😇New SQL数据库还能继续New吗 - 读Andy Pavlo ‘What's Really New About New SQL’
date
Feb 3, 2024
slug
NewSQL_New
status
Published
tags
Database
Distributed System
summary
距离我正式入门数据库已经过了快要两年了，现在是一个非常好的时间去回顾一下这几年OLTP的发展和展望一下未来的方向。
type
Tech
lang
zh
在数据库的市场上，打破一家百年企业的垄断是很困难的。你必须经历从0到1写数据库的阵痛，也必须一块城池一块城池的从老牌劲旅手中抢下来。NewSQL的挣扎就在于此：他是一个伟大的想法，但是在商业化中却处处碰壁。想搞清楚他们又遇到了哪些问题，我们得首先知道NewSQL到底在New什么。
而这一切又得先从NoSQL说起。
一场针对传统数据库的变革
在2000年后NoSQL数据库创造了一代神话。
随着互联网模式的兴起，传统SQL数据库已经没办法支撑成倍增长的业务量。互联网带来了大量的数据，也对现有数据库的数据处理能力发出了几个主要的挑战：
- 具有快速处理数据的性能，并且这种性能要有高扩展性以应对未来疯狂增加的数据量
- 具有高可用性，不能因为某个服务器的崩溃而造成整个业务的雪崩。
而只能部署在单一服务器，并且功能臃肿的传统数据库，比如MySQL，Postgres等很明显已经不足以解决这些问题。传统数据库站在了十字路口，大家纷纷对其开始大刀阔斧的“改革”。
2005年Google发表了Big Table，随后redis，Cassandra，Dynamo这些区别于传统的数据库涌现了出来，彻底炒热了NoSQL。NoSQL相比于传统的数据库有着本质的区别，其彻底放弃了SQL。具体来讲：
- 放弃了对传统SQL对数据模型的严格要求，NoSQL数据库基本都是秉着啥都能存的原则
- 放弃了对数据“正确性”的追求，基本上不会对用户做出任何强一致性的保障
- 放弃了对数据库事务的支持，用户必须从应用层上去处理这些相关的业务要求。
- 增加了可扩展性，用户可以很轻易添加更多的服务器去得到更好的数据处理的性能
- 可用性也得到了很大的改善，数据一般都被复制到了很多个不同的服务器上，某一两个服务器崩溃并不会对业务造成任何影响。
这些新增加的特点很好的迎合了当下成倍增加的业务量。比如Dynamo DB很好的帮助了亚马逊电商平台快速处理巨量的交易量，据亚马逊自己所说，Dynamo每天要支撑亚马逊电商超过一千万次请求， 和超过三百万次付款。很多风投和创业公司也加入到了NoSQL的阵营。其中最有影响力的是MongoDB，NoSQL的热潮成功帮助让它在2017年上市纳斯达克，并且在接下来的6年里增长了10倍。
新时代SQL数据库的复辟
NoSQL并没有解决所有问题，相反的是它加剧了一些行业的痛点：比如对数据“准确性”有极高要求的金融产业。在这个全球化的时代金融产业不仅需要高可用的数据库，需要数据的强一致性，也需要数据库提供事务的支持。NoSQL明显无法成为这个领域的答案。其次，即使是对一般应用而言，使用NoSQL也增加了很多负担。如果数据库没办法提供数据准确性和事务支持的话，这些重担就会逐渐落在开发者身上。上层应用需要很多复杂的逻辑去处理不一致的数据所导致的一些异常，长期下就会形成或大或小💩。NoSQL领头羊之一的Google也发现了类似的问题：
We believe it is better to have application programmers deal with performance problems due to overuse of transactions as bottlenecks arise, rather than always coding around the lack of transactions. （我们认为，最好让程序员处理由于过度使用事务而导致的性能问题，而不是在缺少事务的情况下写代码)
从我自己和Dynamo DB打交道的过程中也有类似的经历：由于Dynamo对事务的支持十分有限，我会写很多更复杂的逻辑去避免会发生的问题。
而另一个契机则是在摩尔定律下硬件的价格大幅的下降，使得服务器性能和网络带宽进一步增加。如果SQL数据库更高效利用这些硬件优势，那么就能保持NoSQL优势的同时，也拥有传统数据库的对数据“准确性”的支持。
在这个情况下，NewSQL数据库悄然崛起。NewSQL采取的是既要又要的策略：既要有NoSQL的高可用性，高可扩展性，同时也要支持传统数据库的事务和强一致性。
在这个时间段兴起了大量的NewSQL数据库: NuoDB, VoltDB, Spanner, CockroachDB, YugabyteDB, Pingcap等（其中yugabyteDB坚称自己不是 NewSQL而是Distributed SQL，但是在我看来两者其实是一个东西）
其中最值得讲的是Google spanner，spanner利用google研发出来的硬件搭起了能分布在全球的高可用数据库，它不仅能提供事务和数据最强一致性的保障，同时可扩展性也能追上NoSQL。在Google 自己发表了一篇文章详细介绍了spanner是如何用Truetime API去做到所有这些功能的同时也不牺牲性能，方法非常的聪明和优雅。有时间我新开个Blog仔细讲讲。
既然New SQL整合了传统SQL数据库和NoSQL数据库，那么至少也应该像NoSQL一样火的一塌糊涂吧！我花时间查了一下主要业务是做NewSQL公司的资料（我能想到和查到的大公司）：
Database | popularity score (by DB engine) | What Happens now |
NuoDB | 1.18 | 被Dassault Systèmes 收购 |
Clustrix | 无 | 被MariaDB收购，但2023年正准备砍掉该业务 |
ScaleArc | 0.87 | 被IgniteTech 收购 |
GenieDB | 无 | 倒闭 |
Xeround | 无 | 倒闭 |
CockroachDB | 6.60 | 正常运营 |
PingCap | 4.35 | 正常运营 |
YugabyteDB | 3.47 | 正常运营 |
PlanetScale | 2.05 | 正常运营 |
VoltDB | 1.95 | 正常运营 |
卧槽怎么回事？为什么有一半不是倒闭就是被收购？而幸存下来的公司数据库流行度得分都不是很高（对比NoSQL当红炸子鸡MongoDB417.48的得分和老牌劲旅DynamoDB 80.94的得分，或者传统数据库百年老店Oracle 1247.49的得分）特别值得注意的是，NewSQL兴起到现在已经过了10年了，流行度榜单前20只有一个MariaDB 勉勉强强算有着NewSQL的业务，其他的一个都不在榜单上。
NewSQL给我们讲了那么美好的一个故事，看起来势必会一统传统SQL数据库和NoSQL数据库江山，为什么到头来一个Top级别的都没有？
注定不是一条好走的道路
NewSQL的失败和技术或者项目质量没有太大关系。很多NewSQL公司的系统质量非常的高，并且你从各种技术报告也能看的出来，他们写出来的数据库性能也十分优秀。那么问题到底出在了哪里呢？
Andy在他的Talk中提到了几点理由，我觉得非常有道理：
- 营销一个NewSQL数据库是真的十分困难
最主要的原因就是NewSQL是去取代已有的数据库，而说服公司老板去放弃他们现在用的好好老数据库很不容易，想想现在还有多少公司在用三十多年前的Oracle就知道了。即使老数据库贵了点，性能差了点（其实未必，Oracle，SQLServer这些数据库都在持续做很多优化），可扩展性差了点，可用性低了点，但最关键的是还能用啊！迁移数据库是需要很多成本的，不仅是涉及到数据的迁移，也涉及到更改服务端的调用代码，并且有可能会发生数据错误，或者不兼容，或者代码更新不彻底。那为啥要花额外的精力冒险去动它呢？数据库是任何服务中最核心的一环，如果数据库崩溃了，对任何公司都是毁灭性的影响。
总结一句：营销NewSQL数据库就像小三去说服别人去和原配离婚一样，别人为啥呢？
- 免费的已经够用了
大公司不愿意选择NewSQL，那小公司呢？小公司也未必愿意。NewSQL解决的是对业务量比较少的公司而言已经大大超纲了。日活量才几千那是一点也不需要也不愿意购买高容错高可用的这些华丽的分布式数据库。别忘了，MySQL和Postgres 这俩数据库是永远免费和开源的，并且有非常多的社区人员不断的更新迭代，在这十年期间开发出了很多新的功能也做出了很多性能优化。对于小公司来讲，这样一个稳定易用的数据库已经完全够用了。
- 无法和AWS，Azure，GCP这样的云计算巨头竞争
绝大部分NewSQL都会把自己的数据库部署在云端然后卖给客户，或者付费授权用户部署在自己的云上，但价格与云计算巨头自己开发的云原生数据库，如AuroraDB，spanner这些相比完全没有优势。
- 缺少开源
数据库 | License |
CockroachDB | |
TiDB | |
YugabyteDB | |
VoltDB | 之前是GNU AFFERO GENERAL PUBLIC LICENSE，现在是private |
Andy 提到了这个观点，但他却并没有给出具体的理由，而很多NewSQL 数据库确实因为没有开源而最后无人问津。我觉得非常有道理，因为现在做的稍微好一点的NewSQL都是开源了自己核心代码的，而这也是这些商用数据库能快速占领市场的重要原因之一。这个看法可能会非常反直觉，因为把代码开源出来让大家看不是会让竞争对手获利吗？为什么反倒会帮助公司呢？
第一，开源其实仅仅只是把代码公开出来，但并不会让你随便公开的使用或者抄来售卖。一些开源的数据库都会有严格的license去杜绝任何人用他们的代码获利。比如MongoDB自己提出的SSPL license，这个license非常有意思，它允许AWS或者Azure这些云服务商用他们的代码去服务客户，但前提条件是，AWS或者Azure必须把他们所有云服务的代码全部公开，包括前端，后端，和基础架构。这怎么可能！所以也就杜绝了大云服务商使用他们的代码获利。
第二，开源代码可以清楚的让客户知道他们具体买了什么样的数据库，架构符不符合他们的要求。所以这些数据库公司不仅要把自己代码公开出来，还要写详尽的文档介绍他们的数据库到底是怎样设计的，适合什么样的场景，使用了什么技术。怕客户还不明白，他们甚至会开设很多免费的课程手把手的让你学习他们的架构设计。比如Pingcap，CockroachDB 都开设了自己的“大学”。
第三，即使客户对架构设计有一些地方不是特别满意，他们可以根据的代码进行私人定制，而不是走向你的竞争对手。
第四，对于数据安全性更敏感的金融行业而言，开源数据库更加的吸引他们。与其把自己宝贵的数据放到google的服务器上让自己完全不知道是啥的代码操作来操作去，还不如买开源数据库，然后把它部署在自己的机器上，这不是更安全吗？这也是CockroachDB，TiDB，yugabyteDB这些类spanner数据库火起来的原因之一。spanner既没开源，也必须部署到google自己的服务器上，那么像JP Morgan这些金融客户便不会选择它，而是奔向了开源和随地部署CockroachDB。即使这些数据库并没有比spanner做的好。
案例研究
开源的NewSQL数据库中最值得注意的是Pingcap做的TiDB。TiDB是用的apache license，意味着任何人可以随便用他们的代码，当然也包括这些云服务商随便把他们的代码抄过来放在自己的云上，然后自己卖给消费者。但这些并没有给Pingcap造成任何的阻碍，相反在六轮融资中获得超过3亿美金的他们非常的成功。平安保险，虎牙直播，卡普空这些纷纷成为Pingcap的大客户。为什么阿里云，AWS这些云服务商不偷走TiDB的代码自己售卖呢？个人认为Pingcap以下几点做的很好：
- 把社区版本和商用版本分开
TiDB分为社区版本和商用版本，而商用版本比社区版本多了更多的功能。所以如果客户想获得完整的功能只能给Pingcap交钱。
- 商用版本的会有24*7的支持
数据库每天都会遇到各种各样的问题，商用版本的数据库会有Pingcap的专业工程师全天候帮忙解决问题，客户买了放心。
这意味着如果其他人拿了TiDB的代码来卖，客户只能得到社区版本的数据库并且在遇到问题时能得到的帮助是有限的。
开源代码并不会伤害数据库，相反我认为未来会成为越来越多商业数据库公司的选择。
To B的逻辑和To C 完全不一样
在我非常有限的工作经历中基本都是做的To B的产品（飞书和AWS），而我最常听到的一句话就是To B和To C的逻辑是不一样的。要是To B和To C是相同的模式的话，产品质量极其优秀的飞书早就打败钉钉和企业微信霸占市场了，而现实情况却完全相反，飞书还是在市场中非常挣扎。我认为最核心的原因就是To B是把产品卖给老板的，而不是卖给员工，而老板考虑的就不仅仅是产品质量了。产品花费，企业关系，信任等等都是他们的考虑范围之内。这也是为什么亚马逊那么强调客户至上：要确保解决的是客户的问题，而不是臆想出来的不是问题的问题。这不仅包括了产品，也包括了信任，企业关系这些方方面面。只有解决好了客户的问题，客户才愿意为你的产品买单。所以NewSQL，虽然有着顶尖的技术和精美的产品，但依旧挣扎在数据库的市场上，而Oracle，IBM，Microsoft却能躺到过去的功劳簿上等着源源不断的钞票流进自己的账户。To B市场对待新人是残酷无情的。
在Andy的Talk的最后，他提到NewSQL在学术界是伟大的，而在工业界已经死了。作为数据库的爱好者，我感到无比的唏嘘。NewSQL远远没有达到完美的地步，还会有很多很好的idea会让它焕然一新，但在现在的市场上似乎已经成为了一个well-solved problem，没有人在意它的未来了。现在的NewSQL已经足够好，足够满足所有的需求了，那为啥还需要把大量的资源投进去改变它呢？失去未来的它已经“死”了。
我经常在网上看到一句话：都这年头了谁还在做OLTP数据库呢？现在在大公司做OLTP数据库已经很少涉及到新功能开发了，大部分都是维护着这个庞大的家伙不让它倒下罢了。今天跟一个Bloomberg的工程师聊天，她问我为啥就那么想去Comdb2（Bloomberg 内部使用的NewSQL）呢？Comdb2这个组一天到晚都是在oncall，基本上也就是做些修修补补的工作，真正的内核大开发早就结束了。
OLTP数据库未来的方向
在结束的时候，Andy照例推销了他自己一手创立的Ottertune。Ottertune并不是一种数据库，而是运行在数据库之上的优化器。数据库有个上百个能调整的参数，这些参数能直接影响数据的性能。Ottertune的核心思想就是与其招很多个数据库管理员每天根据不同workload调参，还不如用ML自动化这个过程，并且性能能比手动调惨做的更好。Andy坚信这就是数据库的未来。
我觉得重点不只是ML For Sys，而是背后的含义。用AI尽量去代替以前数据库管理员的工作，其实这就是为公司节约成本。招一个数据库管理人员在美国需要大概130K一年，而使用Ottertune提供的服务只需要1/4。 在科技产业过分估值的今天，这些企业急需退后一步，重新审视自己的花销。而降本增效自然而然的就是每个公司首先考虑的问题。Andy也在Blog中提到现在越来越多的公司更在意如何用Ottertune降低数据库成本，而不是改善性能。在Ottertune的宣传页上我们也能看到他们着重强调了Ottertune是如何帮助客户降低成本的。如果数据库新需求变少，那么谁能把数据库的成本做的越低就会受到更多公司的青睐，这成本不仅包括了使用成本，也有维护成本，甚至迁移成本。
（贝索斯在1998年就把Frugality当作一个公司成功的准则之一。20年前适用，今天适用，20年后也适用）
所以我认为，在降低成本的阶段，除了用ML去替代数据库的人工成本以外，另一个很有潜力的方向也是值得注意的：分离内存式数据库（Memory Disaggregated Database）。
这是一个很有意思的方向，如果展开讲会有很多可以讲的，我之后新开一篇文章细聊。简短来说，现在很多OLTP数据库都是存算分离的，也就是计算层和储存层能分别横向扩展，这样就不会出现计算层和储存层过度耦合而资源利用不足的情况。但现在随着数据量越来越大，内存和CPU也存在过度耦合的问题了，经常出现内存吃满但是CPU比较空闲，或者CPU吃满单内存却有不少空间的情况。如果能把CPU和内存分开，这样就会提高资源利用率，降低成本。去年FAST会议就有人提出了全分离内存Key Value Store，而在工业界阿里巴巴的Polar DB就早已开始采用这样类似的分离似架构，他们宣称节约了50%的成本。
数据库的发展永远不会结束，即使有些时候看似丢失了方向。因为它是现代高科技的基石，不管是发微信，刷抖音，或者在考试中通过ChatGPT作弊，背后都有无数个数据库在支撑整个服务的运行。它只要还在被大量使用，就会有无数的资本向其涌来，也就会有无数的人为其开疆扩土，而它也就会有无限可能。
后记
我是在2022年做完了15-445所有Lab，这正式标志着我入门数据库也快两年之久。我很庆幸大三的我并没有满足于成为CRUD的业务工程师，而是选择从0开始跟随Andy啃数据库。我在这门课的作业上花了超过100多个小时，最后做出了一个能跑SQL语句，支持事务的数据库BusTub
在这里非常感谢Andy能把整门课开源出来，包括录像，PPT，作业，和grader，Andy甚至专门请了DJ。这需要勇气，也需要对数据库最朴素的情怀，不过我相信对Andy来讲这一切都是值得的。
15-445彻底点燃了我对计算机系统的兴趣，我之后去上了MIT6.824，也开始做Pingcap的Tiny KV。做多了项目，看多了论文之后我也逐渐感悟到，系统永远都没有一个绝对正确的答案，即使能找到当下的一个好答案，但是随着时间的推移，场景在变，问题在变，而过去的系统则也必须随之更新自己。系统的魅力就在于在成本，易用性，可用性，正确性等等多重因素下不断的做出取舍，找到一个客户（或者是老板）能接受的方案。
计算机系统的复杂不仅于此。NewSQL的失败则警示着系统最终还是需要卖给客户使用的的。一个系统即使设计的天马行空，在没有人使用的情况下也会被逐渐淘汰。一个成功的系统能让客户产生非用不可的强烈欲望，这可以是它低成本的诱惑，也可以是客户对它高回报的期待，甚至可以是客户对它的信任。作为系统的设计师则需要考虑的不仅仅是解决问题，也需要思考怎么做才会让它更有优势，更有卖点。
最后再次感谢Andy，我这篇文章参考了许多他在网上分享的内容，所有的引用我都在文字中做出了外链。如果没有Andy的分享，我就不会了解到NewSQL背后发生的这么多故事，也不会有这篇文章。
我希望开始工作的时候能继续保持着这份对计算机系统的热爱，此为后记