分布式数据库其实不好做

2022-11-29 18:36:16

现在国产数据库据说已经突破300种了，厂家也有近200家，这些数据库产品中，大多数都是分布式数据库。不仅仅是中国，其实这些年国外的新数据库产品中，分布式数据库也占了很大的比例。这是为什么呢？分布式数据库更容易开发吗？还是用户更需要分布式数据库呢？

实际上我并不是用户，用户才是对这个问题有发言权的。他们了解自己的应用的痛点，提出的需求往往都是比较现实的。不过我们常年和数据库的用户在一起摸爬滚打，对用户的需求还是有所了解的。

大概7、8年前吧，一个互联网公司想研发一款商用数据库产品，在一个聚会上，大家讨论客户需要什么样的数据库。我总结了三个词：“简单、稳定、安全”，随后根据这三个词扩展为能够组建大型服务器集群，利用分布式架构可以十分方便的动态扩展，无需备份，能够实现自动容灾。同时数据库可以永远在线，不会宕机，并且永不出错，于是大家决定开发一款分布式数据库。

其实要实现后两点是十分困难的，一个BUG足以让整个集群宕机，甚至出现数据错误或者丢失。大概十年前，某国产分布式数据库就出现过分区表数据写错分区的BUG，导致部分数据丢失。

根据上述的需求，对目标数据库产品提出的四个要求，一个是无限容量，无论客户有多大的表，都能够应对自如，访问快速是能够提供高并发的快速相应，永不停服是能够自动感知故障，自动隔离故障，从而确保7*24稳定服务。同时通过强一致性保障，异地多分数据来确保数据库的安全可靠。

数年过去了，后来和这个产品项目组的朋友交流，有个朋友说，当时把数据库想的有点简单了。实际上这个目标目前依然还是我们的数据库厂商的追求目标，可能已经离得更近了，但是还是无法触摸到这个目标。这是因为数据库系统太复杂了，应用场景太复杂了，IT基础设施的可靠性也不像我们想象的那么强大，再加上我们人类的逻辑思维能力太有局限性了。单单通过基础架构上的革命，想要实现我们设定的目标，是远远不够的。必须把IT基础设施看成是数据库的一部分，统一在核心代码中进行管理，才能真正的做到为用户屏蔽大部分硬件故障。

大概是2017年吧，我和Yellowbrick的Nile交流的时候，他认为分布式数据库太复杂了，只有提供完全工程化的一体机才能确保他们的分布式数据库高效、稳定的运行，因此他们只准备出数据库一体机，并不准备提供通用软件让客户自建数据库系统。当时我对这种商业模式提出了疑问，这种昂贵的软硬一体产品是不是能够获得商业上的成功。在推出类似一体化解决方案的厂商中，目前来看只有两个成功者，Oracle和Teradata，GreenPlum算半个成功者，SAP的HANA终也只能向通用硬件妥协才能得到市场的认可。

几年前我们想要达成的目标中，“更易于使用”这一点实际上至今仍然没有达成。虽然说从整体架构上的高可用性，冗余设计理论上能够屏蔽部分硬件故障，但是这仅仅限于宕机，硬件完全损坏这种极端故障。对于忽好忽坏，忽快忽慢，性能毛刺这种问题的自动容忍需要通过在数据库核心代码中做大量的处理，甚至优化OS底层代码才能够真正实现，而我们的绝大多数分布式数据库厂商十分流氓的把这些问题都归结为和数据库无关的IT基础设施问题，需要用户自己去优化IT基础设施来解决这些问题。这实际上是把一些运维上相对简单的比较明显的故障都处理了，而把运维中难解决的问题全部交给用户了。

和集中式数据库相比，现在的绝大多数分布式数据库对IT基础设施可靠性的要求并不是更低了，而是更高了。因为大部分分布式数据库的核心代码中只是考虑了对SQL的实现和数据的存储，并没有能够从底层自动感知存在的各种对数据库运行稳定性、性能、并发能力有极大影响的隐患故障，因此也无法在代码中对这些问题从数据库的角度进行处理，从而实现自动规避问题。在一些大厂的分布式数据库产品的实现算法和代码中，我们看到了不少这方面的容错设计，而对于大部分小厂产品来说，可能开发者都没有很好的去考虑过这个问题。

分布式数据库厂商总是喜欢用互联网大厂的成功实践来证明分布式数据库的能力与使用分布式数据库的必要性。很多数据库厂商都喜欢说自己的产品设计灵感来自于谷歌的Spanner。实际上，我以前对Spanner没有做什么分析研究。为了研究分布式数据库，我稍微了解了一下他们的老祖宗Spanner。大家很有兴趣讨论Spanner实现GTM的True Time，说谷歌使用了昂贵的铯原子钟来作为授时中心，所以很昂贵。听到这里我大概就了解了他实际上并不太了解谷歌TRUE Time的实现方式。谷歌的全球数据中心是采用GPS授时的，铯原子钟只是一个备胎，当GPS授时失败时接管而已。实际上保证谷歌Spanner“稳定的慢”的并不是铯原子钟，而是谷歌在广域网上巨大的投资和强大的优化能力，确保网络延时低于7ms是谷歌Spanner的成功密码。他们的TRUE Time不是一个确定的时间，而是一个7毫秒的时间区间。能够具备这种强大的广域网优化能力的企业是屈指可数的，能够花得起这个钱的企业更是凤毛麟角。因此SPANNER只能是一个膜拜的对象，而不可能飞入寻常百姓家了。谷歌的这种超大型分布式数据库是一个昂贵的工程化的产物，并不能作为一个通用的数据库产品去销售，这也是前些年惊呼狼来了的数据库届并没有看到谷歌把Oracle赶下王座的主要原因。

因为分布式数据库的IT基础设施比集中式数据库更为复杂，因此分布式数据库需要有大量的基础数据探测和分析能力，从而发现IT基础设施中主机、网络、存储、时间、资源、负载等的一系列变化，并且随时针对出现的异常隐患提前进行处置，这样才能实现真正的无需运维人员过多干预的高效自治运行。而实际上我们的分布式数据库厂商大多数在这方面的能力并不足，甚至很多数据库研发人员对网络，OS的核心知之甚少。这样就让分布式数据库成为了一个工程化的产品，不是开箱即用的，而是需要在IT基础设施上做大量的工程化施工和优化，这样就让分布式数据库产品的应用与运维变得更复杂了。

我也和很多分布式数据库的使用者做过交流，他们普遍都遇到过一些运行问题。不像集中式数据库出问题后能够有一定的思路去分析和解决。实在不行，数据库重启一下，服务器重启一下也就解决问题了。大数据分布式数据库出现故障的时候，运维人员是束手无策的，产品手册上并没有告诉你遇到这样的问题是不是关闭一个故障节点就能解决问题，还是去杀掉一些会话就能恢复。因此运维人员只能看这出问题的系统，等着故障消失，或者等着业务高峰快点过去。

开发出一个分布式数据库并不是太难的事情，国内大量涌现的分布式数据库厂商就已经说明了这个问题了。不过要做好一款分布式数据库产品并不容易，要做出一款开箱即用，运维简便的分布式数据库产品就更不容易了。我想，目前的大多数分布式数据库产品可能还只是处于成熟度曲线的前期，只有当我们的分布式数据库产商能够全面感知数据库与IT基础设施的各种变化，并把IT基础设施与数据库本身的风险处置都纳入到核心代码中，让异常处置能力更强大了，分布式数据库产品才能成为只有大企业才玩得转的工程化产品变成通用型的老少咸宜的大路货了。