这次发布的是没有包含全部特性的预览版，提供了一个配额系统，它限制了在预览期间应用免费可用的存储、CPU和带宽。一旦预览期结束，配额仍将免费，但是开发者需要按需购买额外资源。额外资源的价格尚未公布（甚至可能尚未确定）。
预览版的配额包括：3个应用/开发者、500MB存储/应用、2000封邮件/天（连续24小时）、10 GB入站带宽、10 GB出站带宽、200M CPU兆周、650k HTTP请求、2.5M Datastore API调用和160k URL Fetch API调用。
技术：开发环境和API
尽管Google说‘未来将支持更多的语言’，但是目前技术栈是基于Python的，它是Google认同的语言之一。出于安全和伸缩性的目的，Google提供了一个运行在安全沙箱中的Python运行时环境，它提供对底层操作系统有限制的访问。该环境包括标准库，并可通过模块进行扩展，编写模块的语言目前不支持C语言。
该环境包括Python标准库。当然，调用那些违反沙箱限制的库方法（如打开socket或写文件）将不会成功。为了方便起见，几个核心特性不被支持的标准库中的模块被禁用了。那些引入它们的代码会出错。
应用代码只能用Python书写。不支持使用C来编写扩展。
其他安全限制包括：出站通信（outbound communication）只能通过所提供的邮件和URL fetch API进行，通过HTTP和HTTPS作为传输的入站通信（inbound communication）使用标准端口，禁止文件系统写操作和禁止子进程或代码在请求/响应循环外执行（例如后台操作和批操作）。
此外，Google提供了访问一个Datastore、Google用户帐号、URL fetch和邮件服务的API。App Engine还包括一个简化的Web应用框架和Django 0.96.1，尽管App Engine Datastore不是关系型的，而且也不能使用全部的Django API。
Datastore API背后由Google的BigTable支持，但是它与一个简单的对象持久化API（或一个对象关系映射框架，即使Google强调这个Datastore不是关系型的）有很多相同之处：
你们中的大多数，在使用这个Datastore时可能会有点不习惯：如我所说，它不是SQL。这是个巨大的区别。然而，我们想了一下之后，认为这个Datastore可能会引起你们的兴趣，因为它让一些事情变简单了。比如说，我们的Datastore没有模式，这意味着它可以支持任意的新属性或列，你可以用代码创建，无需把所有事情预先设计好并创建一个模式。这就回到了我们尽可能简化Web应用编写的目标：只需开始编码就好了。你的数据模型可以随你应用的演变而演变。
即使Datastore违背了SQL，我们仍然支持你想要的传统关系数据库的许多强大功能。对于任何你提供的单个属性或属性集合，Datastore都提供了高效查询。它还支持对查询结果的排序，包括按多属性进行排序。它对写操作支持事务，通过事务分组来控制。对于提取或创建大量实体，它也支持批操作。它给你机会让你来控制你实体的主键，以获得更好的查询效率和更短的URL。
并且，即使Datastore不是SQL，我们也为你提供了类SQL查询以简化查询的表达，叫做GQL。GQL受到了jQuery和FBQL的启发：底层的存储不是SQL，但是几乎你想要的所有查询仍然可以完成。
你可能已经注意到我们的Datastore缺少一个大特性，那就就是连接（join）。这是因为连接通常是分布式系统效率问题的根源，当你有不止一台机器时：很难在跨多个机器和多个硬盘的分布式系统上进行连接操作。
尽管Datastore API支持事务，但是它们有严格的限制，而且和实体组关联：
每个实体都属于一个实体组，在一个事务内可以操作一个或多个实体。实体组关系告诉App Engine在分布式网络的同一部分保存几个实体。一个事务为一个实体组设置Datastore操作，所有这些操作按组实施，如果事务失败就全部撤销。
更多详细信息，请您微信关注“计算网”公众号：
