聊聊数据密集应用实现的一些关键问题

发表于2022年7月28日由Sihuan

Mysql是基于二维表的关系型数据库，DynamoDB是分布式的KV数据库，ElasticSearch是基于倒排索引的分布式搜索引擎，Doris是mpp数据仓库。。。

近十年是基础软件飞速发展，各种数据库，中间件层出不穷；数据量爆炸的今天，为了满足海量存储，各种数据密集型应用也在向着分布式的方向发展。

从上层看，有哪些技术是可以被总结归纳的？有哪些模式是值得被借鉴的？

今天等着面试也没啥事儿，写篇文章归纳归纳我的看法。

可以从一个老生常谈的问题开始：SQL vs NoSQL。

如果从数据模型的角度讲，SQL对应的就是关系模型，多数NoSQL则是KV模型/文档模型。这两种数据模型从设计出发点是不同的，SQL强调表与表之间数据的关联，可以方便的支持连接查询。而文档模型则淡化这种关系，一条数据只是映射到一个key上，这种设计虽然不方便连接，但是读写性能优异，非常适合分布式的分片模式。

数据模型在具体存储时，也存在不同的选型方案：一种是基于B-Tree为索引，利用磁盘块/页进行数据存储；一种是基于LSM-Tree（SSTables）的日志结构存储。

前者典型代表就是MySQL，数据持久化在磁盘块上，通过B-Tree进行索引，增删改查请求都会通过索引定位到具体的磁盘块上。显然因为有B-Tree索引，查询效率相对较高，但是因为写入是离散的，所以写入效率较低。

后者的代表譬如ElasticSearch, 一个时间段内写入的数据，会在内存中加工成有特定顺序且具备索引的数据结构，并在某个时间点以顺序写的方式将这些数据落盘。整个数据集合由很多这样的段文件构成，段文件通常是不可修改的。因为是顺序写入，所以写入效率非常高，但是查询因为要牵扯很多的段文件，相对来说效率较低。

SQL和NoSQL不同的数据模型，对于底层存储结构的实现有具体的要求吗？我认为是没有的，只是自从受到Google的BigTable论文启发之后，LSM-Tree的这种方式受到了越来越多新兴的NoSQL数据库的青睐。

另外一个值得提及的是OLAP数据库（或者叫数据仓库），它更多的是倾向用于海量数据的快速分析，执行的更多是各种复杂的聚合查询，所以跟普通的数据库会有一些技术上的差异，例如会针对MPP做一些优化设计，也会采用列存储等一些方式加快查询速度。

上面的这些讨论都是针对于单机，在引入分布式后，就可以涉及数据冗余以及分片的概念了。

首先是数据的冗余，为了保证数据高可用，通常会将数据进行冗余存储，并且使存储在不同的服务器/机架/机房/地区；数据的冗余最常用的方式就是主从复制。主节点接收到数据进行处理存储，并分发到到从节点。这种分发可以是直接利用同步网络请求，也可以是异步的，譬如MySQL通过binlog进行主从的同步。

数据的分片则是为了支持更大的数据量。一个数据集增加到一定程度之后就可能超出单机的承载能力，譬如MySQL单表支持1000万以上的数据，效率就会下降。那么就可以对大数据集进行分片，然后在分布式系统上进行存储。

分片往往会给系统引入更多的复杂性，包括路由，数据/流量的均衡，以及跨分区的联合查询。但是它的扩缩容能力能够在某些场景下发挥强大的作用，承载非分布式数据系统无法想象的数据量。所以只要控制好应用场景，它能带来巨大的好处。

另外一个话题就是事务还有一致性。

单机的事务和分布式事务是有区别的。单机的事务，拿MySQL举例，原子性和一致性通过undo日志保证，隔离性通过锁/MVCC保证，持久性通过redo日志保证。

分布式事务更复杂一点，多的是借助2PC，TCC等机制保证。从某个角度上讲，分布式事务实现更类似于分布式一致性/共识的某些实现。

分布式一致性的问题从宏观上包括了主从副本的数据一致性问题，以及共识问题。数据的一致性可以从主从复制角度分析，共识问题则更复杂一点。

什么是共识问题？分布式系统需要在谁是主，谁是从，现在集群状态是什么等问题上达成一致，这就是共识问题。

共识问题可以采用中心节点的算法，例如2PC算法，将这种共识问题的处理放到一个中心节点（协调节点）上去进行，因为是单节点，所以不存在不一致；等中心节点处理完之后在分发到不同的节点上；但是这样的缺点是存在single point of error。