上次谈到“中国铁路订票系统”已经可以有无穷无尽的服务器可以使用了，但是还有很多问题还要解决。首当其冲的是数据库：一天中成功或者未成功的订单会有上 百万条记录，每天的车次以及每趟列车当前的票务记录也很多，查询起来时间会非常长。解决这个问题快的办法是数据库缓存和静态页面缓存，比如说每天每两个 城市之间的查询结果生成静态页面，订单状态放置在缓存中然后每小时更新。数据库的索引当然也必不可少。但是假设说要允许消费者以任意的规则搜索当前实时 的数据，又要求在相当小的时间内返回（比如说2秒），现在的关系型数据库就表示压力很大了。

  关系型数据库有这些问题：

  1. 无法存储海量的数据

  2. 查询时间很可能因为数据记录的增加而激增

  3. 分布部署和同步都很麻烦

  4. 分布部署以后请求的转发和负载均衡也很烦

  这时amazon sdb就有用武之地了。Amazon SimpleDB是一个分散式资料库，以Erlang撰写。同与Amazon EC2和亚马逊的S3一样作为一项Web 服务，属于亚马逊网络服务的一部分。简单的说，simpledb是一个简单快速可以扩展的no-sql数据库，这个数据库的运行由亚马逊负责。 对于上面关系型数据库遇到的这些问题，simpledb可以保存海量的数据，并保持较快的响应速度（几乎所有类型的查询响应时间都是接近的），部署和数据分布也不需要多操心，数据的备份也是由亚马逊自动完成的。

  所有对SimpleDB的操作都是可以通过REST完成的，当然可以通过Amazon提供的官方API来调用，但是实质发送接受的都是XML。

  搭建一个SimpleDB数据库很容易，但是现在好像还不能通过亚马逊的控制台完成。我常用的工具叫做AmazonSimpleDB-2009-04-15-scratchpad，可以用来增删查改simpledb的domain（相当于RDMS里的table）。请注意，scratchpad工具默认连接美国1区的simpledb，要更改地区的话需要更改代码里的地址。Eclipse里也有访问Simpledb的插件。

  amazon的收费非常便宜（具体价格大家可以查aws.amazon.com,我自用基本不会超过服务器费用的1/10）。

  SimpleDB当然不会适合所有的系统，它至少有以下的限制：

  1. simpleDB的性能优势是付出功能上的代价的，比如simpledb只支持很简单的SQL查询。需要复杂多表关联和神级SQL的应用要多考虑一下。

  2. 每次返回的结果集多2500个对象。当然大部分SDK会分多次调用取回所有结果。

  3. 每个Domain（相当于table）只能存储不超过10GB的数据以及不超过1,000,000,000条属性。有部分SDK提供分shard的功能，自己实现难度也不大。

  4. 每个属性不能超过1024个字节。这个比较硬伤，通常的解决方法是把超过1024的字段存在Amazon S3里，然后在simpleDB里保存S3的引用地址。

  “中国铁路订票系统”现在有了个易于扩展的数据库的支持，在不复杂的查询要求下，可以保证查询的反应速度,并且稳定的自动备份的运行在amazon上了,再也不会timeout或者直接CPU 崩溃了。