我喜欢数据库的原因：没那么复杂和吓人

　　去年我在 Square 的工作中接触到了很多种数据库。包括：

1. 　　发现和解决数据库性能问题。
2. 　　为新应用设计数据模型和分片策略。
3. 　　评估和推行新的数据库。

　　起初是因为为需求所迫，但是我很快就对数据库着迷了。数据库的交叉研究几乎横贯了计算科学的每个领域——它的理论与实现都非常复杂，并且富有挑战性。 然而，我很快意识到这并非所有的人都像我一样热衷于数据库。对于我的很多同事与朋友而言，数据库是一个具有魔力的黑盒子系统，它不会太吓人太复杂了以至于不能理解。我想要改变一下这个现状。 当我们谈论到数据库时，分布式系统的话题是不能忽略的。大部分现代数据库都是分布式的，要么是隐式的(分布式集群数据库)，要么是显式的(通过应用程序级的分片连接到多个数据库的单个应用程序)。 这篇文章是我喜欢数据库与分布式系统的告白。它主要针对向我一样的程序员，经常接触数据库的应用开发者。我们主要用 Java、Python、或是 Ruby 编码，用来写服务端的应用。本文会覆盖到以下话题：

1. 　　比较和评估不同的数据库。
2. 　　如何理解和充分利用你的数据库。
3. 　　从大的层面上去理解数据库是如何工作的。

　一、首先，什么是数据库

　　在本文中，任何接收并存储数据以备将来获取之用的软件就是数据库。这包括了传统的 RDBMS 和 NoSQL 数据库，以及与 Apache Zookeeper 与 Kafka 一样的系统。

　二、CAP 理论

　　CAP 理论。这是继图灵的停机问题和 P≠NP (技术上不可解)后，我最喜欢的不可解问题。CAP 理论表明，任何分布式系统最多只能同时满足 CP(一致性 & 分区容忍性), AP (可用性 & 分区容忍性),或者介于这两者之间。因此，一致性与可用性之间有很有趣的权衡出现。 关于CAP定理几个重要的误解：

1. 　　传统的“三选二”争论是没有意义的。你不能抛弃分区容忍性，因为那意味着“在分区中执行的操作行为是不确定的”，而且在这种情况下，数据库并不是真正一致性的。
2. 　　到达 CAP 理论的限制并没有默认给定。有很多的数据库，它们既不是一致的，可用的，也不是分区容忍的。要实现 CAP 理论的限制需要精心的设计和实现。

　　三、分布式系统

　　如前所述，许多现代数据库都以某种方式实现了分布式。以下两点是推动数据库的分布式化的两个因素：

1. 　　为了规模上超越单机 —— 在多节点上存储和处理数据。
2. 　　为了增加可用性 —— 确保数据库不会发生单点故障。

　　这两个目标是相互紧密关联的。一般来说，通过增加机器数量来扩展系统会对可用性产生负面影响，由于发生单个机器故障的机会增加了。因此，实现高可用性几乎是可扩展性的先决条件。

　三、正确性与效率

　　正确性与效率，这两者都重要，并且在分布式数据库中两者也是紧密关联的。 在任何软件中正确性都是重要的，但是对于数据库来说它是必不可少的。以下的两个原因:

1.     数据库存储数据，错误的数据在重启后仍然存在。
2.     数据库被认为是软件栈(software stack)中最值得信赖的基础。

   数据库是正确的是什么意思呢?许多分布式数据库的代码很难懂，有惊人一致的语义。你可以在这里做一个权衡。在一般情况下，对于效率与可用性的成本来说，更严格的一致性使得编写应用程序更容易。 除了理论之外，还有实现与业务挑战的正确性。分布式系统本质上是复杂的。像 Paxos 这种算法是很难理解和正确实现的。随着系统越来越复杂，更多隐蔽的故障场景会出现。像 Redis 与 ElasticSearch 就承受了由他们分布式系统的非常规设计带来的考验。 除了上述的权衡，效率也是很重要的，因为以前遇到的困难。我学到越多的底层编码，我就更了解一台机器美秒可以执行多少原始操作(raw operations)。在许多情况下，效率降低了复杂度，使整个系统更简单。事实是分布式系统比底层编码更激发我去追求效率。在给定相同负载的情况下，我更乐意选择需要更少机器的数据库。 最后，用于机器间协调的计算和延迟开销会是很显著的。总之：运行的部件越少越好。 为了从代码中优化出更多的性能和效率，深入更底层的抽象中是必须的旅程，包括以下4点：

1. 　　内存分配 和 垃圾收集器 [2]
2. 　　文件系统调度 和 IO 设备特性
3. 　　内核设置
4. 　　各种系统调用的实现细节(fork，execv，malloc)

　　它们中产生任何的不协调，都会导致性能不佳。你不必成为一个内核黑客(kernel hacker)，但你需要对这些组件之间的交互有一定高度的了解。

