Boang's Blog梦,追逐着….

       
       数据存储区查询将返回零个或多个单一类别的实体。它也可以只是返回查询所得的实体的键。查询不仅可以根据条件（必须匹配实体属性的值）进行过滤，还可以根据属性值对返回的实体进行排序。查询也可以通过键来进行筛选和排序。

       在传统的关系型数据库中，查询会实时地根据数据表（由开发人员决定如何对其进行存储）进行计划和执行。开发人员还可以让数据库在指定的列上创建和维护索引以提高相关查询的执行速度。

       App Engine的做法与此大不相同。在App Engine中，每个查询都有一个与之对应的由数据存储区维护的索引。当应用程序执行查询时，数据存储区将会找出该查询的索引，扫描并找到第一个与之匹配的行，然后逐行返回索引中的实体，直到发现与查询不匹配的行为止。

       当然了，这需要App Engine预先掌握应用程序将要执行哪个查询才行。虽然它无须预先知道具体的筛选条件，不过却需要知道查询中实体的类别、用于筛选或排序的属性、筛选器的操作符以及排列顺序等。

       默认情况下，App Engine会根据各类实体的既有属性为简单查询提供一组索引。为了执行更复杂的查询，应用程序必须在其配置文件中添加索引声明。当你在本地计算机上利用App Engine SDK所提供的那个开发版Web服务器测试应用程序时，App Engine SDK会监视所执行的查询并帮你生成一份配置文件。在你上传应用程序的时候，数据存储区就会自动地为测试时执行过的每条查询生成索引，你也可以手工编辑索引配置文件。

       当应用程序创建了新实体或是更新了现有实体时，数据存储区会更新相应的索引。这也就使得查询变得非常快（每个查询都是一个简单的表扫描译注1），而实体的更新操作则反之（一个小小的修改就可能会使很多表译注2都需要更新）。事实上，基于索引的查询性能并不受数据存储区中实体数量的影响，而只会受到结果集大小的影响。

       索引是值得关注的，因为它们会占用空间，而且会增加实体更新操作所需的时间。我们将在第5章中详细讨论索引。

       译注1： 其实这里用“索引扫描”来比喻会更加贴切（我不知道GAE中索引的具体组织形式，虽然本书有所提及，但我始终认为G公司应该不会把索引做得如此简单，毕竟系统IO的速度在那摆着）。

       译注2： 这里指定的应该是“索引”或“索引表”。同上，索引和表这两个概念也不一样。
