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

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

《为oltp选择rdmbs时你都需要考虑哪些.docx》由会员分享，可在线阅读，更多相关《为oltp选择rdmbs时你都需要考虑哪些.docx（14页珍藏版）》请在冰豆网上搜索。

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

为OLTP选择RDMBS时，你都需要考虑哪些？

译者|大愚若智策划｜木环我们经常需要为自己的OLTP（事务/运营）数据库选择适合的RDBMS（关系型数据库管理系统）。

虽然通过编写可移植的SQL可以暂时避免进行这样的选择，但迟早要做出这样的选择，至少需要进行这样的尝试（比如，意识到具体的选择不够明确，因此决定选择跨RDBMS的SQL）。

生产环境中选择RDBMS的标准是？

在发起“到底哪个RDBMS最好”的讨论圣战之前，也许需要首先明确一下对于24x7运行的生产级OLTPRDBMS，到底需要具备哪些必不可少的功能。

一、基于锁，或是基于MVCC

考虑到并发性，目前几乎所有RDBMS无外乎基于锁的（Lock-Based），或基于MVCC（多版本并发控制）的。

从写负载更重的OLTP处理角度来说，我曾经见到过：

对于读写混合型负载（例如OLTP事务和报表），基于MVCC的RDBMS表现会比基于锁的略好一些。

如果使用高于ReadUncommitted的隔离级别，效果还会更好，最适合用于读取/报表用途。

另一方面，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、“即时”的ADDCOLUMN语句。

我们可能需要对生产环境的数据库进行扩展，这一点是确定无疑的。

大部分时候这是通过ALTERTABLE…ADDCOLUMN语句实现的。

面对ADDCOLUMN语句，很多RDBMS会简单地将整个表重写为新格式的行。

如果表包含10亿行，这一过程可能需要数小时?

（在进行复制的过程中，整个表将完全无法访问，导致数据库在数小时内无法使用?

）。

让ADDCOLUMN能够近乎即时（考虑到表的大小，可能需要几毫秒的时间）执行完成并不需要什么艰深的技术，有些RDBMS也确实能做到这一点，但是也不能忽视，这并不是一种普遍特性。

预算不足时的备选方案是实现无锁ADDCOLUMN（以及常规的ALTERTABLE），方法如下：

用新的结构创建“影子”表通过触发器将对当前表的所有改动写入影子表将数据从当前表复制到影子表（一定要忽略已存在的行，因为触发器已经在其中写入内容了）用影子表取代当前表这种“廉价”的ADDCOLUMN方法相当繁琐（全过程会对性能产生极大影响），但如果没有其他更好的方法，这种做法至少可以起到一定的效果。

“即时”ALTERCOLUMN（字段拓宽，Wideningfield）也是个很好的功能，但因为字段拓宽可通过ADDCOLUMN模拟，因此显得并不是太重要。

4、联机表优化。

这个功能需要介绍一下。

由于RDBMS会不断修改表内容，表的性能会逐渐退化（实际上取决于所用存储引擎，从“行溢出（Overflowrow）”到“死行（Deadrow）”，我们会遇到各种不希望出现的情况）。

为此有必要进行一定的优化（例如InnoDB的OPTIMIZETABLE，DB/2的REORGTABLE，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数据库尤为如此。

另外从Postgres8.3开始提供了一种所谓的Heap-OnlyTuples（HOT）功能，该功能至少在理论上应该能消除大部分相关问题（然而我没找到任何能确认这一点的现实用例），该功能的简要介绍可参阅Postgres.HOT。

这个功能的大致思路是：

在HOT正常工作的前提下，如果新行可以放入同一页，那么无论Ctid如何变化，索引依然会指向同一页，因此无需更新索引。

当然这种想法有一定效果，但前提是新行可以放入同一页，为此似乎可以通过“机会型的（Opportunistic）Mini-vacuum”实现：

尽管Postgres依然无法清理（Prune）需要更新的Tuple（出于MVCC的考虑必须保持精简），但（据推测）可以对同一页中较旧的Tuple进行清理，这样也许可以在同一页中保存新行并避免更新索引。

底线是：

虽然Postgres存在不必要的索引更新问题，但通过HOT功能大幅缓解了这个问题，但HOT能否完全解决这个问题还有待讨论（这种缓解过程可能需要额外的配置以便在页中为HOT提供所需的空间），但至少我们可以针对数据库实例监视HOT的运行效率（可参阅Postgres.HOT）。

MemSQL：

