针对评论的App引擎数据建模 [英] App Engine Data Modeling for Comments

问题描述

我为当前的应用程序实现了一个注释部分。评论部分可以被认为是给定页面上的一系列用户帖子。我想知道哪种设计在非关系数据库（Google App Engine）中最有效。

设计1：
通过groupId对评论进行分组并对这些结果进行过滤

 评论实体>> [id，groupId，otherData ...] 
  

查询与页面相关的所有评论：

 从中选择过滤groupId 
  

设计2：
为组中的所有注释存储单个密钥，并使用自扩展列表的条目超过5000条。

 评论实体>>查询只需执行一次id / key查找。
 
 
 
 
 $ b 
 
 
 
 $ b 
据我所知，索引可能很昂贵，但第一个设计方案只会索引groupId字段，并且只需要一次写入即可发表评论（如果包含索引，则写入更多）。第二种设计将避免代价高昂的索引，但每个发布的评论都需要读取和写入操作。此外，我很担心争用问题，这些评论应该不会遇到极高的吞吐量，但第二个设计似乎会造成瓶颈。
 
 
 
因为我是新手非关系型数据库，我希望对这些提议的设计及其相关权衡提供任何意见。
   解决方案

数据存储，你将采取的方法主要取决于你的实体需要的一致性模型（强大vs最终）。在Google Cloud Datastore中，有一个实体组的概念。实体组（实体及其后代）是一个实体具有强一致性，事务性和局部性的单元，但也施加了一些限制（每秒写1次）。

注意事项

1. 您需要一致的结果吗？


2. 每页发布评论的频率如何？


3. 您期望每页有多少条评论？


4. 您是否有要求交易行为的用例？

由于您的设计选项均不使用实体组页面 - >职位），我想你决定不这样做。

设计1

1. groupId


2. 更容易维护（您不必处理5000个实体限制）
   

设计2

1. 通过entityGroupId强大的一致性查找功能
   
2. （您必须处理5000个实体限制）


3. 如前所述，代表页面所有帖子的实体可能是瓶颈（可通过Memcache降低）

我可能会采用第一种方法，即使它可能与关系数据模型相似。

I implementing a Comments section for my current application. The Comments section can be thought of as a series of user posts on a given page. I am wondering which design would be most effective in a non-relational database (Google App Engine).

Design 1: Group the comments by a groupId and filter on those results

Comment Entity >> [id, groupId, otherData...]

Queries for all comments pertaining to a page would look like:

Select from Comments filter by groupId

Design 2: Store a single key for all comments within a group and use a Self Expanding List if the number of entries exceeds 5000 entries.

Comment Entity >> [id, SELid]

Queries would simply perform an id/key lookup.

I understand that Indexes can be expensive, but the first design proposal will only index the groupId field and will only require a single write to post a comment (well more writes if you include the index).

The second design will avoid costly indexing but each posted comment will require a read and a write operation. Furthermore, I"m worried about contention issues. These comments should not be experiencing extremely high throughput, but the second design seems to create a bottleneck.

As I am new to non-relational DB's, I would appreciate any input on these proposed designs and their associated tradeoffs.

解决方案

In case of App Engine and Datastore, the approach you will take depends mainly on the consistency model (strong vs eventual) you require for your entities. In Google Cloud Datastore, there is a concept of an entity group. The entity group (an entity and its descendants) is a unit with strong consistency, transactionality, and locality but also imposes some restrictions (1 write per second).

Considerations

1. Do you require strong consistent results?
2. How often will be comments posted per page?
3. How many comments per page do you expect?
4. Do you have a use case requiring transactional behaviour?

Since neither of your design options uses entity group (page -> posts), I suppose you decided not to go this way.

Design 1

1. Eventual consistent lookup by groupId
2. Easier to maintain (you do not have to deal with 5000 entities limit)

Design 2

1. Strong consistent lookup by entityGroupId
2. Harder to maintain (you HAVE to deal with 5000 entities limit)
3. As mentioned, one entity representing all post for a page can be a bottleneck (can be reduced by means of Memcache)

I would probably go with the first approach even though it can resemble relational data model.

这篇关于针对评论的App引擎数据建模的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！