创意电子

标题: 近十年纪据库流行趋势纵览！存储计算分离、ACID 全面回归...... [打印本页]

作者: CSDN 时间: 2020-1-2 17:46
标题: 近十年纪据库流行趋势纵览！存储计算分离、ACID 全面回归......

作者 | 黄东旭
责编 | 郭芮
回看这几年，分布式系统范畴出现了许多新东西，特别是云和 AI 的崛起，让这个过去其实不太 sexy 的范畴一下到了风口浪尖，在这期间诞生了许多新技术、新思想，让这个古老的范畴重新抖擞生机。站在 2010s 的尾巴上，我想从数据库、硬件、测试、运维等角度，跟大家一起聊聊分布式系统令人振奋的进化旅程，以及谈一些对 2020s 的大胆猜想。
无论哪个期间，存储都是一个重要的话题，今天先聊聊数据库。在过去的几年，数据库技术上出现了几个很显着的趋势。

存储和盘算进一步分离
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，终于慢慢盛行起来。

云基础设施和数据库的进一步整合
在过去的几十年，数据库开发者都像是在单打独斗，就好像操作系统以下的就完全是黑盒了，这个假设也没错，毕竟软件开发者大多也没有硬件背景。另外如果一个方案过于绑定硬件和底层基础设施，一定很难成为事实标准，而且硬件非常倒霉于调试和更新，本钱过高，这也是我一直对定制一体机不是太感爱好的原因。
但是云的出现，将 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 仍旧不敷理想，但是长远上看，一定是会越来越完善的。

数据库的将来在哪里？
数据库的将来是更加的垂直化还是走向统一？
对于这个问题，我同意这个世界不存在银弹，但是我也并不像我的偶像，AWS CTO Vogels 博士那么悲观，相信将来是一个割裂的世界（AWS 恨不得为了每个细分的场景设计一个数据库）。过度地细分会加大数据在差别系统中流动的本钱。解决这个问题有两个关键：

数据产品应该切分到什么粒度？
用户可不可以不消知道背后发生了什么？

第一个问题并没有一个明白的答案，但是我以为肯定不是越细越好的，而且这个和 Workload 有关，比如如果没有那么大量的数据，直接在 MySQL 或者 PostgreSQL 上跑分析查询其实一点问题也没有，没有须要非去用 Redshift。虽然没有直接的答案，但是我隐约以为第一个问题和第二个问题是痛痒相关的，毕竟没有银弹，就像 OLAP 跑在列存储引擎上一定比行存引擎快，但是对用户来说其实可以都是 SQL 的接口。
SQL 是一个非常棒的语言，它只描述了用户的意图，而且完全与实现无关，对于数据库来说，其实可以在 SQL 层的后面来进行切分，在 TiDB 中，我们引入 TiFlash 就是一个很好的例子。动机很简朴：
1、用户其实并不是数据库专家，你不能指望用户能 100% 在恰当的时间使用恰当的数据库，并且用对。
2、数据之间的同步在一个系统之下才能尽量保持更多的信息，比方，TiFlash 能保持 TiDB 中事务的 MVCC 版本，TiFlash 的数据同步粒度可以小到 Raft Log 的级别。
另外一些新的功能仍旧可以以 SQL 的接口对外提供，比方全文检索，用 SQL 其实也可以简便的表达。这里我就不一一睁开了。
我其实坚信系统一定是朝着更智能、更易用的方向发展的，如今都 21 世纪了，你是希望每天拿着一个 Nokia 再背着一个相机，还是直接一部手机搞定？
作者：黄东旭，分布式系统专家、架构师、开源软件作者。PingCAP 联合创始人兼 CTO，着名开源项目 Codis/TiDB/TiKV 主要作者，曾就职于微软亚洲研究院、网易有道及豌豆荚。2015 年创业，成立 PingCAP，致力于下一代开源分布式数据库的研发工作，擅长分布式存储系统设计与实现，高并发后端架构设计。
声明：本文系作者投稿，版权归作者个人所有。

欢迎光临创意电子 (https://wxcydz.cc/)