投票式日志写入虽然内存中数据库为OLTP应用提供了巨大收益，但我并不会出于这种用途考虑选择MemSQL，原因如下。

正如Mituzas所述，MemSQL会使用耗时50毫秒的投票发起数据库日志写入操作。

对任何类型的OLTP数据库来说这都是一种很糟糕的做法，但如果你考虑我的建议选择单一写入数据库连接架构，MemSQL的这种所谓“功能”会造成极为严重的后果。

一定要反复核实该产品是否还在使用这个功能，如果在使用，至少应该尽量避免使用单一写入数据库连接的配置。

执行计划和Profiling为了对SQL语句进行调试和Profiling，至少需要具备一个能展示SQL查询“执行计划”的工具。

面对生产数据库，我们需要对SQL语句进行调试和Profiling。

至少需要具备一个能展示SQL查询“执行计划”的工具。

这样才能预测查询的执行方式（即，SQL语句编译后的执行计划将用于生产数据库，或从生产数据库状态导入的数据库）。

另外执行计划只能告诉我们预测的执行成本（通过数据库状态计算而来），但可能与实际情况存在数量级的差异。

为此可以使用某些类型的实时Profiling技术。

这类工具可能有一定的作用，但在我看来并非绝对必要：

通常来说只要具备一些经验和常识，就可以很容易地发现这些与查询有关的性能问题（一般来说，迫使数据库使用我们指定的查询计划，这往往要比确定当前所用查询计划表现欠佳的原因更为困难）。

内存中处理目前已经有不少RDBMS提供了内存中处理功能。

这些功能主要可分为两类：

非持久内存中处理。

例如通过RAM磁盘运行RDBMS，以及为MySQL使用MEMORY存储引擎。

但这种方式通常无法用于OLTP数据库。

持久内存中处理。

这种方式类似于在应用和RDBMS之间添加了一层内存缓存（实际上Oracle的TimesTenIMDBCache就是作为一种缓存进行宣传的）。

下文将要介绍的所有大型商用RDBMS供应商都提供了类似技术，但每种技术都需要耗费血本。

然而非持久内存中处理技术通常并不适合OLTP数据库复制

面对极高的负载，我们迟早需要为数据库创建（只读的）副本（Replica）。

如果所用RDBMS产品支持复制（并能正确使用），就可以自动创建所需副本。

大部分时候我们最需要的是一种所谓的主从异步复制（这样从副本的延迟才不会影响主副本）。

此外可能还会用到其他相关功能，例如副本合并（同样适用于简单的主从异步环境，但绝对不会产生任何冲突）。

然而从我个人的经验来看，RDBMS提供的复制功能在高负载情况下通常表现都很糟。

有这样一个极端案例：

在负载持续多天维持每天不超过1百万笔事务的情况下，复制功能总是因为一些难以理解的错误而失败，需要对副本进行完整的重新同步（这也是个非常头疼的问题）。

这种情况告诉我们：

在实际使用前一定要通过极为严苛的负载对复制机制进行测试。

DUD：

设备或机械由于无法正常工作或运转失败而显得无用。

—维基词典好在如果你选择的复制技术恰好就是这样的“DUD”（并且使用了单一连接的方法），还可以用相对较为简单的方法自行进行复制。

分区

RDBMS提供的分区（Partitioning）是一种实现可缩放性的工具，但往往会被过度吹捧。

但是我本人也倾向于选择无需共享（Share-Nothing）的模式（并采用应用层面的分区），因为相比将一个数据库分区至多台服务器，这种方式可以上线更为线性的缩放能力。

但有些情况下RDBMS提供的分区功能也会显得较为有用，因此如果提供有这样的功能，也可以将其看作一个“加分项”（尽管可能并不像RDBMS销售人员说的那么天花乱坠）。

对OLTP而言，哪些不该是问题

在比较不同RDBMS时，你肯定会看到有关不同RDBMS对JOIN的支持情况，或对SQL标准不同解释的大量争议。

然而有一件事必须注意：

虽然所有这些问题对“报表”和“分析”数据库非常重要，但从以往经验来说，对OLTP数据库并不重要。

OLTP数据库是一种很奇怪的东西，尤其是这一领域很少会使用JOIN语句。

当然，你可能有时候会需要JOIN（毕竟这是SQL的全部），但大部分情况下OLTP数据库并不需要JOIN（哪怕真的需要JOIN，也可以非常简单地实现）。

因此除非为“报表”和“分析”使用同一个数据库（下文将详细介绍），这个问题其实并不重要。

