当应用创建一个实体时，它可以分配另一个实体作为新实体的父。给一个新实体分配父时，将使它进入父实体所在的实体组。
没有父的实体是根实体。一个实体的父实体也可以有父。从一个实体到根的父实体链就是这个实体的路径，路径的成员是实体的祖先。实体的父只能在创建时定义，之后就不能修改。
祖先是同一根实体的所有实体都在相同的实体组中，组中的所有实体存储在同一Datastore节点中。单个事务可以修改单个组中的多个实体，或通过将组中现有实体变成为新实体的父来把一个新实体加到组中。
因为App Engine迫使你以一种特殊的方式（如Datastore on BigTable，而不是数据库）来处理你的开发，Google声称你的应用将更易于伸缩，而且这种伸缩性几乎是透明的：
当一个Web应用变得流行起来时，突如其来的流量可以压垮各种规模的应用，从创业公司到大公司都发现需要一年几次的重新架构他们的数据库和整个应用。通过自动复制和负载均衡，利用Bigtable和Google的可伸缩基础设施中的其他组件，Google App Engine使得应用可以从一个用户伸缩到百万级用户。
User API允许通过Google帐号进行用户验证和登录，以及访问帐号的绰号和邮件。其他更多的用户信息可以从应用保存在Datastore中的用户信息直接获取。
URL fetch API能通过提取HTTP和HTTPs URL（支持GET、POST、HEAD、PUT和DELETE，因此这似乎可以支持REST功能）检索远程服务器的信息。
Mail API允许App Engine应用异步发送邮件，如果邮件服务器不可用时允许重试。
App Engine SDK包含模拟App Engine Python运行时环境的服务器，以及：
- 模拟模块引入限制，只允许处理程序引入被许可的模块，它们来自标准库、包含在App Engine Python环境中的第三方库，以及应用目录中的模块
- 模拟应用缓冲行为
- 使用本地文件模拟App Engine Datastore
- 模拟包含有登录和注销页面的Google帐号，登录参数可以是任何邮件地址。
- 通过提取你计算机的URL模拟URL fetch服务
- 使用你选择的SMTP服务器或Sendmail配置模拟邮件服务
乍一看，绝大多数的应用配置似乎可用YAML来写。
动机和竞争
Google的公告称他们的动机是，简化Web应用的构建、部署和伸缩性：
嗯，我们构建Web应用是因为我们想要更多的Web应用被创建出来。我们注意到，目前创建一个Web应用真的很难：即使部署一个最简单的Web应用也有巨大的前端挑战。你需要做很多事情。当然，首先你必须为你的应用编写代码。
但是接着，你还需书写你的Apache Web服务器配置和启动脚本，安装你的数据库，创建所有表和设置口令，安装监视器来了解你的流量和日志，决定你如何推出代码的新版本等等。
那只是我们注意到的技术方面的挑战。然后，一旦你完成了所有那些系统管理员的工作，你就有了另一个挑战：你必须着手去找你能使用的机器来运行你的应用，不论是物理的还是虚拟的提供商。现在，就要花钱了：即使是最简单的应用，一周用几次，你都必须支付一大笔预支费用来让它在一个传统主机托管提供商处运行。
那么，这就是财务或物理方面的挑战。然后，一旦你搞定了整件事情并且运行了，而且找到地方并为此付费来测试它，你又面临了另一个挑战：随着你应用的成长，你必须去维护它。你的机器崩溃了，你的配置有错误，你的硬盘坏了，你的流量开始增长，你必须重新分享你的数据库，安装更多更多的机器。随着应用的成长，任何事情都象是一场激战。
所有这些激战正是我们试图通过App Engine避免的。它们是我们正试图解决的问题。
其他人已经揣测出了言外之意。很多人指出了Google与Amazon和微软在未来云计算和Web服务方面的竞争，常常将App Engine与Amazon的Web服务EC2、S3、SQS 更多详细信息，请您微信关注“计算网”公众号：