关于数据库技术的发展思考

这是学习笔记的第 2232 篇文章

读完需要

9

分钟

速读仅需7分钟

现在对于数据库的需求越来越丰富，但是从本质来说，无非就是读和写，如果把这个需求做一些引申，以稳定，高效，安全为基准，会发现有几个地方其实是比较困难的。

1）写需求实现水平扩展相对是比较容易的，如果是日志流水型数据，那么对于insert类的写需求是很容易实现的，如果要考虑略微复杂的场景，多活的数据写入，对于insert类的日志流水型数据依然不是问题，引入类似分布式ID的方案就是一个引子。

2）涉及到状态数据的写扩展就很难了，这类需求通常和select+insert/update类操作组合绑定较多，这里业务需求不复杂的情况，有个分水岭，那就是是否需要引入事务，如果引入，事务模型的考量，分布式事务的支持粒度就是一个重点，如果不引入事务，做事务降维，那么这个复杂度相对会低一些，尽可能考虑的就是幂等的逻辑，幂等的基础需求就是基于主键的模式，在多活的环境中如何高效支持就是一个更精细的事情了，这里所说的精细主要表达的就是延迟，在毫秒及更低的环境中，高并发中对于数据一致性的影响会被放大，也能够影射出很多系统中设计简陋的一面，如果保证数据的一致性，抛开链路的消耗，从根上来说，还是得靠主键的基础依赖，也就意味着简单的数据模型可以做很多的事情。

3）对于还有一类写是跨数据集的写，可以理解为状态和日志数据的分离，比如一个用户的账户信息，状态信息是唯一的1条记录，但是围绕这1条状态信息可以上行下钻出一连串的变更历史，也就是所谓的流水日志，这是从数据模型中比较常见的操作模式，这列需求本质上也可以做拆分，即流水的可扩展写和状态写。

4）强依赖于事务写的业务，基本得和一些关键状态信息有关，大多是和钱相关，比如账户信息等。从业务线的数据流链路中来整体考虑，可能会涉及异构或者多端环境，即需要在多个数据源中寻求一种平衡，难点就是事务回滚的一致性，有分阶段提交，事务补偿机制等，这块着实是个硬骨头，这里也涉及一种折中的方式，那就是有业务层的数据基准，基准数据有相关数据/日志支撑,对于临界状态处理尤其有用，数据库中的很多细节也是这么玩的。

5）现在对数据库的一些需求发生了变化，那就是不光希望数据写得快，可扩展，还应该支持海量数据存储，并且查得快，看似有些矛盾的方案，行业里多见是HTAP方案，我做事情比较喜欢先建立边界，能做什么不能做什么，而不希望交给业务的东西就是一个大杂烩，从这一点来看，我是更希望业务需求对自己的数据模型有一个基本的理解，能够在一些快速增长中，对于数据库的存储和响应有一定的灵活空间，这里可以提供的是支撑能力，而不是眼皮底下的可适配方案，从这一点来说，我比较喜欢冷热数据分离的模式+数据引擎的组合。

6）对于数据查询方向，出了硬通货主键之外，二级索引是一块很大的发展空间，因为主键代表的含义在很多业务场景中是比较单薄的，比如一个表有10个字段，可能id字段仅仅代表的是一个自增的基础属性，更多的业务含义需要从二级索引中挖掘，这里就牵扯出两个比较有意思的问题，为了查询更快，需要更多的索引，为了写入更快，更多的索引会对写入产生副作用，当然没有所谓的银弹，只能是保持一种平衡，在平衡的基调之上，如何建立合适的索引其实是摆在DBA和开发人员面前的一个新的话题，DBA在早期不是很能理解业务特点，所以无法给出有效的建议，开发对于索引的而理解有限，认为有索引就是性能的代名词，所以这就需要达到更高一层的平衡。

7）有人说数据库发展中有所谓的1.0,2.0时代等，不管怎么定义，1.0时代都是过去，参数优化和系统层面的优化空间相对会比较有限了，而对于业务优化的模式其实就是SQL优化，而SQL优化几乎都离不开索引的陪伴，好的，索引的问题是我逐步引出的一个完全摆脱步调的话题，论调始终不变，那就是建立什么样的索引是最匹配，最高效，代价最低的。其实从DBA的角度来说，索引也是不友好的，索引对业务不透明，但是业务逻辑的性能又和索引紧密相连，从存储上索引也是相对独立的存在，从底层来说也需要额外的维护管理，包括碎片管理等。这里我算是抛出一个问题，也是我需要埋头需要做点东西的方向。

8）上面更多提到的还是基于关系型的一些观点，但是把这个视角放开，其实关系型模式这是数据模型中的一个重要分支，还有更多的数据模型，比如基于图的数据模型，半结构化，非结构化的数据模型的解决方案，这些在现在数据业务高速发展的过程中，可以提供更多的思路和更有效的方案。