评价分布式事务数据库的5个标准

你知道吗？二手交易网转转的数据库用的是什么？本文由TiDB / TiKV的首席架构师Ed Huang发表，虽然有软文嫌疑，但是从其研发的最先进分布式数据库经验角度看，这五个问题还是很干货的。TiDB/TiKV分布式数据库是一种高一致性的分布式事务数据库，存储使用Rust编写，SQL计算使用Go语言，语言工具选择上也是很棒的。

下面是原文大意：

当我第一次与我的联合创始人一起开始构建TiDB时，我们遇到了无数的挑战、陷阱和关键设计的选择，这些可能会导致项目失败，要从头开始构建像TiDB这样的企业级分布式数据库，我们必须不断做出艰难的决策，以平衡开发速度和客户及团队的长期考虑。

三年后发布了两个重要版本，TiDB 2.0现已部署在200多家公司的生产环境。在此过程中，我们的团队在评估TiDB和其他分布式数据库时回答了用户的许多问题。在基础架构堆栈中进行选择使用是一个重要的决定，并不是一个简单的决定。所以我收集了多年来我们的经验，并将它们总结为以下每个工程师在查看分布式数据库时应该问的问题。

1.为什么分布式数据库不是银弹？
没有任何一种技术可以成为你所有问题的灵丹妙药，数据库领域也不例外。如果你的数据可以用一个MySQL实例解决，而不会对服务器造成太大压力，或者对复杂查询的性能要求不高，那么分布式数据库可能不是一个好的选择。选择使用分布式数据库通常意味着额外的维护成本，这对于小型工作负载来说可能是不值得的。如果你需要针对小型工作负载的高可用性（HA），则使用MySQL的主从复制模型及其GTID解决方案可能足以完成工作。如果还不够，你可以使用组复制扩展它。由于MySQL社区非常活跃，因此Google一下几乎可以解决任何问题并找到解决方案。简而言之，如果单个实例数据库足够，请坚持使用MySQL。当我们第一次开始构建TiDB与MySQL兼容时，我们的目标永远不是取代MySQL，而是解决单实例数据库本身无法解决的问题。

如果你的数据可以适用于单个MySQL实例而服务器上没有太大的压力，那么分布式数据库可能不是一个好的选择。

那么何时适合部署像TiDB这样的分布式系统？就像对任何难题的任何答案一样，这取决于：我并不想给出一个通用的答案，但在决定分布式数据库是否是正确的答案时，还有一些迹象信号。例如：

发现自己在考虑如何复制、迁移或扩展数据库以获得额外容量？
寻找优化现有存储容量的方法？
关注慢查询性能？
研究中间件扩展解决方案或实施手动分片策略？

如果你发现自己定期询问这些类型的问题，那么就应该考虑像TiDB这样的解决方案是否可以帮助你。

MySQL和TiDB不是互斥的选择。实际上，我们花了大量的工作来帮助我们的用户继续使用MySQL，通过构建工具来实现从MySQL到TiDB的无缝迁移。这保留了同时使用MySQL用于单个实例工作负载的选项。

2.为什么要将SQL与存储分开？
有几个原因可以解释为什么要将SQL与底层存储分开。(banq注：计算和存储分离)

（1）易于维护。我们将TiDB平台的SQL层（无状态，也称为TiDB）与其存储层分离（负责存储称为TiKV））以使得部署，操作和维护更简单。这是我们的最重要的设计选择之一。这可能看起来违反直觉（不是更多的组件使部署更复杂吗？）。好吧，作为一个DevOps不仅仅是进行部署，而且还可以快速隔离问题，系统调试和整体维护 - 模块化设计真正支持这些职责。例如：如果你的整个系统融合在一起而不是单独分层，一旦你在SQL层中发现需要紧急更新的错误，那么滚动更新可能非常耗时，具有破坏性，甚至存在风险。但是，如果你的SQL层是无状态且分离的，则更新很容易，并且不会破坏系统的其他部分。

（2）更好的资源使用。模块化设计也更适合资源分配和使用。存储和SQL处理依赖于不同类型的计算资源。存储严重依赖于输入输出（I / O），并受硬件类型的影响，例如PCIe / NVMe / Optane SSD。SQL处理更依赖于CPU功率和RAM大小。因此，将SQL和存储放在不同的层中有助于使整个系统更有效地使用适当类型的资源进行正确的工作。

TiDB旨在支持HTAP（混合事务和分析处理）体系结构，同时支持OLTP和OLAP工作负载以出色的性能进行处理。每种类型的工作负载都有不同的优化，需要不同类型的物理资源才能产生良好的性能。OLAP请求通常是长而复杂的查询，需要大量RAM才能快速运行。OLTP请求短而快，因此必须根据OPS（每秒操作数）优化延迟和吞吐量。由于TiDB的SQL层是无状态的并且与存储分离，因此它可以通过应用其SQL解析器和基于成本的优化器在执行之前分析查询，智能地确定哪种工作负载应该使用哪种物理资源。

（3）开发灵活性和效率。使用单独的键值抽象来构建低级存储层有效地提高了整个系统的灵活性。它可以轻松提供水平可伸缩性 - 使用key自动分片比使用具有复杂模式和结构的表更容易实现。单独的存储层也为利用分布式系统中的不同计算模式开辟了新的可能性。

