Python和Google AppEngine开发基于Google架构的应用软件

核心提示： ，我们所面临的用户则几乎是无法预计的，Python和Google AppEngine开发基于Google架构的应用软件(2)，其行为也有一定的不确定性，从而给数据库带来了更大的风险，还必须要引入客户端的Ajax，比如Prototype或者Dojo等，举一个不太恰当的例子，当一个突发事件发生

，我们所面临的用户则几乎是无法预计的，其行为也有一定的不确定性，从而给数据库带来了更大的风险。举一个不太恰当的例子，当一个突发事件发生的时候——比如当年克林顿总统“拉链门”的斯塔尔报告就曾经几乎让整个互联网瘫痪。之所以说这个例子不太恰当，是因为我们在当下的互联网上所需要做的，是云计算之下的面向全球的企业级应用，而不仅仅是若干个文档的下载。

BigTable所做的事情之一就是存储结构上的优化——当然，由于其是基于互联网架构的，我们没有办法在自己的Windows或者Linux上安装一个BigTable来分析其底层结构——而且Google应该也不允许我们这么做。BigTable数据库系统从其根本上并不是为了将其数据放在企业内部而设计的（这也就是为什么Google AppEngine不希望将Devappserver.py开发的程序作为企业应用的理由之一，因为开发环境下根本不是真正意义上的BigTable，而只是一个文件模拟存储而已。）——另一个可能的原因就是除了Google之外，世界上可能没有其他适合BigTable运行的硬件架构，众所周知，Google的底层硬件结构是自创的。

Google的BigTable的存储是实体的概念，我们关系型数据库传统意义上的“表”对BigTable来说是一个实体集合；而表中的每一行则是一个“实体”。对于单个的实体而言，“字段”——当然，这里所说的字段是对应于关系型数据库而言的，在BigTable中，我们称之为属性(Property)，BigTable的属性可能不是确定数量的，如果对于一些实体来说，有五个属性，那么对于另外一些实体则可能有十个属性，这完全是根据需要而定的，不必为所有的实体都预先分配相同的属性。这种设计对于一般数量级的应用来说似乎无关紧要，因为关系型数据库本身就已经对“空”数据进行了优化处理；但是对于海量数据和系统的扩展而言就有很重要的意义了。BigTable的另外一个特性就是它的存储是可以“分组”的。例如，对于我们开发的一个系统，我们可能希望在一个事务中一次性处理一个用户的数据（这是非常可能的，可能来自于用户的操作，也有可能是因为系统的升级而需要对数据分别进行批量处理），如果有这种需要的话，我们可以将数据进行分组，分组的方法就是在创建一个实体的时候将另外一个实体作为新实体的父节点。已经创建的实体不能对其重新进行分组。分组后的数据，在Google后台的存储是存储在基础架构的同一个节点（注意，对Google而言的一个“节点”显然不是我们传统意义上的一台单机，而是一组后台存储架构，可能包含上千台服务器）上的。正是因为同一分组的数据放在同一个存储节点上，于是才可以在同一个事务中进行处理。

除了GoogleAppEngine提供的以上三利器之外，为了更好的开发富应用的互联网系统，还必须要引入客户端的Ajax，比如Prototype或者Dojo等，从而可以使系统和用户的交互更加友好。