从数据库与现代硬件谈起
前两天和一个朋友聊数据库的时候谈到数据库的设计如何充分利用现代硬件的特性，从而使之更为高效。实际上数据库厂商对硬件新特性的渴望一直是十分强烈的。
1996年，DEC
的64位服务器ALPHA刚刚推出的时候，Oracle就迫不及待的推出了VLDB和VLM（Very Large
Memory），虽然当时的VLM仅仅是GB级别，不过相对于当时服务器几十MB级别的物理内存来说，已经是巨大的发展了。
VLM的出现，让Oracle逐步解决了共享池争用严重的瓶颈问题，也让各种现在数据库可观测性的能力得到了极大的发展。而在SSD开始大行其道的时候，Oracle推出的Exadata更是把数据库与现代硬件做了十分强大的绑定，重新优化过的direct
path read可以瞬间榨干Exadata硬件的能力，Smart Scan可以把扫描的操作下沉到存储上。
现代数据库产品也在充分考虑如何充分利用现代硬件的技术特点，2017年我在杭州和Yellowbrick的朋友交流NEWSQL技术的时候，他们提出了一个更大胆的设计，构建一套类似Teradata的数据库、硬件一体化的设计方案，把大量的SQL操作单元下沉到硬件上，甚至可以下沉到NVME
SSD控制器上。借着这种一体化设计，Yellowbrick可以轻松面对数千亿条记录的表之间的表连接操作。当然这种系统的成本也是极高的，不是一般用户用得起的。
国内数据库厂商充分利用硬件的大多数选择是分布式架构，这也是这些年网络硬件大的发展对数据库的贡献之一。实际上对于分布式数据库和集中式数据库的选择也是仁者见仁智者见智，分布式数据库厂商讲得多的是SacleOut/ScaleUp之争。实际上这个争论的年代已经十分久远了，而那个时代正好是性能荒漠时代，CPU/MEMORY/DISK的性能扩展都十分困难，价格十分昂贵。
而我们现在正在迎来一个服务器性能相对富裕的时代，近一次统计一个企业客户的200多个数据库系统，CPU的平均使用率几乎都小于10%，绝大多数系统的CPU平均使用率低于5%。峰值CPU使用率也不过80%多，而且这几个库都是跑在IBM
P系列小型机上。
实际上我们的X86服务器单机处理能力目前还不存在十分严重的瓶颈，选择分布式数据库有时候是一些场景需要（比如高并发的IOT应用场景），有时候是可靠性的要求，支持分布式，多副本数据存储的分布式数据库天生拥有高可用容错能力。
实际上在全球范围内看，目前单机集中式数据库还是主流。Oracle
RAC是集中式数据库的一个终极追求目标。不过RAC也不是的，CACHE
FUSION是需要代价的，随着RAC集群数量的增多，这个代价会越来越高。
十多年前我给一个客户的6节点OLTP交易系统做过优化，当时使用6台P570的系统，在处理10万/秒的并发交易的时候，就已经力不从心了，后来换成Oracle
EXADATA
X2-8，两台8路服务器的RAC集群，轻松达到48万/秒的峰值。实际上对于现代硬件的性能，很多数据库用户是不知道的，2012年我在一个运营商的IT架构优化大会上，分享我们在4路40核的X86服务器上与IBM
P750
32核性能对比数据时，大家都十分惊诧，不相信我的数据的真实性。我的演讲结束后，有一个人上来激动地和我握手拥抱，我当时十分高兴，总算是遇到知音了。后来交换名片一看，他是INTEL负责运营商业务的总监。
在国内数据库厂商纷纷选择选择分布式架构的时候，亚马逊的AURORA选择了另外一条道路，那就是基于日志重演与存储多副本的读写分离架构。
实际上，数据库的各种架构设计都是为了满足应用的需求的。作为一个数据库用户，我们的应用需要什么样的数据库呢？我想可能有几点：Aurora在回答上面这些问题上都给出了很好的答案。Aurora底层是使用自己的分布式存储系统的，磁盘都是EC2虚拟机中的本地磁盘，这个分布式存储优化的很好，有很强大的可扩展性，可以提供高并发，低延时的IO访问能力。
Aurora采用的是读写分离集群结构，大配置环境为一主15副本。可以通过放在不同的故障隔离区来实现极高的高可用特性。一个典型的架构是在3个数据中心中使用6个副本，实现每个数据中心都是高可用的。
Aurora采用了读写分离的方式解决横向扩展问题，实际上在大多数OLTP系统中，写操作与多操作的比例大概是2:8，甚至是1:9，读操作是一个大型OLTP系统中成本与开销大的操作。08年的时候，给某移动公司优化BOSS系统的时候，他们就是因为IBM小型机的CPU资源严重不足，经常出现问题，我们建议他们将部分数据通过OGG复制到一台X86服务器上，把几个十分频繁的查询操作迁移走之后，这套系统就变得十分稳定了。Aurora主实例可以同时处理读取和写入请求。
更改日志被发送到
3 个不同数据中心的所有 6 个 EC2
实例。副本实例仅服务于读取请求。当页面有更新时，主实例向副本实例发送通知，通知它该页面已过时。如果该页面在副本实例的缓冲区内，它将从缓冲区中逐出该页面。当副本实例收到读取请求时，如果缓冲区中不存在该页面，它将向
EC2 实例发送请求以获取该页面。借助远程存储，Aurora
数据库支持多个实例并行运行，而无需在它们之间进行大量协调。通过主副本设置，Aurora 数据库能够支持比传统 DBMS 更高的吞吐量。
在这里，Aurora并没有采用类似Oracle的Cache
Fusion技术来处理数据变更，而是采用了日志重演的方式（目前还没有自己研究其细节，实现算法还不是很清楚）。这是一种降低复杂性的方法，Cache
Fusion的复杂性带来的研发成本是相当高的，而且对于今后只读节点的横向扩展也不利。
这种架构中必不可少的就是读写自动分离，以及故障自动切换，这些AMAZON当然也已经安排的妥妥的。从上面的简单分析来看，Aurora已经比较全面地解决了我们应用所关心的数据库问题。因此Aurora的出现在数据库界也被认为是一个十分了不起的创新。
现在阿里的Polardb-PG也采用了类似的架构，我想如果POLARFS能够达到AMAZON分布式存储的性能，那么Polardb这种数据库的应用前景也是不错的。