第二部分5-9章综述,designing Data-Intensive Applications 中文翻译摘要

之前的第一部分我们都在讲的是单机的数据系统。第二部分我们上一个台阶，当有多台机器的时候，我们需要如何进行数据的存储和查询？为什么我们需要一个多机分布式的数据库呢？原因如下

• 扩展性， 如果你的数据量，读写量已经超过了单机负载的极限，你可以通过多机部署的方法提高负载
• 容错性/高可用性, 如果你的服务要求即使单机挂了，也能正常服务，那你就需要多机了，即使一台挂了，其他机器依旧能够提供服务
• 减小延迟, 如果你的用户遍布全球，那你会希望你在世界多个地区都有服务部署，这样用户就可以和他最近的那个服务通讯，避免了你的数据跨越半个地球而带来的延迟。

提高服务负载能力

如果你想提高你服务的负载能力，最简单的方法是买一台更好的机器，这个往往称作垂直扩展(vertical scaling or scaling up)。这也引出了共享内存架构(shared-memory architecture)。如果你有多个CPU，多个内存条，多块磁盘在同一个操作系统的管理下，并且CPU可以内部极快的访问你的内存。这样可以把这所有的组件当做一台机器看待。

但是这个方案有一个问题，首先是性价比问题，一台电脑如果有原来2倍的CPU，2倍的内存，2倍的磁盘空间，那价格一定不止原来的2倍。另外就是由于瓶颈效应，这台配置2倍的机器很可能无法承受2倍的负载。还有就是这个架构的容错性比较差，虽说高端机器会允许你在不停机的情况下更换CPU，内存，磁盘等等。但是他毕竟还有地理位置的限制，也就是说你不可避免的会有高延迟的问题。

另外一个方法是共享磁盘架构(shared-disk architecture), 我们用多台机器，这些机器之间共享磁盘，但是每台机器有自己的CPU和内存，机器之间通过网络连接。这种方式在一些数据仓库当中有运用，但是网络传输以及多机锁的问题限制了他的扩展性。

不共享架构

相反，不共享架构(shared-nothing architectures),也叫水平扩展(horizontal scaling or scaling out)就更为流行。在这种架构下，每一台机器被称作一个节点(node), 每个节点有自己的CPU， 内存，磁盘，节点之间是不共享任何东西的。任何节点之间的协作是通过软件层面实现的，通信方式还是最为普通的网络。

因为这个架构对硬件机器没有任何要求，所以你可以用任何你觉得性价比最高的机器。你可以把数据放在不同地域的数据中心内，这样既可以降低延迟，也可以防止某一个机房崩溃所带来的数据丢失。在当下，由于有了云服务商，你不再需要有google这个量级，也可以轻松的用虚拟机部署一个多地的服务。

本章我们重点关注不共享架构，因为这个架构很好用，并且在这其中你需要考虑很多东西，一旦你的数据跨节点存储，在这其中就会有很多的约束和折中。这些问题数据库都没办法替你处理。

尽管这种不共享架构有很多优点，但是同时它引入了很多的复杂性，有时候会限制你的可用的数据模型。在特殊情况下，一个单机单线程的程序要比一个100核的大集群的表现更好。下面就深入来讲当数据分布到多机后，一些特有的概念。

备份(Replication) VS 分区(Partitioning)

将数据部署到多地有两种简单的方法，

• 备份， 将同一份数据的多个副本保存到多机，甚至多地。备份提供了可靠性，即使一个节点挂掉了，剩下的节点也可以提供服务。备份往往也能带来性能提高，这个第5章讲。
• 分区, 将一个大型数据库分解成若干个小的子集，不同的分区可以部署在不同的节点上，这种也叫分片(sharding).这个技术第6章讲
  虽然这是两种技术，但是我们往往在日常中要结合两种技术同时使用，可以看Figrure II-1
  
  

当我们对这些概念有了简单的了解后，我们会讲一个分布式系统比较难的点，权衡(trade-off), 第7讲事务(transactions),你会发现在一个数据系统中，很多地方会有很多你意想不到的错误，然后会了解到如何应对这些问题。第8、9章会总结讨论分布式系统的一些基础限制。第三部分主要讲如何将多个不同的数据存储集成到一个大型系统中去，以满足系统各个方面的需求。