Google App Engine 数据存储实体.效率和结构 [英] Google App Engine Datastore entities. Efficiency and structure
问题描述
我有兴趣了解 Google App Engine Datastore 实体的最佳结构，以提高速度和成本效率.
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.
每个俱乐部的单个 ndb.Model 实体，具有:姓名、ID、地址、联系人、标签、评论、图片等
A single ndb.Model entity per club with: Name, ID, Address, Contacts, Tags, Reviews, Images etc
每个俱乐部有多个实体，其 KeyProperty 引用俱乐部.
Multiple Entities per club with a KeyProperty referencing the club.
- ndb.Model 实体 A. 名称和 ID
- ndb.Model 实体 B. 地址
- ndb.Model 实体 C. 联系人
- 等
考虑到用户可能只想查找靠近其位置的俱乐部的地址，或者可能只想搜索一个俱乐部的联系电话，或者可能滚动浏览有关各个俱乐部的信息页面；什么是速度和成本效率的更好结构/最佳实践?
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?
谢谢.
推荐答案
归结为 (a) 阅读模式，和 (b) 写作模式.
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屋！
