聊聊已往十年，数据库技能的成长趋势

图片来自“Pixabay”

回看这几年，漫衍式辖档挽域呈现了许多新对象，出格是云和 AI 的崛起，让这个已往着实不太 sexy 的规模一下到了风口浪尖，在这时代降生了许多新技能、新头脑，让这个迂腐的规模从头抖擞朝气。站在 2010s 的尾巴上，我想跟各人一路聊聊漫衍式辖档皖人振奋的进化旅程，以及谈一些对 2020s 的斗胆意料。

无论哪个期间，存储都是一个重要的话题，本日先聊聊数据库。在已往的几年，数据库技能上呈现了几个很明明的趋势。

存储和计较进一步疏散

我印象中最早的存储 - 计较疏散的实行是 Snowflake，Snowflake 团队在 2016 年颁发的论文《 The Snowflake Elastic Data Warehouse 》是近几年我读过的最好的大数据相干论文之一，尤其保举阅读。Snowflake 的架构要害点是在无状态的计较节点 + 中间的缓存层 + S3 上存储数据，计较并不强耦合缓存层，很是切合云的头脑。从最近 AWS 推出的 RedShift 冷热疏散架构来看，AWS 也认可 Snowflake 这个搞法是先收支产力的成长偏向。其它这几年存眷数据库的伴侣不行能不留意到 Aurora。差异于 Snowflake，Aurora 应该是第一个将存储 - 计较疏散的头脑用在 OLTP 数据库中的产物，并大放异彩。Aurora 的乐成在于将数据复制的粒度从 Binlog 低落到 Redo Log ，极大地镌汰复制链路上的 IO 放大。并且前端复用了 MySQL，根基做到了 100% 的应用层 MySQL 语法兼容，而且托管了运维，同时让传统的 MySQL 合用范畴进一步拓展，这在中小型数据量的场景下是一个很省心的方案。

固然 Aurora 得到了贸易上的乐成，可是从技能上，我并不认为有很大的创新。认识 Oracle 的伴侣第一次见 Aurora 的架构也许会认为和 RAC 似曾体会。Oracle 或许在十几年前就用了相同的方案，乃至很美满的办理了 Cache Coherence 的题目。其它，Aurora 的 Multi-Master 尚有很长的路要走，从最近在 ReInvent 上的说法来看，今朝 Aurora 的 Multi-Master 的首要场景照旧作为 Single Writer 的高可用方案，本质的缘故起因应该是今朝 Multi-Writer 回收乐观斗嘴检测，斗嘴检测的粒度是 Page，在斗嘴率高的场所会带来很大的机能降落。

我以为 Aurora 是一个很好的迎合 90% 的公有云互联网用户的方案：100% MySQL 兼容，对同等性不太体谅，读宏大于写，全托管。但同时，Aurora 的架构抉择了它放弃了 10% 有极度需求的用户，如全局的 ACID 事宜 + 强同等，Hyper Scale(百 T 以上，而且营业不利便拆库)，必要及时的伟大 OLAP。这类方案我认为相同 TiDB 的以 Shared-nothing 为主的计划才是独一的出路。作为一个漫衍式体系工程师，我对任何不能程度扩展的架构城市认为不太优雅。

漫衍式 SQL 数据库登上舞台，ACID 全面回归

追念几年前 NoSQL 最风物的时辰，各人恨不得将统统体系都行使 NoSQL 改革，固然易用性、扩展性和机能都不错，可是大都 NoSQL 体系都丢弃掉了数据库最重要的一些对象，譬喻 ACID 束缚，SQL 等等。NoSQL 的首要推手是互联网公司，互联网公司的简朴营业加上超强的工程师团队，NoSQL 丢掉的对象虽然能用某些器材简朴搞定。但最近几年各人徐徐发明低垂的果实根基上没有了，剩下的都是硬骨头。

最好的例子就是作为 NoSQL 的开山鼻祖，Google 第一个搞了 NewSQL (Spanner 和 F1)。在后移动期间，营业变得越来越伟大，要求越来越及时，同时对付数据的需求也越来越强。尤其对付一些金融机构来说，一方面产物面对着互联网化，一方面不管是出于禁锢的要求照旧营业自己的需求，ACID 是很难绕开的。更实际的是，大大都传统公司并没有像顶级互联网公司的人才供应，大量汗青体系基于 SQL 开拓，完全迁徙到 NoSQL 上必定不实际。

在这个配景下，漫衍式相关型数据库，我以为这是我们这一代人，在开源数据库这个市场上最后一个 missing part，终于逐步风行起来。这背后的许多细节因为篇幅的缘故起因我就不先容，保举阅读 PingCAP TiFlash 技能认真人 maxiaoyu 的一篇文章《从大数据到数据库》，对这个话题有很出色的叙述。

云基本办法和数据库的进一步整合

在已往的几十年，数据库开拓者都像是在单打独斗，就仿佛操纵体系以下的就完满是黑盒了，这个假设也没错，事实软件开拓者大多也没有硬件配景。其它假如一个方案过于绑定硬件和底层基本办法，肯定很难成为究竟尺度，并且硬件很是倒霉于调试和更新，本钱过高，这也是我一向对定制一体机不是太感乐趣的缘故起因。可是云的呈现，将 IaaS 的基本手段酿成了软件可复用的单位，我可以在云上按需租用算力和处事，这会给数据库开拓者在计划体系的时辰带来更多的也许性，举几个例子：

1、 Spanner 原生的 TrueTime API 依靠原子钟和 GPS 时钟，假如纯软件实现的话，必要捐躯的对象许多(譬喻 CockroachDB 的 HLC 和 TiDB 的改造版 Percolator 模子，都是基于软件时钟的事宜模子)。可是恒久来看，不管是 AWS 照旧 GCP 城市提供相同 TrueTime 的高精度时钟处事，这样一来我们就能更好的实现低耽误长间隔漫衍式事宜。

2、 可以借助 Fargate + EKS 轻量级容器 + Managed K8s 的处事，让数据库应对突发烧点小表读的场景(这个场景险些是 Shared-Nothing 架构的老浩劫题目)，好比在 TiDB 中通过 Raft Learner 的方法，共同云的 Auto Scaler 快速在新的容器中建设只读副本，而不是仅仅通过 3 副本提供处事;好比动态起 10 个 pod，给热门数据建设 Raft 副本(这是我们将 TiKV 的数据分片计划得那么小的一个重要缘故起因)，处理赏罚完突发的读流量后再烧毁这些容器，酿成 3 副本。

3、冷热数据疏散，这个很好领略，将不常用的数据分片，说明型的副本，数据备份放到 S3 上，极大地低落本钱。

4、 RDMA/CPU/ 超算 as a Service，任何云上的硬件层面的改造，只要袒露 API，都是可以给软件开拓者带来新的甜头。

例子尚有许多，我就纷歧一罗列了。总之我的概念是云处事 API 的手段会像已往的代码尺度库一样，是各人可以依靠的对象，固然此刻公有云的 SLA 如故不足抱负，可是久远上看，必然是会越来越完美的。

（编辑：河北网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!