　　四、给应用授权

　　因为不同的编程语言都有自己的优缺点，数据库也有自己独特的特点。完全理解它们是很重要的。它可以让你实现高效和复杂的应用程序，同时委托大部分复杂易错的工作给数据库。 一般来说，如果你没有严格的性能或可用性要求，那么传统 RDBMS 是一个好选择。ACID 的保证是非常强大的，而且工具也很不错。分片 RDBMS 虽然痛苦，但它是很好理解的。MySQL 和 Postgres 是两个普遍的选择。 全文搜索引擎允许你构建高级的索引和搜索功能。集成这些系统后的最终一致性，很少是个问题，因为搜索本身就是一个模糊操作。Lucene 和它的变种数据库(Solr，ElasticSearch)是普遍的选择。 消息队列和事件处理系统消除了那些很难正确和高效实现的代码。Kafka、Storm、Spark SQL、RabbitMQ 和 Redis 是普遍的选择。 具有跨域复制的数据库使得区域故障切换和高可用性容易地多。在这方面没有很多开源选择，但是 Cassandra 可能是最成熟的一个。 一致性，leader 选举(leader election)，以及分布式锁都是很难实现和测试的。不要自己去实现。用 Zookeeper 等，或者 raft 类库。 现在走向细节。数据库本身是一个抽象泄露(leaky abstraction)。他们一般在隐藏底层的复杂性上做了很好的工作，但是忽视其局限性最终会伤到你自己。以下四点是一些重要的东西：

1. 　　理解数据库的正确性保证。一个失败的操作是指什么[3]? 哪些操作是完全一致的，哪些又不是?
2. 　　理解数据是如何被存储和获取的。哪些操作是有效的，哪些又是无效的?有没有一个查询规划(query planner)，或者每个操作的详细统计信息?
3. 　　分片和集群架构。理解数据是如何在集群中分布的。你的分片策略均衡地分布数据了吗?或者有没有热点存在?
4. 　　数据建模模式和反模式。

　　五、业务挑战

　　一旦你的软件栈中的一部分，数据库和你的基础架构保证24*7提供不中断服务 。它就引入了独特的业务挑战。 操作数据库就像在海洋中航行。无论何时你遇到了问题，甚至是在风暴中心，你都要不让数据库下沉的同时解决它，。所以，数据库需要有以下三点：

1. 　　内省(introspect)和监视系统的方法。
2. 　　维护和管理系统的把手。
3. 　　复制，备份和恢复。丢失数据是极其糟糕的。机器会在某个点奔溃。由于数据库是有状态的，你不能简单地只部署代码。

　　在运行的同时具备以上所有。坦白得说，在这点上所有数据库都有缺点。在完全运行的同时允许任何配置都可以修改，是一个艰难的挑战。许多操作需要一个数据库层面的互斥量，额外的系统资源，或者重新启动。例如包括以下两点：

1. 　　在 MySQL 5.6 以前，添加一列需要全表锁，而黑客们喜欢 pt-online-schema-change 的存在就是为了缓解这一问题。MySQL 现在支持在线模式迁移。
2. 　　Cassandra 允许你简单地添加、删除、和修复节点。然而，这些操作给系统添加了额外的负载，而且需要容量空间。

　　另外，你不能简单的替换一个数据库。即使是在同一数据库内迁移数据的任务也不简单。迁移到另一个数据库中更是难上加难，如果不是不可行[4]。一个应用程序的代码是非常容易逐步铺开并恢复(如果需要的话)的。数据比代码存活地更久。数据模式和存储的数据通常会在多个应用程序之间共享。因此，初始的数据库系统和对应的数据模型的选择是非常重要的。 最后，数据库总会发生故障。不管你用的是什么平台/服务即架构，有些故障是避免不了的，如下所示：

1. 　　应用程序代码弄脏或丢失数据的 Bug 。
2. 　　误解了数据库的安全性和一致性保证，丢失了写操作。
3. 　　数据模型和数据库不匹配 —— 例如，有一个数据集并不适合在一个独立 shard 上。期待原子切换(compare-and-swap)到最终一致性的数据库中工作。
4. 　　运行故障 —— 机器崩溃。硬盘损耗。操作系统升级。
5. 　　网络分区[6]。
6. 　　惊群效应 —— 单个系统故障，并级联到其他系统。
7. 　　而最糟糕的是 —— “突然慢下来了”。“随机尖峰延迟”。“每天一次偶发错误”。“这条记录应该存在但是没有了”。

　　对于这些却没有单一的解决方法。操作数据库的艺术真的属于维护一个高 SLA 系统的艺术，但是如果我需要给出一些技巧，如下所示：

1. 　　应用程序开发人员理解的限制和故障模式的行为。
2. 　　编写一个有弹性的应用程序。多数据中心部署。自动故障转移。
3. 　　拥有一支由熟悉业务并且了解不同故障场景和恢复方法的工程师(网站可靠性工程师，DBAs)所组成的队伍。

