GAE数据存储设计存储“like”用户状态机制（如Facebook的“喜欢”） [英] GAE datastore design to store "like" mechanism for user's status (like Facebook's "likes")

问题描述

我正在使用Google App Engine的数据存储，并寻找一个用于用户状态的喜欢功能的设计解决方案（类似于Facebook的喜欢）。

已经经历了Sharding Counters概念（ https://developers.google.com/appengine/articles/sharding_counters ），并发现它很好，适合计算可以增加或减少计数的喜欢数。但我想存储喜欢这个状态的userId。所以我尝试了相同的分片概念来存储userIds，但是面对以下问题，
*首先将userId列表分割为count是很好的做法？
*如果是这样，当用户不喜欢它，我已经从共享列表中删除用户标识。为了实现这一点，我需要遍历所有分片数据存储并执行userId检查并删除

对此或其他解决方案的任何建议以实现它？

谢谢！

解决方案

分片不适用于这种情况。分片是为了避免在短时间内对同一个对象进行多次写入。因为许多人喜欢同一个帖子，所以对'喜欢'的计数器有意义。当他们喜欢什么的时候不一样。这些对象只会改变每个用户，许多用户不会共享同一个对象。只需将它们存储在非分片表中，就像在sql中那样。

I'm using Google App Engine's datastore and looking for a design solution for "like" functionality for user's status (similair to facebook "likes")

I've gone through the Sharding Counters concepts (https://developers.google.com/appengine/articles/sharding_counters) and found its good and suitable for counting number of likes where you can increment or decrement the count. But I want to store the userId who liked the status. So I tried the same sharding concepts to store userIds but facing the below issues, * first of all is it good to shard userId list like count? * If so when the user dislike it, I have remove the user id from shared list. To achieve this I need to traverse all the sharded datastore and do a userId check and remove

Any suggestions on this or alternative solutions to achieve it?

Thanks!

解决方案

Sharding doesnt apply for that case. Sharding is to avoid many writes to the same object in short time periods. Makes sense for a 'likes' counter since many people like the same post. Not the same when sgoring who liked what. Those objects only change per-user, many users dont share the same object. Just store those in a non sharded table like you would in sql.

这篇关于GAE数据存储设计存储“like”用户状态机制（如Facebook的“喜欢”）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！