为oltp选择rdmbs时,你都需要考虑哪些

为OLTP选择RDMBS时，你都需要考虑哪些？ 译者 | 大愚若智策划｜木环我们经常需要为自己的OLTP（事务/运营）数据库选择适合的RDBMS（关系型数据库管理系统）。虽然通过编写可移植的SQL可以暂时避免进行这样的选择，但迟早要做出这样的选择，至少需要进行这样的尝试（比如，意识到具体的选择不够明确，因此决定选择跨RDBMS的SQL）。生产环境中选择 RDBMS 的标准是？ 在发起“到底哪个RDBMS最好”的讨论圣战之前，也许需要首先明确一下对于24x7运行的生产级OLTP RDBMS，到底需要具备哪些必不可少的功能。一、 基于锁，或是基于MVCC 考虑到并发性，目前几乎所有RDBMS无外乎基于锁的（Lock-Based），或基于MVCC（多版本并发控制）的。从写负载更重的OLTP处理角度来说，我曾经见到过：对于读写混合型负载（例如OLTP事务和报表），基于MVCC的RDBMS表现会比基于锁的略好一些。如果使用高于Read Uncommitted的隔离级别，效果还会更好，最适合用于读取/报表用途。另一方面，OLTP很少会遇到大量并发读取的情况，如果真的遇到这种情况，通常可通过副本（Replica）执行此类读取，因此不会造成太严重的问题。对于大部分情况下以写入为主的OLTP（没有太多报表需要创建），基于锁的RDBMS要比基于MVCC的表现略好一些。然而如果能让OLTP工作负载使用INSERT代替UPDATE，此时MVCC的效率更高。另外，值得注意的是，如果使用了单一写入连接（Single-write-connection）数据库架构，基于锁和基于MVCC的RDBMS之间的逻辑差异将显得微乎其微（尽管性能略有差别，但其他方面几乎相同，基于锁的RDBMS通常略微领先一些）。二、ACID保障 对于OLTP数据库，我们需要为涉及多行和多表的事务提供ACID保障。如上所述，对于OLTP数据库，我们需要为事务提供全面的ACID保障。更重要的是，需要保障涉及多行和多表的事务具备ACID特性。虽然这一规则也有例外，但这种例外情况实际上极为罕见。这几乎已自动将MySQL+MyISAM用作OLTP数据库的可能性彻底排除在外。但是也要注意，MySQL+ISAM可能是少数应用（例如作为快递追踪系统或系统监视工具的后端）的好选择，但并不适合涉及某类与金钱有关信息的常规OLTP处理。此外RDBMS提供的ACID保障差不多等同于意味着需要使用数据库日志，同时也意味着一旦RDBMS崩溃，随后需要通过数据库日志进行自动恢复（并自动前卷Rollforward）。三、 支持24×7运行 作为联机备份的备选方案，可使用异步主从复制（Replication）我们需要的另一系列功能主要与24×7不间断运行有关（例如游戏服务器，总得全天候运行对吧）。这些功能包括：联机备份。无论做什么都肯定需要备份，24x7不间断运行更是少不了联机备份。1、通常来说，联机备份意味着需要具备“日志前卷”能力。大部分时候是这样工作的：创建两个数据库，一个作为“主”，一个作为“从”；随后从“主”获取日志文件并发送给“从”，然后在从数据库上进行“前卷”。此外,有些数据库可以对处于“日志前卷”状态下的“从”数据库执行只读请求（实际上等同于创建了一个只读从副本）。然而其他一些RDBMS不能处理这样的请求（例如需要首先完成“日志前卷”操作才能让从RDBMS能够接受查询操作）。2、作为联机备份的备选方案，也可以通过异步主从复制获得近乎完全同步的备份副本（这种做法对MySQL+InnoDB是一种尤为有趣的选项）。需要注意，这样的副本也许可以或无法支持联机备份+前卷那样的“时点”恢复（具体情况请参阅文档）。虽然只在从一些非常糟糕的情况下恢复时需要“时点”恢复（实际生产环境中我从未遇到需要这种恢复的情况），不过真遇到这种糟糕的情况至少也能助我们一臂之力。3、“即时”的ADD COLUMN语句。我们可能需要对生产环境的数据库进行扩展，这一点是确定无疑的。大部分时候这是通过ALTER TABLE… ADD COLUMN语句实现的。面对ADD COLUMN语句，很多RDBMS会简单地将整个表重写为新格式的行。如果表包含10亿行，这一过程可能需要数小时?（在进行复制的过程中，整个表将完全无法访问，导致数据库在数小时内无法使用?）。让ADD COLUMN能够近乎即时（考虑到表的大小，可能需要几毫秒的时间）执行完成并不需要什么艰深的技术，有些RDBMS也确实能做到这一点，但是也不能忽视，这并不是一种普遍特性。预算不足时的备选方案是实现无锁ADD COLUMN（以及常规的ALTER TABLE），方法如下：用新的结构创建“影子”表通过触发器将对当前表的所有改动写入影子表将数据从当前表复制到影子表（一定要忽略已存在的行，因为触发器已经在其中写入内容了）用影子表取代当前表这种“廉价”的ADD COLUMN方法相当繁琐（全过程会对性能产生极大影响），但如果没有其他更好的方法，这种做法至少可以起到一定的效果。“即时”ALTER COLUMN（字段拓宽，Widening field）也是个很好的功能，但因为字段拓宽可通过ADD COLUMN模拟，因此显得并不是太重要。4、联机表优化。这个功能需要介绍一下。由于RDBMS会不断修改表内容，表的性能会逐渐退化（实际上取决于所用存储引擎，从“行溢出（Overflow row）”到“死行（Dead row）”，我们会遇到各种不希望出现的情况）。为此有必要进行一定的优化（例如InnoDB的OPTIMIZE TABLE，DB/2的REORG TABLE，Postgres的VACUUM等），并且我们会需要联机完成这些操作（无需让整个数据库彻底停摆，因为对包含数百万行内容的表进行优化通常需要花很长时间）。大部分时候，此类优化需要创建“影子副本”（由数据库自行创建，这总好过需要我们手工创建），这也意味着需要额外的存储空间。不过至少有一个RDBMS提供了“原地”表优化功能。5、容器的重新平衡。虽然不像上文列出的其他问题那么重要，但我始终认为“容器的重新平衡”也是RDBMS需要考虑的一个重要问题。简单来说，这个问题主要出现在添加存储数据的新硬盘（这种情况时有发生），以及通过将数据分散在所有硬盘上实现提速时。此时可通过下列两种方法之一实现：(a) 使用RAID-10（这样就无需考虑数据库存储数据的方式了）(b) 通过多个RAID-1磁盘使用数据库容器（因为数据库本质上采用了类似RAID-0的工作原理）。只要无需添加新硬盘（实际上通常在添加时，为了实现冗余往往会成对增加硬盘），所有系统基本上是均等的，然而在添加了一对新硬盘后，我们需要对硬盘进行“重新平衡”，借此实现负载的重新平衡，这一“重新平衡”的工作分别是由RAID或数据库进行的。RAID级别的重新平衡对服务器性能的影响远大于数据库级别的重新平衡（尤其是有些情况下系统甚至完全无力承担RAID级别重新平衡过程中产生的负荷）。因此我更乐于选择使用由数据库管理的容器（会在增加容器后重新平衡，整个过程会保持尽可能平缓）。四、 性能 不幸的是，缺乏具体用例情况下进行的数据库性能评测其实没有任何意义。当然，性能（尤其是写性能）对OLTP数据库至关重要。不幸的是，缺乏具体用例情况下进行的数据库性能评测其实没有任何意义。因此我只能尽量介绍一些与性能有关的知名RDBMS架构功能及对某些功能的误解。 SQL编译器的提示人类从不以史为鉴，这本身就是最重要的“鉴”。—— 奥尔德斯·赫胥黎在向RDBMS提交SQL语句时，语句会被编译为“执行计划”。而（无论数据库开发者怎么想或数据库产品的销售人员怎么说）这样的编译器时不时总会出错。例如下面列出了一个常见的此类错误：我们正在使用基于统计信息（即基于成本）的SQL编译器。有一个很大的历史表，其中包含一个TIMESTAMP字段（很常见的情况）。统计信息恰好有些陈旧，例如晚了几小时/几天（总是会这样）。我们正在编译的SQL语句会获取“T=上一小时”之后的数据。此时SQL编译器查看统计信息发现我们所请求的T之后没有任何数据，并决定针对上一小时的数据进行索引扫描（并预期到将会读取回0行数据）。其实还有其他（实际上更好的）执行计划（基于其他索引），但SQL优化器（预期会通过索引扫描取回0行数据）决定使用基于时间的索引。然而在上一个小时里产生了几百万笔事务，导致这次索引扫描工作需要耗费极长的时间。 OLTP的性能问题某些RDBMS会让人感觉它们在设计时从未考虑过主要以写操作为主的OLTP（而是更专注于读取查询）。虽然这并不意味着此类RDBMS从本质上就很糟糕（毕竟大部分数据库确实主要以读取查询为主要任务），但在现实世界中，面对需要执行大量写操作的OLTP环境，这会成为一个不容忽视的问题。一起看看这些相当著名的问题吧。Postgres：甚至对非索引字段进行更新也会导致Ctid的变化（存在争议）有报道称现实用例中对包含大量索引的数据库进行更新时，Postgres的数据库会遇到严重的性能问题。相关问题的详细讨论可参考StackOverflow.PostgresUpdates和Klitzke，在我看来问题主要在于：“由于索引需要通过Ctid引用行，一个简单的UPDATE（哪怕针对非索引列执行）也会改变Ctid，导致引用了被更改行的表中每个索引中的Ctid均需要重写。”这就很糟了，对写操作负担重的OLTP数据库尤为如此。另外从Postgres 8.3开始提供了一种所谓的Heap-Only Tuples（HOT）功能，该功能至少在理论上应该能消除大部分相关问题（然而我没找到任何能确认这一点的现实用例），该功能的简要介绍可参阅Postgres.HOT。这个功能的大致思路是：在HOT正常工作的前提下，如果新行可以放入同一页，那么无论Ctid如何变化，索引依然会指向同一页，因此无需更新索引。当然这种想法有一定效果，但前提是新行可以放入同一页，为此似乎可以通过“机会型的（Opportunistic）