云原生数据库设计新思路
Posted 给小熊梳头
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了云原生数据库设计新思路相关的知识,希望对你有一定的参考价值。
在讲新的思路之前,先为过去没有关注过数据库技术的朋友们做一个简单的历史回顾,接下来会谈谈未来的数据库领域,在云原生数据库设计方面的新趋势和前沿思考。首先来看看一些主流数据库的设计模式。
常见的分布式数据库流派
分布式数据库的发展历程,我按照年代进行了分类,到目前为止分成了四代。第一代是基于简单的分库分表或者中间件来做 Data Sharding 和 水平扩展。第二代系统是以 Cassandra、HBase 或者 MongoDB 为代表的 NoSQL 数据库,一般多为互联网公司在使用,拥有很好的水平扩展能力。
第三代系统我个人认为是以 Google Spanner 和 AWS Aurora 为代表的新一代云数据库,他们的特点是融合了 SQL 和 NoSQL 的扩展能力,对业务层暴露了 SQL 的接口,在使用上可以做到水平的扩展。
第四代系统是以现在 TiDB 的设计为例,开始进入到混合业务负载的时代,一套系统拥有既能做交易也能处理高并发事务的特性,同时又能结合一些数据仓库或者分析型数据库的能力,所以叫 HTAP,就是融合型的数据库产品。
未来是什么样子,后面的分享我会介绍关于未来的一些展望。从整个时间线看,从 1970 年代发展到现在,database 也算是个古老的行业了,具体每个阶段的发展情况,我就不过多展开。
数据库中间件
对于数据库中间件来说,第一代系统是中间件的系统,基本上整个主流模式有两种,一种是在业务层做手动的分库分表,比如数据库的使用者在业务层里告诉你;北京的数据放在一个数据库里,而上海的数据放在另一个数据库或者写到不同的表上,这种就是业务层手动的最简单的分库分表,相信大家操作过数据库的朋友都很熟悉。
第二种通过一个数据库中间件指定 Sharding 的规则。比如像用户的城市、用户的 ID、时间来做为分片的规则,通过中间件来自动的分配,就不用业务层去做。
这种方式的优点就是简单。如果业务在特别简单的情况下,比如说写入或者读取基本能退化成在一个分片上完成,在应用层做充分适配以后,延迟还是比较低的,而整体上,如果 workload 是随机的,业务的 TPS 也能做到线性扩展。
但是缺点也比较明显。对于一些比较复杂的业务,特别是一些跨分片的操作,比如说查询或者写入要保持跨分片之间的数据强一致性的时候就比较麻烦。另外一个比较明显的缺点是它对于大型集群的运维是比较困难的,特别是去做一些类似的表结构变更之类的操作。想象一下如果有一百个分片,要去加一列或者删一列,相当于要在一百台机器上都执行操作,其实很麻烦。
NoSQL - Not Only SQL
在 2010 年前后,好多互联网公司都发现了这个大的痛点,仔细思考了业务后,他们发现业务很简单,也不需要 SQL 特别复杂的功能,于是就发展出了一个流派就是 NoSQL 数据库。NoSQL 的特点就是放弃到了高级的 SQL 能力,但是有得必有失,或者说放弃掉了东西总能换来一些东西,NoSQL 换来的是一个对业务透明的、强的水平扩展能力,但反过来就意味着你的业务原来是基于 SQL 去写的话,可能会带来比较大的改造成本,代表的系统有刚才我说到的 MongoDB、Cassandra、HBase 等。
最有名的系统就是 MongoDB,MongoDB 虽然也是分布式,但仍然还是像分库分表的方案一样,要选择分片的 key,他的优点大家都比较熟悉,就是没有表结构信息,想写什么就写什么,对于文档型的数据比较友好,但缺点也比较明显,既然选择了 Sharding Key,可能是按照一个固定的规则在做分片,所以当有一些跨分片的聚合需求的时候会比较麻烦,第二是在跨分片的 ACID 事务上没有很好的支持。
HBase 是 Hadoop 生态下的比较有名的分布式 NoSQL 数据库,它是构建在 HDFS 之上的一个 NoSQL 数据库。Cassandra 是一个分布式的 KV 数据库,其特点是在 KV 操作上提供多种一致性模型,缺点与很多 NoSQL 的问题一样,包括运维的复杂性, KV 的接口对于原有业务改造的要求等。
第三代分布式数据库 NewSQL
刚才说过 Sharding 或者分库分表,NoSQL 也好,都面临着一个业务的侵入性问题,如果你的业务是重度依赖 SQL,那么用这两种方案都是很不舒适的。于是一些技术比较前沿的公司就在思考,能不能结合传统数据库的优点,比如 SQL 表达力,事务一致性等特性,但是又跟 NoSQL 时代好的特性,比如扩展性能够相结合发展出一种新的、可扩展的,但是用起来又像单机数据库一样方便的系统。在这个思路下就诞生出了两个流派,一个是 Spanner,一个是 Aurora,两个都是顶级的互联网公司在面临到这种问题时做出的一个选择。
Shared Nothing 流派
Shared Nothing 这个流派是以 Google Spanner 为代表,好处是在于可以做到几乎无限的水平扩展,整个系统没有端点,不管是 1 个 T、10 个 T 或者 100 个 T,业务层基本上不用担心扩展能力。第二个网站监控好处是他的设计目标是提供强 SQL 的支持,不需要指定分片规则、分片策略,系统会自动的帮你做扩展。第三是支持像单机数据库一样的强一致的事务,可以用来支持金融级别的业务。
以上是关于云原生数据库设计新思路的主要内容,如果未能解决你的问题,请参考以下文章
一起架构-某实时分析项目云原生 serverless 架构的设计思路和poc代码实现
一起架构-某实时分析项目云原生 serverless 架构的设计思路和poc代码实现