1996年，DEC 的64位服务器ALPHA刚刚推出的时候，Oracle就迫不及待的推出了VLDB和VLM（Very Large Memory），虽然当时的VLM仅仅是GB级别，不过相对于当时服务器几十MB级别的物理内存来说，已经是巨大的发展了。
VLM的出现，让Oracle逐步解决了共享池争用严重的瓶颈问题，也让各种现在数据库可观测性的能力得到了极大的发展。而在SSD开始大行其道的时候，Oracle推出的Exadata更是把数据库与现代硬件做了十分强大的绑定，重新优化过的direct path read可以瞬间榨干Exadata硬件的能力，Smart Scan可以把扫描的操作下沉到存储上。
而我们现在正在迎来一个服务器性能相对富裕的时代，近一次统计一个企业客户的200多个数据库系统，CPU的平均使用率几乎都小于10%，绝大多数系统的CPU平均使用率低于5%。峰值CPU使用率也不过80%多，而且这几个库都是跑在IBM P系列小型机上。
实际上我们的X86服务器单机处理能力目前还不存在十分严重的瓶颈，选择分布式数据库有时候是一些场景需要（比如高并发的IOT应用场景），有时候是可靠性的要求，支持分布式，多副本数据存储的分布式数据库天生拥有高可用容错能力。
十多年前我给一个客户的6节点OLTP交易系统做过优化，当时使用6台P570的系统，在处理10万/秒的并发交易的时候，就已经力不从心了，后来换成Oracle EXADATA X2-8，两台8路服务器的RAC集群，轻松达到48万/秒的峰值。实际上对于现代硬件的性能，很多数据库用户是不知道的，2012年我在一个运营商的IT架构优化大会上，分享我们在4路40核的X86服务器上与IBM P750 32核性能对比数据时，大家都十分惊诧，不相信我的数据的真实性。我的演讲结束后，有一个人上来激动地和我握手拥抱，我当时十分高兴，总算是遇到知音了。后来交换名片一看，他是INTEL负责运营商业务的总监。
更改日志被发送到 3 个不同数据中心的所有 6 个 EC2 实例。副本实例仅服务于读取请求。当页面有更新时，主实例向副本实例发送通知，通知它该页面已过时。如果该页面在副本实例的缓冲区内，它将从缓冲区中逐出该页面。当副本实例收到读取请求时，如果缓冲区中不存在该页面，它将向 EC2 实例发送请求以获取该页面。借助远程存储，Aurora 数据库支持多个实例并行运行，而无需在它们之间进行大量协调。通过主副本设置，Aurora 数据库能够支持比传统 DBMS 更高的吞吐量。
现在阿里的Polardb-PG也采用了类似的架构，我想如果POLARFS能够达到AMAZON分布式存储的性能，那么Polardb这种数据库的应用前景也是不错的。
