数据库你信仰什么-- 我信不给自己打标签（CloudJUMP ）

________________________________________________________________________ 从SQLSERVER，到MYSQL ，在到POSTGRESQL ， MONGODB ，REDIS，数据库变了又变，现在又到了POLARDB ，你是什么数据库的DBA ，还在标签化吗， NO ，这么多年的摸爬滚打，拼的最终是变化和快速的学习的能力。

前一段时间，团队的一些人给我的一些信息，让我曾经迷茫，云数据库我摸不到底层，我是要变成一个 operator DBA, 这是我最难接受的，我希望对我使用的数据库，里里外外，弄个明白，从原理到成本，到对应用程序的适配，最终到一个解决方案的地步，云数据库没有那么多的书，也没有那么多的文字，让你去更深入的学习，这才是问题的所在。

提出一个新的问题，数据库的开发是基于硬件的变化，还是硬件可以依据数据库的发展进行变化，到目前为止还是信任前者，因为的面对现实。

http://mysql.taobao.org/monthly/2022/06/01/

看完上面连接的文字，可能就能体会，数据库截止目前大部分的优化原理还是要基于目前的硬件体系，并跟随硬件的变化而变化。

文章中提到了一种我们传统DBA 不熟悉的存储系统，弹性分布式块存储系统，和我们曾经的对象存储最大的不同是，这样的存储系统是基于云的结构和需求产生的新的存储模式。

图中的存储系统左边是传统的模式，右边是云的存储系统和数据库节点组成的数据库系统

所以基于硬件的变化，云上的数据库必然在代码层开始要适应这样的新的架构下的各种需求。

其中文中提到了两个优化的方式，

1 在数据库的结构上进行原理性的修改，如REDO LOG 在存储时不在使用原有的数据落地的模式，而在中间在构建一个层，来存储REDO LOG ，避免网络消耗导致的系统的性能消耗。

2 第二种方式是文章中提出的，在不改变现有数据库的原理，并在现有的分布式存储方式中，进行优化，完成数据库系统和新的存储系统之间的对接。

实际我们必须有一点认知，云数据库的存储性能高吗，说高的人估计是没有怎么用过云数据库，云数据库在目前的状态下，其硬件的性能体现一定是不如你去购买目前强悍传统服务器基础上搭建的数据库的单机系统。

而现在的云数据库持续改进的目标，是要达到传统系统独占数据库的性能，并维持一个较低的成本代价。

为什么这样说，原文中提到了云数据库在使用分布式块存储作为数据库基础中的挑战

1. 远程分布式存储集群的访问导致云存储服务的I/O延迟高；
2. 通常聚合I/O带宽未被充分利用；
3. 在具有本地存储的单机上运行良好但需要适应云存储而导致特性改变的传统设计，例如文件cache缓存；
4. 长链路导致各种数据库I/O操作之间的隔离度较低（例如，日志刷写与大量数据I/O的竞争）；
5. 云用户允许且可能使用非常大的单表文件（例如数十TB）而不进行数据切分，这加剧了I/O问题的影响。

同时在读完这篇文字中的关于数据库对于cloudjump的优化的 7个原则，我对于云上的数据库在应用中的使用中的弱点和问题，有了更深的了解。

优化的反义其实就是不足，在传统数据库中的刷脏，日志突发的写入，DDL大表 等这些对于云数据库都是性能产生的问题点，也可能是压垮云数据库的最后一根稻草。硬件的不同，之前不是问题的问题，到现在都需要进行考量和优化。

其中文中提出了2中优化的方式，针对日志集中的写入，基于网络传输IO的延迟，那么更好的在同一个时间利用IO，分割IO 并行，以及加大一个时刻维度写入的IO的量，是解决集中IO 的写入的一个点。

最终的结果REDO 将不在同一个时间，只写入到一个文字中，在传统数据库MYSQL 中我们在同一个时刻REDO 只能写入到一个文件中，并且是顺序性的，而在云端的 MYSQL 或者 WHAT EVER，这些数据库将变化为，在同一个时刻，写入的REDO 的文件，将不在是一个文件，而是多个文件。

同时优化还未停止，一个文件在变成多个文件的基础上，IO的传输也不在是单线程了，IO 变成了多线程的任务，对于一些应用中使用的BLOB 或者大流量的batch insert ，或big transcations 都变成了分片，并行利用多个IO通道来写入的方式。

原有的数据库日志写入的方式，被彻底肢解了。除此之外，在REDO LOG 方面重启数据库时，针对原有读取REDO LOG 文件的扫描信息的方式进行了改变，因为大量读取文件信息，又触发了云数据库的弱点，所以更精确的读取所要的数据，同时在进行数据的标识等进行了变化，最终的目的是减少数据库系统重启时，读取必要数据的信息量，更精准，并且将整体的恢复进行拆分，结果也是将使用硬件的在时间的维度进行了并行。

同时在其他的场景下，对于索引提取数据，进行了更多的预读的方式，也就是比传统的数据库在预读取数据上，做了更多的空间来读取更多的数据，防止数据命中不到的时候，着急调用IO，来引发数据库读取数据的延迟放大化。

在另一个面对于传统数据库的在添加索引时对于页面的枷锁SX锁，也进行改变，从不释放直到做完这个工作，而变成了产生一个页面的副本，慢慢改，在副本产生后，就释放SX锁的方式，进行更好的页面的刷脏。

最后对于IO的物理使用，也进行了改造，对于在本地机上的IO 是不会给进行分类的，而云上的数据库是需要进行分类的，对于核心的IO需求有单独的数据通道保证突发的写，如WAL 日志的写入，PAGE的读取写入，而对于一些其他的如BINLOG 部分（我猜的）的优先级就不会那么高了。

从整片文字中，我深刻的感受到一直信奉的数据库优化的方式的几个字，

时间换空间，空间换时间，分类管理而后提高并发度。

最后这篇文字的最终还是要落到，标签化，DBA同学有些喜欢标榜自己是 MYSQL ，POSTGRESQL ，MONGODB ,REDIS ，POLARDB, SQL SERVER ， ORACLE DBA 的某一种 ，我对此没有任何的异议，热爱一种数据库是一种信仰，尤其各个数据库领域的专家和大神，如果你问我，你是什么DBA ，我会笑着回答，我希望我是全栈DBA ，不给自己设限，我们都值得不断进化，不是吗！