TiSpark是我们利用Spark的OLAP引擎，就是这样一个例子，它利用我们的层设计，位于TiKV之上，直接从它读取数据，而不受TiDB的任何依赖或干扰。从开发角度来看，分离允许使用多种编程语言。我们选择Go是一种高效的语言来构建TiDB并提高我们的生产力，而Rust是一种高性能的系统语言，用于开发速度和性能至关重要的TiKV。如果整个系统没有模块化，则不可能采用多道程序设计语言方法。我们的分层架构允许我们的SQL团队与我们的存储团队并行工作，并且我们使用RPC（更具体地说是TiDB中的gRPC）来实现组件之间的通信。

3.为什么延迟不是首要考虑目标？
很多人问我：TiDB可以取代Redis吗？不幸的是，因为TiDB根本不是缓存服务。TiDB是一种分布式数据库解决方案，首先支持具有强一致性，高可用性和水平可伸缩性的分布式事务，其中数据在多台计算机（或多个数据中心）上持久化和复制。简而言之，TiDB的目标是成为每个系统的“真相之源”。但是为了使所有这些功能在分布式系统中发生，一些与延迟有关的权衡是不可避免的（相反，任何争论都在藐视物理学）。因此，如果你的生产场景需要非常低的延迟，比如说不到1毫秒，那么你应该使用像Redis这样的缓存解决方案！实际上，我们的许多客户都在TiDB之上使用Redis，因此他们可以结合可靠的“真相之源”实现低延迟。

相对延迟指标，对分布式数据库的更有意义的测量标准是吞吐量。如果系统的吞吐量随着添加到系统的机器数量（更多机器，更多吞吐量）线性增加，而延迟保持稳定，那么这是一个强大的分布式数据库的真实标志。我们的一些生产用户已经在TiDB集群上每秒处理多达100万个查询; 在单台机器上几乎不可能达到这种吞吐量水平。

我们在PingCAP中有一句话，“在快速行动之前做好准备。”正确性，一致性和可靠性总是胜过速度。没有它们，低延迟有什么用呢？

4.基于范围(Range-Based)的分片是否优于基于散列的分片？
我们在TiKV中实现了基于范围的分片而不是基于哈希散列，因为我们的目标从一开始就是支持功能齐全的关系数据库，关系数据库必须支持各种类型的扫描操作，如表扫描，索引扫描等，尽管基于范围的分片更难构建，但基于散列的分片无法按顺序维护指定表的数据，因此即使在基于散列的设置中的几行上进行小扫描也可能意味着在多个分片之间跳转节点服务器。基于范围的分片则不会出现此问题。

当然，这并不意味着基于范围的分片不具有自己的权衡。例如，如果你的查询模式主要是顺序写入，其中写入操作远远超过非更新或非删除的读取（如日志），则可能形成热点。对于这种情况，我们计划使用分区表作为解决方案，以减轻由此写入模式引起的系统压力（这是我们2018年的路线图））。另一种难以解决的情况是，如果你的请求模式包含恰好位于同一Raft区域的小型表上的频繁读/写。现在，每个TiKV Raft区域按顺序键值对分割，默认为96MB。如果频繁读/写的一个小表大小小于96MB，则无疑会形成热点，唯一的解决方案（到目前为止）是将该区域手动拆分为两个并在不同节点上重新分配它们。这个“修复”不会解决热点问题，但只是通过缩小热点来缓解它。这是分布式数据库不适合解决的问题，因此如果你有这种类型的请求模式，我们建议你使用内存缓存层，如Redis，或者将这个小表直接放在你的应用程序中层。

5.为什么可伸缩性对业务如此重要？
当一家公司开始规模较小时，任何数据库和基础设施都可以运行，但当该公司开始出现爆炸性（通常是意外的）增长时，你选择的基础架构技术就会非常重要。根据你的业务需求做出正确的选择，可以轻松地向任一方向扩展，这可能意味着你公司的生死存亡。

我们都记得Twitter臭名昭着的“ 失败的鲸鱼fail whale ”，因为这项服务不仅因用户增长而不断下降，而且基础设施也很糟糕。当你的数据库成为瓶颈时，解决方案不是手动对表进行分片，牺牲关系功能，制作同一个表的一堆副本，并冲洗并重复这个恶性循环。正确（且最具成本效益）的方法是使用可弹性扩展的分布式数据库，因此你所要做的就是添加新机器以增加容量。增加更多的机器可能看起来成本越来越高，但与人力资源节省的成本和在竞争环境中响应和适应所需的宝贵工程时间相比，它要便宜得多。

概要
当我们第一次开始设计和构建TiDB时，我们从我们自己的经验和其他DBA和基础设施工程师那里学到了很多教训。一个真正有用且强大的分布式数据库应立即解决可伸缩性瓶颈并使所有“快速修复”如手动分片过时，因此应用程序开发人员可以专注于做他们最擅长的事情 - 为客户提供服务并发展业务，而不是管理数据库分片。

最近，我们看到我们的两个用户，Mobike（无人驾驶自行车）和转转（在线市场，banq注：也许就是中国的那个转转）就是这么做的。这两家公司都经历了爆炸式增长，并且因为他们在这种增长腾飞的过程中部署了TiDB，他们的数据库基础设施并不是阻碍他们以这种方式发展的瓶颈。实际上，转转是对TiDB赌注全押，因为它知道精心打造的分布式数据库对其未来至关重要。

5 Questions for Evaluating a Distributed Database
[该贴被banq于2018-08-16 08:45修改过]