Continue reading →

       
       App Engine应用程序将其数据保存为一个或多个数据存储区实体（entity）。实体拥有一个或多个属性（property），每个属性都有一个名字和一个值，这个值可以是任何一种基本值类型。每个实体都有一个命名类别（kind），它用于在查询中对实体进行分类。乍一看上去，这跟关系型数据库没什么不同：同一类别的实体就像是表中的行，而属性就像是列（字段）。实际上，实体和行之间有两个显著的区别：第一，同类别的两个实体无须拥有相同的属性；第二，两个实体的同名属性可以拥有不同类型的值。这样，数据存储区实体就成“无架构”的了。你很快就会看到，这种设计既提供了强大的灵活性，同时也带来了一些维护上的问题。

       实体跟表行之间的另一个区别在于：实体中的某个属性可以拥有多个值。这个功能有点诡异，不过当你弄明白之后就会发现它的作用其实非常大。每个数据存储区实体都有一个唯一键，它既可以由应用程序提供，也可以由App Engine 生成（随你高兴）。跟关系型数据库不同，这个键不是“字段”也不是属性，而是实体的一个独立元素。如果知道实体的键，就能够快速地将其取出来，还可以执行基于键值的查询。

       实体的键在其创建之后就不能修改了，其类别也一样。App Engine通过实体的类别和键去判断它究竟存储在一大堆服务器中的什么位置（不过，键和类别都不能保证某两个实体会存储在同一台服务器上）。

       
       大部分网站都有那种“需要发送给浏览器但却不会因为日常操作而发生变化”的资源。用于描绘网站外观的图片和CSS文件、在浏览器中运行的JavaScript代码、不含动态组件的HTML网页文件等都属于这样的资源，人们将之统称为静态文件（static file）。由于发送这些文件时不会用到应用程序代码，因此没有必要把它们放到应用程序服务器上,实际上，那样的做法是很低效的。

       为此，App Engine另外提供了一组服务器专门用来发送静态文件。为了处理对静态资源的请求，这些服务器专门对内部架构和网络技术进行了优化。对客户端而言，静态文件跟应用程序所提供的其他资源没什么两样。

       你可以在上传应用程序代码的时候上传静态文件。在静态文件的处理方式上，你可以进行许多方面的配置，比如内容类型、静态文件的URL等；此外，为了降低流量并提高页面呈现速度，还可以指定浏览器对这些文件副本的缓存时间。

       
       App Engine会对Web请求作出响应。当客户端（一般就是用户的Web浏览器）通过一个HTTP请求（比如获取某个指定URL的网页）联系应用程序时，Web请求就开始了。当App Engine接收到请求时，会根据其地址中的域名确定具体的应用程序，这个域名可以是一个.a p p s p o t.c o m子域名（任何应用程序都可以免费使用），也可以是你自己注册并设置到Apps的自定义域名的某个子域名。App Engine会从许多可用服务器中选出一个来处理该请求，选择的依据是看哪个服务器最可能作出快速响应。然后，它将使用该HTTP请求中的内容去调用应用程序，并接收来自应用程序的响应数据，跟着再将响应返回给客户端。

       从应用程序的角度来看，运行时环境在请求处理器（request handler）启动时出现，并在其结束时消失。App Engine提供了至少两种用于持久化请求之间存储数据的方式（稍后再讨论），不过它们都不是在运行时环境内部实现的。由于不会在运行时环境内部保留请求与请求之间的状态（其实本来就不想保留），因此App Engine可以将流量分布到多个服务器上去，这样它就可以同等对待每一个请求了，而无须关心到底一次处理了多大的流量。

       从传统意义上来讲，应用程序代码是不能访问其所在的服务器的。虽然应用程序能够通过文件系统读取其自己的文件，不过却不能写文件，而且也不能读取属于其他应用程序的文件。虽然应用程序可以通过App Engine看到环境变量集，不过对这些变量所作出的修改操作不能在请求与请求之间持久化。应用程序不能访问服务器硬件中的网络设备， 但是可以通过相关服务来完成网络操作。
Continue reading →

    
       GAE是一个Web应用程序托管服务。其中，“Web应用程序”指的是通过Web（通常是利用Web浏览器）访问的一个应用程序或服务，比如，带有购物车功能的网上商店、社交网站、多人游戏、移动应用、投票应用、项目管理、协作、出版等其他一切能够利用Web的东西也都是可以的，只要我们想得出就行。虽然App Engine也适用于诸如文档和图片等传统网站内容，但它实际上是专门针对实时动态应用程序而设计的。

       GAE主要是针对那些拥有大量并发用户的应用程序而设计的。当某个应用程序在有大量并发用户的情况下性能没有降低，我们则认为其“伸展”了。为App Engine所编写的应用程序都是可以自动伸缩的。某个应用程序的使用人数越多，App ngine为其分配的资源也就越多，同时它还会对那些资源进行管理。而应用程序本身则无需了解它所使用的那些资源到底是怎么回事。

       与传统的Web托管或自管服务器不同，使用GAE时，你只需为那些实际用到的资源付费。这些资源均会换算成GB，无须按月付费或预付费。可供购买的资源包括CPU使用率、每月存储容量、出入口带宽以及其他特定于App Engine服务的资源。为了便于人们了解GAE，每个开发人员都能免费获得一些资源，这些资源已经足以应付那些流量不大的小应用了。G公司曾对此进行过评估，使用这些免费资源的应用程序能够应对每月500 万左右的PV量。

       我们可以把App Engine描述为三大块：运行时环境、数据存储区以及可伸缩的服务。在这一章中，我们将从宏观的角度来观察每个部分。我们还将讨论App Engine的一些特性，包括Web应用程序的部署管理，以及集成其他服务（例如Apps和Account）等。