然而有些时候确实需要为“报表”和OLTP使用同一个RDBMS然而有些时候确实需要为“报表”和OLTP使用同一个RDBMS，尤其是恰巧在这两类数据库之间进行了RDBMS级别的复制时，可以无需自行实现，直接获得所需副本（过程较为简单，但非常耗时）。

RDBMS供应商（尤其是商用供应商）还过度鼓吹了另一个问题：

容错。

使用容错功能的数据库服务器并不能保证可以改善MTBF（考虑到容错系统本身的MTBF并非无限的，很容易得出这样的结论）。

更重要的是，现实情况告诉我们，容错功能的MTBF通常低于高质量服务器硬件自身的MTBF，这意味着如果不使用容错机制，系统本身的MTBF反而更高（这也是现实世界中经验得出的结论）。

换句话说，对于高质量服务器，硬件（例如CPU或主板）故障几率远低于容错系统出错（进而导致各种类型的麻烦，直到最棘手的“脑裂（Splitbrain）”）的几率。

当然，有些情况下确实需要容错（例如证交所或银行的系统），但这些系统很可能运行在DB/2/Oracle产品之上，它们在这方面表现其实差不多，因此RDBMS的容错问题也就不那么重要了。

方案对比分析

三家商用DB的情况概览

一旦开始考虑商用RDBMS的许可问题，你会发现这些产品不仅昂贵，而且许可机制极为复杂，可能需要花费数天时间才能理解到底要花多少钱。

最后同样重要的一个问题：

还需要考虑许可的获取及相关成本。

一旦开始考虑商用RDBMS的许可问题，你会发现这些产品不仅昂贵，而且许可机制极为复杂，可能需要花费数天时间才能理解到底要花多少钱。

我对截止2016年底市面上三大商用RDBMS的许可情况分析如下。

首先是几个说明：

我会尽可能以“每内核”方式比较不同产品的价格。

我只关注面向生产环境的许可，“开发者版”、“学生版”，只能通过托管供应商获得的版本等特殊版本不予考虑。

此外我还会忽略“授权的客户端”这种许可模式（毕竟这种模式无法适用于用户数未知的部署）。

声明：

有关许可的介绍信息基于“我本人尽最大努力后的理解”，但不提供任何保证。

在制定任何决策，尤其是要购买昂贵的产品前，还行自行分析相关信息。

另外需要注意，虽然存在一些共同的趋势（例如免费提供较为基本的数据库产品），但商用数据库的许可经常会发生变化，尤其是内核数方面的限制，通常数量可能增加，但也有可能降低。

最后同样重要的是：

一定要与经销商好好砍价，有时候甚至能达到50%的折扣，对于更大金额的合约甚至折扣可以高达80%。

MicrosoftSQLServer2016在各大主要商用数据库中，MSSQLServer是最便宜，许可模式最简单的产品之一（没错，按照商用RDBMS的标准来看真的是既便宜又简单）。

注：

下列数据来自SQLServer.Editions。

1、MicrosoftSQLServerExpress成本：

免费。

局限：

最多1颗处理器（或4个内核，取较小值），1GB内存，数据库体积上限10GB。

SQLServer2016中这些限制适用于每实例，主要限制了每个实例（而非每台数据库服务器）可用资源总量，通过一台物理服务器运行多个实例绕过这些每实例限制的做法是官方允许的，详情请参阅SQLServer.CapacityLimits。

考虑到每个数据库10GB容量的限制，就算为每个服务提供一个数据库，也会很快达到上限。

因此该版本非常适合为每个服务提供一个数据库（无论是否使用单一数据库连接）的模式。

然而考虑到每个数据库10GB容量的限制，就算为每个服务提供一个数据库，也会很快达到上限。

具备的功能：

基本的SQL功能，支持24×7运行，可充当复制关系中的客户端。

欠缺的功能：

分区，充当复制关系中的主副本。

当然，该版本可以由用户自行进行分区和复制，如果希望针对企业版之外SQLServer版本自行分区，可使用一些工具，例如Clement实现。

2、MicrosoftSQLServerStandard成本：

约每内核2千-4千美元（可参阅Ozar和SQLServer.Pricing）。

局限：

最多4颗处理器（或24个内核，取较小值），128GB内存，数据库大小几乎无上限。

具备的功能：

基本的SQL，支持24×7运行、复制，及SQLProfiler。

缺乏的功能：

分区。

只要预算允许，SQLServerStandard是一款完整功能的RDBMS产品，很适合用于OLTP负载。