　　PS:在 Square ，我们有一个超酷的在线数据存储(ODS)团队把这些问题从我们这里抽离出去。

　　六、基础构建模块

　　通过数据库提供的抽象真的很神奇。数据提取(ingestion)，查询，复制，以及故障恢复都在同一个包里?但是当你习惯了它，你就开始认识到有一些基础的构建模块 —— 在所有数据库之间共享的通用模式和组件。 首先，数据检索降低了以下所说中的一个：

1. 　　键值查找(哈希表)
2. 　　范围查找(树和 LSM 树)
3. 　　文件偏移量查找(Kafka，HDFS)

　　在本文的最后，我想说的是，电脑并不懂 SQL、索引、联接、或者是其他的花哨的装饰。上层的操作需要被翻译成机器能执行的东西。 对于可持久化数据结构，B-trees， hash tables，和 LSM树 (log-structured-merge-trees)都是很普遍的选择。很可能你的数据存储在其中的一个，除非它需要一些特定的查找(例如：地理空间查询)。LSM 树是一种流行的现代的选择，在BigTable，HBase， Cassandra， LevelDB， 以及 RocksDB 中都有使用，因为其一流的写入性能和合理的读取性能。 最后，还有流行的模式和算法用于整个不同的系统： Paxos, Raft, 一致性哈希, Quorum 读/写, Merkel 树, 以及 Vector Clocks 都是一些基本的构建模块。

　　七、总结

　　这篇文章是对一些话题的简单、高度概括。还有很多话题我没有涉及到，诸如对不同工作流的优化(OLAP、OLTP、批处理)和数据库的UX(查询语言、传输协议、客户端类库)，这些都是同等重要的。不同语义一致性的影响，诸如sequential consistency, read your own write, at least once delivery 都是非常有趣的。 关于数据库最棒的事情就是它是一个非常成熟的抽象。它大部分都在工作，而作为一名应用开发者，你可以不用思考就能非常容易地保存和读取数据。这绝对是值得庆祝的，但是为了这足够先进的技术脱层皮也确实是值得的。 我希望有更多的人能被这个主题深深吸引，并充分利用它。

　　八、参考文献和旁注

　　[1] 你不能牺牲分区容忍性 —— http://codahale.com/you-cant-sacrifice-partition-tolerance/。Aphy’rs Jepsend 的文章是一个很好的入门资源 —— http://aphyr.com/tags/Jepsen [2] 现代数据库频繁地利用OS文件系统缓存显著地加速文件系统的访问。未使用的内存自动地被用作缓存。这样一个系统的推荐生产配置对于没经验的人来说是不寻常的，机器有90%的内存是空闲的。 [3] 在基于类似 dynamo 的 quorum 系统中的常见缺陷是写故障时没有给出任何信息。当没有按时写入到内部副本时，写操作可以在客户端外部失败。因此，失败的写操作是非常容易成功。最糟糕的是，在最后写成功(last-write-wins)解决策略和倾斜的系统时钟下，以后的写入操作可以被这次的写入故障覆盖。 [4] 在数据库之间迁移涉及到了在多个数据库之间同时做读写操作。数据的所有者(俗称“真相来源”)是不确定的，而在新旧系统之间做同步可能会有数据的丢失。 [5] 在初创公司的基础架构中，应用程序的 bug 可能是可靠性和可用性最大的罪犯。扩展和性能问题是可以被预测到的，而当你有一把服务器的时候，硬件故障通常不能被预见。然而，每天都会有新代码部署上线。 [6] 从网络是可靠的 —— 网络分区比你想象的还要常见。从根本上说，没有办法区分高延迟、网络分区、GC 停顿、和机器故障 —— 他们的表现都是低速连接。在 ElasticSearch 中这是一个普遍面临的问题。一个节点正在遭受一个大 GC 停顿，而整个集群认为这个节点挂了，然后试图重新分配数据，一连串的问题出现了。

　　九、多数据库

　　一旦一个系统与多个数据库有交互了，系统就是最终一致性了。除非你实现了两阶段提交协议(2PC)，你不能在同一时刻并发地修改多个数据库，这类似于“原子操作的成分是不是原子”。

　　十、关于删除

　　在任何的分布式系统中，删除数据是困难且危险的。数据到处都被复制，不管是数据库还是应用程序。没有一个适当的协调，被删除的数据被恢复回来是不可能的。一种典型的处理方法是写一个tombstones记录来代表删除,然而， tombstones 有他们自己的问题，如下所示 ：

1. 　　Tombstones 占据硬盘空间。为了回收硬盘空间，tombstones 必须到期。如果 tombstones 在完全复制前过期且被删除了，已删除的记录可以被复制回来。
2. 　　你可以用一个旧的 tombstone 来删除一个将来的写操作。这被通俗地称为厄运石头(doomstone)。搞笑的是，这是一个现实存在的问题。