Google App Engine数据存储实体。效率和结构 [英] Google App Engine Datastore entities. Efficiency and structure
问题描述
我有兴趣了解Google App Engine数据存储实体的最佳结构，以提高速度和成本效率。 举例来说，一个关于Clubs的应用程序。 / b>
结构A：
每个俱乐部的单个ndb.Model实体：
名称，ID，地址，联系人，标签，评论，图片等
结构B：
具有KeyProperty的每个俱乐部的多个实体参考俱乐部。
- ndb.Model实体A.名称和ID
- ndb.Model实体B.地址
- etc
考虑到用户可能只想查看靠近他们位置的俱乐部的地址，或者可能只搜索一个俱乐部的联系人号码，或者可能浏览关于各个俱乐部的信息页面;什么是更好的结构/速度和成本效率的最佳做法？
谢谢。
阅读：
如果您的使用最广泛-case将显示关于俱乐部的所有信息，将所有信息保存在单个实体中将是更便宜和更高效的方法（一次读取而不是三次）。
WRITE：
如果您的模型包含很多几乎不会更改的属性和一些非常频繁更改的属性，最好将它们分离为不同的实体，以便每个更新的单个实体不会触发对所有索引的更新。
在你的例子中，似乎没有理由将实体分成多个模型。
I am interested in knowing the best structure, for speed and cost efficiency, of Google App Engine Datastore entities.
As an example, an app about Clubs.
Structure A:
A single ndb.Model entity per club with: Name, ID, Address, Contacts, Tags, Reviews, Images etc
Structure B:
Multiple Entities per club with a KeyProperty referencing the club.
- ndb.Model Entity A. Name and ID
- ndb.Model Entity B. Address
- ndb.Model Entity C. Contacts
- etc
Considering that users might only want to look up addresses of Clubs close to their location, or perhaps only search for a contact number for one Club, or might scroll through pages of information about various Clubs; what is the better structure / best practice for speed and cost efficiency?
Thanks.
It all boils down to (a) reading pattern, and (b) writing pattern.
READ: If your most widely use-case is to show all the information about the club, keeping all information in a single entity will be a cheaper and a more efficient approach (one read instead of three).
WRITE: If your model includes many properties that are almost never changed and some properties that change very frequently, it's better to separate them into different entities, so that each update of a single entity does not trigger updates to all indexes.
It appears that in your example there are no reasons to split the entity into multiple models.
这篇关于Google App Engine数据存储实体。效率和结构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
