现在国内的数据库据说有300多种，生产厂商也有将近200家。这些数据库产品大多是分布式数据库。不仅在国内，实际上在国外近几年新出现的数据库产品中，分布式数据库也占了很大的比重。为什么是这样？分布式数据库更容易开发吗？还是用户更需要分布式数据库？其实我不是用户，在这个问题上最有发言权的是用户。他们了解应用程序的痛点，而且他们的需求往往更切合实际。但是我们常年和数据库用户打交道，对用户需求还是有一些了解的。大约七八年前，一家互联网公司想开发一款商业数据库产品。在一次聚会上，大家讨论客户需要什么样的数据库。我总结了三个词：“简单、稳定、安全”，然后在这三个词的基础上进行扩展，能够形成大规模的服务器集群。采用分布式架构可以非常方便的进行动态扩展，无需备份，并且可以实现自动容灾。同时数据库可以一直在线，永不宕机，永不出错，所以我们决定开发一个分布式数据库。事实上，要做到最后两点是非常困难的。一个bug就足以导致整个集群宕机，甚至出现数据错误或丢失。大概十年前，国内的一个分布式数据库有一个bug，分区表数据写错了分区，导致部分数据丢失。根据以上需求，目标数据库产品有四个需求，一是无限容量，无论客户有多大的表，都可以处理自如，快速访问意味着可以提供高并发和快速响应，永不停止服务意味着它可以自动感知故障并自动隔离故障，以确保7*24的稳定服务。同时，通过强一致性保证和多地数据分布，保证了数据库的安全性和可靠性。几年过去了，后来跟这个产品项目组的朋友交流。有朋友说当时数据库有点简单。其实这个目标还是我们数据库厂商追求的目标。或许更近了，但依然无法触及这个目标。这是因为数据库系统太复杂，应用场景太复杂，IT基础设施的可靠性没有我们想象的那么强，我们人类的逻辑思维能力太有限。仅仅通过革新基础设施来实现我们设定的目标是远远不够的。必须将IT基础设施视为数据库的一部分，在核心代码中统一管理，才能真正为用户屏蔽大部分硬件故障。大概是2017年，和Yellowbrick的Nile交流的时候，他觉得分布式数据库太复杂了。只有提供完全工程化的一体机，才能保证他们分布式数据库的高效稳定运行，所以他们只准备发布数据库一体机，并没有准备为客户提供通用软件建立自己的数据库系统。当时我就质疑过这种商业模式，这种昂贵的软硬件一体化产品能否取得商业上的成功。在推出类似集成解决方案的厂商中，目前成功的只有Oracle和Teradata两家，而GreenPlum算得上是成功的一半。SAP的HANA只能向通用硬件妥协，才能获得市场认可。几年前我们想要实现的“更易用”的部分实际上还没有实现。虽然就整体架构的高可用而言，冗余设计理论上可以屏蔽部分硬件故障，但这仅限于宕机和硬件完全损坏等极端故障。好坏、快慢、性能故障等问题的自动容忍，只能通过在数据库核心代码做大量处理，甚至优化OS底层代码来实现。我们大部分的分布式数据库厂商都很流氓，把这些问题归咎于IT基础设施问题，与数据库无关，用户需要优化IT基础设施来解决这些问题。其实这是为了处理运维中一些比较简单明显的故障，把运维中最棘手的问题全部交给用户。与集中式数据库相比，当今的分布式数据库大多对IT基础设施的可靠性要求更高而不是更低。因为大多数分布式数据库的核心代码只考虑了SQL的实现和数据存储，并没有从底层自动感知到对数据库的稳定性、性能、并发有很大影响的各种隐患的存在，所以无法从数据库的角度去处理代码中的这些问题，从而自动规避问题。在一些大厂的分布式数据库产品的实现算法和代码中，我们看到了很多这方面的容错设计，但是对于大部分小厂的产品，开发者可能没有考虑好这个问题。分布式数据库厂商总是喜欢用各大互联网公司的成功实践来证明分布式数据库的能力和使用分布式数据库的必要性。许多数据库供应商喜欢说他们的产品设计灵感来自谷歌的Spanner。其实之前我并没有对Spanner做过任何分析研究。为了研究分布式数据库，稍微了解了一下他们的老祖宗Spanner。大家对讨论Spanner对GTM的TrueTime的实现很感兴趣，说谷歌用昂贵的铯原子钟作为时间服务中心，所以很贵。听到这里，我大概明白了，其实他对Google的TRUETime的实现了解不多。谷歌的全球数据中心使用GPS授时，铯原子钟只是一个备用轮胎，在GPS授时出现故障时接管。事实上，保证GoogleSpanner“稳而慢”的并不是铯原子钟，而是Google在广域网方面的巨大投入及其强大的优化能力。保证网络延迟小于7ms是GoogleSpanner的成功密码。他们的TRUETime不是一个确定的时间，而是一个7毫秒的时间间隔。能够拥有这种强大的广域网优化能力的企业屈指可数，能负担得起的企业就更少了。因此，SPANNER只能是供奉的对象，不可能飞入寻常百姓家。Google的超大型分布式数据库是一个昂贵的工程产品，不能作为通用数据库产品销售。下王位的主要原因。由于分布式数据库的IT基础设施比中心化数据库复杂，分布式数据库需要大量的基础数据检测和分析能力来发现系统中主机、网络、存储、时间、资源、负载等方面的问题。IT基础设施。一系列的变化，并随时提前处理异常隐患，实现真正的高效自主运行，不需要运维人员的过度干预。事实上，我们的大多数分布式数据库厂商都没有这方面的能力，甚至很多数据库开发人员对网络和操作系统的核心知之甚少。这使得分布式数据库成为一个工程产品，不是开箱即用的，而是需要在IT基础设施上进行大量的工程建设和优化，使得分布式数据库产品的应用和运维变得更加复杂。我也和很多分布式数据库的用户交流过，他们普遍都遇到过一些操作上的问题。不像中心化的数据库，出现问题后可以有一定的思路去分析解决问题。如果还不行，重启数据库，重启服务器即可解决问题。当大数据分布式数据库出现故障时，运维人员束手无策。产品手册并没有告诉你是关闭故障节点来解决问题，还是杀死一些会话来恢复。因此，运维人员只能看着有问题的系统，等待故障消失，或者等待业务高峰快点过去。开发分布式数据库并不太难。国内众多的分布式数据库厂商已经说明了这个问题。但是，做好一个分布式数据库产品并不容易，而做出一个开箱即用、易于运维的分布式数据库产品更是难上加难。我认为目前大部分的分布式数据库产品可能只是处于成熟曲线的早期阶段。只有当我们的分布式数据库厂商能够充分感知数据库和IT基础设施的各种变化，将IT风险处理本身融入到核心代码中，使得异常处理能力更强，分布式数据库产品才能成为工程只有大企业才能玩的产品，成为老少皆宜的通用商品。
