GroupBlog

在这里插入图片描述本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。

本作品 (李兆龙博文, 由李兆龙创作)，由李兆龙确认，转载请注明版权。

回顾历史

自1970年 Codd 祖师爷提出关系模型开始，关系型数据库在五十多年的时间中蓬勃发展。早期互联网的流量并不想我们现在所处的年代，QPS的需求往往百级别就绰绰有余，但是2000年左右互联网应用如雨后春笋，一时间庞大的资源要求远超传统的软件服务，在这种日益增长的极端需求下，对并发性能，可用性的需求变得极为迫切。

传统数据库注重于实现强ACID特性，在可用性和性能上有所损失，这种 trade-off 与一些互联网应用的需求背道而驰。其次关系模型在一些场景下表达能力过强，在这些场景下使用SQL似乎有些大材小用，带来了不必要的性能损失，相比之下在这些场景各种垂直领域的数据库优势显然更大。后者直接导致了2005年到2010年间 “NoSQL运动”的兴起，一时间百家争鸣，KV，Document，Wide column，graph，Spatial，Time Series，Search engines等等数据模型好不风光。

虽然NoSQL一时间风光无限，但是关系模型带来的ACID理念仍旧深入人心，而且很多场景非常需要事务带来的强一致能力，这就意味着SQL仍然占据了主要的市场份额：
在这里插入图片描述
此时我们的处境是传统数据库逐渐成为了互联网应用的瓶颈，NoSQL系统使用强一致性交换高可用性，而且传统的升级机器和中间件解决方案治标不治本[1]。自1960年第一个数据库管理系统 Integrated Database System(IDS) 诞生之初的理念就是“应用程序逻辑与数据操作逻辑分离”，显然对于并发，可用等需求最优雅的解决方案莫过于在数据库管理系统中满足这些需求。

在这种大环境的推动下，New-SQL这个术语在2011年在[3]中被第一次提出，自此浩浩荡荡的“New-SQL运动”开始了。在[1]中Andy对New-SQL下对定义是：

NewSQL is that they are a class of modern relational DBMSs that seek to provide the same scalable performance of NoSQL for OLTP read-write workloads while still maintaining ACID guarantees for transactions.

且针对的读写事务有如下特征：

are short-lived (i.e., no user stalls)
touch a small subset of data using index lookups (i.e., no full table scans or large distributed joins),
are repetitive (i.e., executing the same queries with different inputs).

下图是[1]中的对当时已有New-SQL对一个总结：
在这里插入图片描述

大数据领域的绝对大哥Google（Amazon当然也是大哥）从 2011 Megastore 这个过渡品到 2012 Spanner 的究极完全体为 “New-SQL运动”带来精神寄托，一时间涌现出很多类Spanner的New-SQL系统，比如TiDB，yugabyteDB，CockroachDB，这些大名到今天听来仍然是如雷贯耳。

但是不得不提到的是[1]中提到New-SQL其实其实并没有在架构上做出突破性进展，更多的是一种把已有的研究成果伴随以极致工业化的结果。从[2]中我们也可以看到Andy对于New-SQL这个术语其实并不认同，并提到目前只有中国的数据库创业公司称自己为New-SQL，对此类数据库主流的称呼为Distributed SQL。不过有一说一，确实Distributed SQL听起来确实名副其实一些。

展望未来

那么未来会如何发展呢？

Andy在[1]中提到认为以下四类数据库会在未来逐渐融合：

the older DBMSs from the 1980-1990s
the OLAP data warehouses from the 2000s
the NoSQL DBMSs from the 2000s
the NewSQL DBMSs from the 2010s

看了这个列表，不禁感叹，这不就是HTAP+多模吗。确实，未来把这些本来业务无关的代码下沉到DB层是一种趋势，倘若业务眼前有一个集存储，分析，多模型，gloabl为一体的数据库，那么只需要注重业务代码的编写即可，这对人心智的解放和降本都是大有裨益的。

[5]中李飞飞大佬提到未来数据库技术的发展趋势将集中于以下六点：

云原生与分布式
大数据与数据库一体化
软硬件协同
多模型
智能化运维，自治性与智能性
安全可信

站在我个人现在这一时刻的角度来看，第三点和第五点不会是我个人的发展方向，因为目前对硬件和AI并无太多了解。至于第二点和第六点，OLAP以及大数据分析工具目前并不擅长，安全可信这一点目前中国的各大厂商并不重视，暂时没有发展前景。所以我更愿意押宝云原生与分布式以及多模型。

云原生数据库

称云计算为一次计算机产业的变革我认为并无不妥，其解决了IT基础设施构建的痛点，利用容器化，虚拟化，编排系统组成了一个云端操作系统，为各种资源使用带来了一个令人无法拒绝的优势，即“弹性”。

