为0LTP选择RDMBS时，您需要考虑什么？

我们经常需要为OLTP（事务/操作）选择正确的RDBMS（关系管理系统）. 尽管可以通过编写可移植的SQL来暂时避免做出这样的选择，但是迟早要做出这样的选择至少需要这样的尝试（例如，意识到特定的选择还不够清楚，因此决定在整个过程中选择SQL RDB MS）.

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

在开始讨论“哪种RDBMS是最好的”圣战之前，可能有必要首先弄清楚以24x7运行的生产级OLTP RDBMS需要哪些基本功能.

一个，基于锁或基于MVCC

考虑到并发性，目前几乎所有RDBMS都不过基于锁（基于锁）或MVCC（多版本并发控制）. 从具有更大写入负载的OLTP处理的角度来看，我已经看到:

对于混合的读写工作负载（例如OLTP事务和报告），基于MVCC的RDBMS的性能要比基于锁的RDBMS稍好.

如果隔离级别高于“读取未提交”，则效果会更好，并且最适合读取/报告目的.

另一方面，OLTP很少遇到大量并发读取. 如果确实遇到这种情况，通常可以传递副本

（Replica）执行此类读取，因此不会引起太大的问题.

在大多数情况下，OLTP是基于写的（不需要创建很多报告），基于锁的RDBMS的性能略好于MVCC. 但是，如果可以让OLTP工作负载使用INSERT而不是UPDATE，那么MVCC会更有效.

此外，值得注意的是，如果使用单写连接体系结构，则基于锁的RDBMS与基于MVCC的RDBMS之间的逻辑差异将很小（尽管性能略有不同，<

但是其他方面几乎是相同的，基于锁的RDBMS通常稍微领先一些.

第二个ACID保护

对于OLTP，我们需要为涉及多行和多表的事务提供ACID保护.

如上所述，对于OLTP，我们需要为事务提供全面的ACID保护. 更重要的是，您需要确保涉及多个行和多个表的事务具有ACID特性. 尽管有此规则的例外，但实际上这种例外很少见.

这几乎自动排除了将MySQL + MyISAM用作OLTP的可能性. 但是，还应注意，MySQL + ISAM对于某些应用程序（例如后端跟踪系统或系统监视工具）可能是一个不错的选择，但不适用于涉及某些类型资金的常规OLTP处理，相关信息.

此外，RDBMS提供的ACID保护几乎等同于意味着需要使用日志，这还意味着一旦RDBMS崩溃，日志就需要自动恢复（并自动前滚） ）.

三，支持24×7操作

作为联机备份的替代方法，可以使用异步主从复制（Replication）. 我们需要的另一系列功能主要与24×7不间断操作有关（例如游戏服务器，必须以24/7运行，对吗？）. 这些功能包括:

备份. 无论您做什么，都肯定需要备份，而备份则24x7全天候运行是必不可少的.

1. 一般而言，备份是指“先记录日志”的功能. 在大多数情况下，它都是这样工作的: 创建两个，一个作为“主”，一个作为“从属”；然后从“主服务器”获取日志文件并将其发送到“从服务器”，然后在从上执行“前卷”.

此外，某些可以在“日志前”状态下对“从属”执行只读请求（实际上等同于创建只读从属副本）. 但是，其他一些RDBMS无法处理此类请求（例如，在从属RDBMS可以接受查询操作之前，需要先完成“卷前记录”操作）.

2. 作为备份的替代方法，您还可以通过异步主从复制获得几乎完全同步的备份副本（这种方法对于MySQL + InnoDB来说是一个特别有趣的选择）.

应该注意的是，这样的副本可能支持或不支持“时间”恢复bs运行日志分类，例如备份+前卷（请参阅文档以获取详细信息）. 尽管从某些非常糟糕的情况中恢复时仅需要“时间点”恢复（我在实际生产环境中从未遇到过这种恢复情况），但真正遇到如此糟糕的情况至少可以帮助我们一方面<​​/ strong>

3. “即时” ADD COLUMN语句. 可以肯定的是，我们可能需要扩展生产环境的. 大多数情况下，这是通过ALTER TABLE ... ADD COLUMN语句实现的. 面对AD DCOLUMN语句，许多RDBMS只会将整个表重写为新格式的行. 如果表包含10亿行，此过程可能需要几个小时？ （在复制过程中，整个表将完全不可访问，从而导致在几个小时内变得无法使用？）. ADD COLUMN几乎可以立即执行（考虑到表的大小，可能需要几毫秒的时间）. 它不需要任何困难的技术即可完成执行. 一些RDBMS也可以执行此操作，但是不能忽略它. 这不是一种通用特征.

当预算不足时，另一种方法是实现无锁的ADD COLUMN（和传统的ALTER TABLE），如下所示:

使用新结构创建“影子”表

通过触发器将对当前表的所有更改写入影子表

将数据从当前表复制到影子表（请确保忽略现有行，因为触发器已写入内容）用影子表替换当前表

这种“便宜”的ADDCOLUMN方法非常麻烦（整个过程将对性能产生很大影响）bs运行日志分类，但是，如果没有其他更好的方法，这种方法至少可以起到一定的作用.

“即时” ALTER COLUMN（场扩展，场扩展）也是一个很好的功能，但是因为可以通过ADD COLUMN模拟场扩展，所以它似乎不太重要.

4. 表格优化. 此功能需要引入. 由于RDBMS会不断修改表的内容，因此表的性能会逐渐变差（实际上取决于所使用的存储引擎，从“溢出行”到“死行（Dead row）”），我们将遇到各种不良情况发生了）. 因此，有必要进行某些优化（例如InnoDB的OPTIMIZE TABLE，DB / 2的REORG TABLE，Postgres的VACUUM等），而我们将需要完成这些操作（无需完全关闭整个，因为它包含数百万行内容的表优化通常需要很长时间.

大多数时候，这种优化需要创建“影子副本”（由本身创建，这比要求我们手动创建它们更好），这也意味着需要额外的存储空间. 但是，至少有一个RDBMS提供“就地”表优化功能.

5. 重新平衡容器. 尽管没有上面列出的其他问题那么重要，但我始终认为“容器的重新平衡”也是RDBMS要考虑的重要问题.

简单来说，此问题主要发生在添加存储数据的新硬盘时（有时会发生），并且通过在所有硬盘上分散数据来实现加速. 这可以通过以下两种方法之一来实现:

（a）使用RAID-10（因此无需考虑存储数据的方式）

（b）通过多个RAID-1磁盘使用容器（因为本质上使用类似的RAID-0工作原理）.

只要不需要添加新的硬盘驱动器（实际上，通常在添加时为了实现冗余，通常成对添加硬盘驱动器），所有系统基本上是相等的，但是在添加新的硬盘对之后硬盘驱动器，我们需要执行“重新平衡”以实现负载平衡. 此“重新平衡”工作分别由RAID或Aoku执行. RAID级别重新平衡对服务器性能的影响远大于级别的重新平衡（特别是在某些情况下，系统甚至无法承受RAID级别重新平衡过程中产生的负载）.

原始地址:

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-208066-1.html