寻找Google App Engine的非规范化建议

Question

我正在研究一个将在GAE上运行的系统,它将有几个相关的实体,我不确定存储数据的最佳方法.这篇文章是对其他可能有类似经历的人的建议的请求....

系统将拥有用户,包括个人资料数据和图像.这些用户将能够创建"事件"并向其添加日记条目.出于系统的目的,"事件"可能在其中包含1或2个日记帐分录,并且任何超过10个的事件都可能永远不会发生.其他用户也可以为用户的条目添加评论,其中流行的评论可能有数百甚至数千条评论.当随机访问者使用该系统时,他们应该能够看到最新的事件(最新的事件,由其中包含最新日记条目的人定义),按标签搜索以及非常有效的基本文本搜索.然后,在选择要查看的事件时,应显示所有日记帐分录和所有用户评论,其中包含用户图像和评论.用户还应该拥有一种自我管理页面,以查看/修改/删除他们的事件,以及查看/修改/删除他们对其他事件所做的评论.因此,在普通的RDBMS上执行所有这些操作只会查询几个表中的一些大连接.在GAE上,它显然需要以不同的方式工作.以下是我对实体设计的初步想法:

• 事件实体 - 标识的id,名称,timstamp,列表属性,视图计数,创建者的用户名,创建者的配置文件图像ID,它包含的日记条目数,它包含的总评论数,包含日记条目的最后更新的时间戳,列表属性用于搜索的索引词(从包含的日记条目中的文本构建/更新)
• JournalEntry实体 - 时间戳,日记文本,事件名称,创建者的用户名,创建者的个人资料图像ID,评论的列表属性(包含评论者用户名和图像ID)
• 用户实体 - 用户名,密码哈希,电子邮件,订阅事件的列表属性,创建日期的时间戳,图像ID,发布的评论数,创建的事件数,创建的日记条目数,上次日记活动的时间戳
• UserComment实体 - 用户名,评论的事件ID,评论的事件标题
• TagData实体 - 标记名称,带有标记的事件计数

所以,我想听听人们在这里对设计的看法,以及应该做些什么改进来帮助它很好地扩展.谢谢!

Answer 1

• 不是存储Event.id为属性,而是使用自动嵌入每个实体键中的id ,或者在创建实体时在实体上设置唯一键名.
• 你有很多的之间建模的关系,选项Event和JournalEntry:你可以使用ReferenceProperty,你可以家长JournalEntries来Events与祖先查询检索它们,或者你可以存储的名单JournalEntry上键ID或名称Event,并用钥匙查询检索它们的一批.使用逼真分布的虚拟数据尝试一些事情,并使用appstats查看最有效的方法.
• UserComment引用一个Event,同时JournalEntry引用一个列表UserComments,这有点令人困惑.有没有之间的关系UserComment和JournalEntry？或者只是UserComment和之间Event？
• 坚持如此多的计数是昂贵的.当我发表评论时,您将编写一个新UserComment实体并更新我的User实体以及JournalEntry实体和Event实体.UserComments您期望的每个数量Event使得将所有内容都包含在同一个实体组中是不明智的,这意味着您无法以事务方式执行这些写操作,因此您将按顺序执行这些操作,并且实体可能存储在不同的网络节点上,从而使整个操作缓慢; 而且你也会对一致性问题持开放态度.你可以没有这些计数,并考虑将其他人存储在memcache中吗？
• 当您Event从数据存储区中获取a时,实际上并不关心其搜索索引字列表,并且从协议缓冲区中检索和反序列化它们会产生成本.您可以通过将每个Event搜索索引单词拆分为单独的EventIndex子实体来解决此问题.然后,您可以查询EventIndex您的搜索词,只获取与您的搜索匹配的EventIndex键EventIndexes,派生相应的Events'键key.parent(),并获取Events按键,从不支付搜索索引词列表的检索或反序列化.布雷特·斯拉特金解释了这一策略在这里为14:35.
• Event.viewCount如果您有很多Event快速连续的视图,则更新将失败,因此您应该尝试计数器分片.

祝你好运,并告诉我们你通过尝试的东西学到了什么.