logo

单机数据库的不可能三角

正如经济政策的不可能三角“不可能同时实现资本流动自由,货币政策的独立性和汇率的稳定”那样,单机数据库也有一个不可能三角,那就是:①持久化 ②事务隔离 ③高性能,三者不可兼得。

为什么不可能

  1. 持久化需要每一次写数据都要落到磁盘上,宕机再启动以后,数据库可以自动修复。如果只要求这一条,很好实现。
  2. 事务隔离需要每一次会话(session)的事务都拥有自己的数据库版本:既要多个并行的事务相互之间不会写到对方的虚拟数据库上(读提交),又要不能读到对方的虚拟数据库上(可重复读),还要在一个事务内不能读到别的事务已经提交的新增的数据(幻读),终极需求则是完全串行化——我的读 session 不结束,你就不能读。这个需求和持久化需求结合以后,会大幅增加日志管理的复杂度,但仍然是可控的。
  3. 读写都要尽量地快:单独实现也很快,内存数据库嘛(如 Redis),但是加上持久化和事务隔离,就很难做了——需要对前两项进行妥协。

MySQL 选择了哪两个?

首先,MySQL 选择了持久化:失去人性,失去很多;失去持久化,失去一切。没有持久化能力的核心数据库就做不了核心数据库,这一条是所有磁盘数据库的刚需,完全无法舍弃。

然后,MySQL 选择了一部分高性能:MyISAM 就是为了快速读写而创造的,早期 MySQL 在低配 PC 机上就有不错的性能。后来更高级的 InnoDB 出现了,小数据量时它的读取性能不如 MyISAM,写性能更是彻底拉胯,但是在面对大数据量场景时,读性能非常强,还能提供很多后端程序员梦寐以求的高级功能(例如丰富的索引),承担了大部分互联网核心数据库的角色。

最后,MySQL 将事务隔离拆成了几个级别,任君挑选:你要强事务隔离,性能就差;你能接受弱事务隔离,性能就强。你说无事务隔离?那你用 MySQL 干什么,Redis 它不香吗。

所以 MySQL 其实选择了 持久化*1 + 高性能*0.8 + 事务隔离*0.5,算下来,还赚了 0.3。

不过,从 MySQL 也可以看出,“数据库的不可能三角”并不是完全互斥的,是可以相互妥协的。

在开始细数分布式数据库之前,我们先看一个非分布式的数据库性能提升方案——读写分离,主从同步。

阅读数:1410      字数:809 最后更新:2023-10-26 11:48:16