云原生其实到今天也没有一个官方的定义，但可以大致理解为下：

一个灵活的工程团队，遵循敏捷开发的原则，使用高度自动化的研发需求，开发专门基于并部署在云基础设施上的应用，以满足快速变化的客户需求。

云原生数据库则可以理解为充分利用云计算基础设施的特性设计的数据库，最大的特点是可伸缩，细粒度弹性，按需取用的服务化能力。与其对应的Distributed SQL则强调线性扩展能力，完全ACID语义和sql支持 。

其实如何理解云原生数据困扰过我一段时间，但其实其强调的就是利用云赋予的弹性去实现按需使用，这就意味着：

存算分离
极致弹性
高可用
高性能

这几点是必不可少的。这样看来云原生的最终形态不就是Serverless吗，这是目前我能想到的最弹性的按需获取。阿里至少在这条路上已经走到了前面，[6]中提出的计算，内存，存储分离的架构实在是过于先进，不过现在广为人知的不也是几十年前无人问津的吗。

不过一个云原生数据库的架构应该是什么样子呢？我们以PolarDB-X举一个简单的例子[5]（因为细节的我也不懂…），PolarDB-X采用Shared nothing 和 Shared Everything 结合的架构。单个PolarDB中利用RDMA和PolarFS[7]的极致工业用户减少 Shared Everything 带来的网络瓶颈（X-Engine也是秀的人头皮发麻[9]），同时多个PolarDB之间采用 Shared nothing，这种混合架构的好处是它减轻了小碎片过多的缺点。特别是降低跨分区事务的概率（单个PolarDB内提交无冲突），且Re-balence也更为轻松。

在这里插入图片描述

最重要的优点如下：

计算和存储资源被解耦，计算和存储节点可以使用不同类型的服务器硬件，并且可以单独定制。例如，计算节点不再需要考虑内存大小与磁盘容量的比率，这高度依赖于应用场景，并且很难预测。
它突破了单节点数据库（如 MySQL、PostgreSQL）的局限性。存储节点上的磁盘形成一个存储池，这降低了碎片化、使用不平衡和空间浪费的风险.
由于数据都存储在存储集群上，计算节点上没有本地持久状态，这使得执行数据库迁移更容易、更快。
PolarFS 提供的数据复制和其他高可用特性，数据可靠性也可以得到提高。

其实这已经满足了我们上面提到的那几点。

多模型数据库

从 DB Ranking 就可以看出多模型无疑是一个趋势：
在这里插入图片描述
前二十中有十三个产品中已经支持多模型，从[5]中可以看到李飞飞对于多模多未来预期是：

An important application scenario at Alibaba is to support multi-model analysis, which consists of two aspects: southbound and northbound multi-model access. The southbound multi-model access indicates that the underlying storage supports different data formats and data sources. The stored data can be either structured or non-structured, e.g., graph, vector and document storage. The database then provides a unified query interface, such as a SQL or SQLlike interface, to query and access various types of data sources and formats, forming a data lake service. The northbound multi-model access indicates that a single data model and format (e.g., key-value model in most cases) is used to store all structured, semi-structured and unstructured data in a single database. On top of this single storage model, the database then supports multiple query interfaces, such as SQL, SPARQL and GQL depending on the application needs. Microsoft CosmosDB [9] is a representative system of this kind.
In addition to addressing our internal business operation needs, being able to support multi-model analysis is also an essential requirement for cloud database services. Many cloud applications require to collect large-volumes of data from heterogeneous sources, and conduct federated analysis to link different sources and reveal business insights (i.e., south-bound multi-model access). On the other hand, a cloud database (e.g., a large KV store such as HBase) is often a central data repository accessed by multiple applications with various application needs. They may prefer to use different query interfaces due to usability and efficiency, where northbound multi-model analysis is needed.

基本上这个领域的大哥还是Azure CosmosDB[8]。可能是我见识短浅，其实目前看起来我相对熟悉的更多的产品还是走向 northbound，比如yugabyteDB，Redis，包括我现在所在部门做的产品，更强调易用性。

而 lake service base multi model（southbound）我认为更多的用于数据分析中，其更加强调与多模型分析。

总结

其实数据库融合的趋势已经是可以预料到的事情了，虽然题目中我提到Distributed SQL，云原生数据库，多模型数据库，但是在很多实例上这些特征在现在这一时刻已经融为一体了。

历史的车轮滚滚向前，谁也无法阻挡。

目前看来笃学好古才是真真切切需要去做的，一只眼睛看前面的路，两只脚和另外一只眼睛负责脚下的路，如是而已。

参考：