我通常更愿意选择该产品而非MySQL（出于可靠性和功能丰富程度的考虑），然而如果预算极为充足，我会考虑用DB/2或Oracle产品代替（虽然通常更贵，但相比MSSQL而言，长远来看通常会更可靠）。

3、MicrosoftSQLServerEnterprise成本：

每内核7千-1.4万美元。

局限：

无。

具备功能：

需要的一切功能，外加内存中OLTP处理。

缺乏的功能：

无。

SQLServerEnterprise无疑很贵，老实说我没看到该版本有任何实际用例，除了内存中OLTP（在这一领域SQLServer在价格方面远超其他所有商用RDBMS）。

其实如果你按照本书其他章节提供的思路来设计数据库架构，除非每天写入事务量上亿，否则通常并不需要内存中OLTP，这样价格也就显得不是那么的高。

IBMDB/210.5BMDB/2在一个领域是不容置疑的冠军：

尽可能让价格高到离谱让人难以置信。

然而DB/2也确实具备一些不错的技术特性（我本人就有良好的使用体验），因此成本分析中也包含了这个产品。

1、DB/2Express-C成本：

免费。

局限：

最多2个内核，16GB内存，数据库体积上限15TB。

这一系列限制适用于每台服务器（而非每个实例），但也可适用于每个虚拟化会话，详情请参阅RadaMelnyk。

具备的功能：

基本的SQL，支持24×7运行。

缺乏的功能：

分区，复制。

总的来说，对于大部分单一写入数据库连接部署（尤其是使用副本作为报表用途时），2内核的限制并不是太糟，通常可在无需面临太多局限的情况下满足要求。

其他局限其实也显得不是太糟糕了。

另外还可参阅上文自行实现分区和复制的介绍（DB/2的自行分区实现方式与SQLServer差不多）。

2、DB/2ExpressDB/2Express主要有两种值得我们考虑的定价模式。

成本：

DB/2Express主要有两种值得我们考虑的定价模式。

其中之一基于一种名为PVU（暂不考虑其含义）的概念：

约为每PVU70美元[3]及每内核100PVU，换算后价格为每内核7千美元。

另一种定价模式基于所谓的FTL概念，可将其简单理解为包年订阅的全套方案（初始TCO较低，长期范围内较高）。

然而我暂时没找到有关DB/2最新FTL定价的标准。

局限：

最多8内核，64GB内存（每服务器），数据库大小上限15TB。

具备的功能：

基本的SQL，支持24×7运行和复制（一种名为SQLReplication的复制方式）。

缺乏的功能：

分区，QReplication。

DB/2Express相当贵，但功能也相当强大。

对于OLTP应用，通常使用中不可能达到规格上限，但对报表（和分析）副本，这样的上限略微有些低。

3、DB/2Workgroup顾名思义，DB/2Workgroup与DB/2Express基本类似，但存在下列差异：

上限提高至16个内核与128GB内存（每服务器）。

相比DB/2Express，成本提高约1.5倍（大约每内核1万美元左右）。

是否可以将Workgroup版用于OLTP应用这不太好说，但报表副本可以从该版本提高的上限中获益。

4、DB/2Enterprise相比DB/2Workgroup，上限有所提高，但价格也有了5倍-6倍的提升（约为每内核5万美元左右！

）。

此外EnterpriseServer还提供了一些花哨的功能（例如QReplication），但老实说与其支付对这么贵的价格，不如自行开发复制机制;-）。

实际上我没看到任何将DB/2Enterprise用于OLTP的用例（甚至银行/证交所也不会这样做）。

5、DB/2Advanced*Server为了让许可机制变得更复杂，DB/2还提供了AdvancedWorkgroupServer和AdvancedEnterpriseServer版本。

这些版本的价格高得离谱（AdvancedWorkgroup的价格与非AdvancedEnterprise版价格类似，但AdvancedEnterprise的价格比非AdvancedEnterprise版高了1.5倍）。

另外他们还提供了每TB容量定价的模式（AdvancedWorkgroup版每TB容量约5万美元，AdvancedEnterprise版每TB10万美元）。

OLTP数据库的容量通常不会超过1TB（但他们没提供低于1TB容量的许可），因此可以将其理解为实际成本。

在OLTP处理方面，DB/2AdvancedWorkgroupServer的用例可能只有一个：

那就是你真的非常“不差钱”，并且同时你还需要内存处理技术。

OracleDatabase12c

相比BD