购物网站哪个东西便宜质量好,传奇手游代理平台价格表,国内互联网推广,wordpress 团购任何数据库的主要要求之一就是实现可伸缩性。只有将争用#xff08;锁定#xff09;最小化#xff08;如果不能一起删除#xff09;#xff0c;才可以实现。由于读/写/更新/删除是数据库中发生的一些主要的频繁操作#xff0c;因此对于这些操作并发进行而不被阻塞非常重要…任何数据库的主要要求之一就是实现可伸缩性。只有将争用锁定最小化如果不能一起删除才可以实现。由于读/写/更新/删除是数据库中发生的一些主要的频繁操作因此对于这些操作并发进行而不被阻塞非常重要。为了实现这一目标大多数主要数据库都采用了一种称为多版本并发控制的并发模型该模型将争用降低到最低限度。什么是MVCC多版本并发控制以下简称MVCC是一种算法可通过维护同一对象的多个版本来提供精细的并发控制以使READ和WRITE操作不会冲突。这里的WRITE表示UPDATE和DELETE因为无论如何新插入的记录都将按照隔离级别受到保护。每个WRITE操作都会生成对象的新版本并且每个并发读取操作都会根据隔离级别读取对象的不同版本。由于读取和写入操作均在同一对象的不同版本上进行因此这些操作都不需要完全锁定因此两者都可以并发操作。争用仍然存在的唯一情况是当两个并发事务尝试写入同一记录时。当前大多数主要数据库都支持MVCC。该算法的目的是维护同一对象的多个版本因此MVCC的实现因数据库而异仅在创建和维护多个版本方面有所不同。因此相应的数据库操作和数据存储发生了变化。公认的实现MVCC的方法是PostgreSQL和Firebird / Interbase使用的一种而InnoDB和Oracle使用的另一种。在随后的章节中我们将详细讨论如何在PostgreSQL和InnoDB中实现它。PostgreSQL中的MVCC为了支持多个版本PostgreSQL维护每个对象的其他字段PostgreSQL术语为Tuple如下所述xmin –插入或更新元组的交易的交易ID。如果是UPDATE则将使用此事务ID分配更新版本的元组。xmax –删除或更新元组的交易的交易ID。如果是UPDATE则为元组的当前现有版本分配此事务ID。在新创建的元组上此字段的默认值为null。PostgreSQL将所有数据存储在称为HEAP的主存储中页面的默认大小为8KB。所有新元组都将xmin作为创建它的事务进行处理而旧版本元组已更新或删除将分配给xmax。从旧版本元组到新版本始终存在链接。在隔离的情况下较旧版本的元组可用于在回滚的情况下重新创建元组并可通过READ语句读取较旧版本的元组。考虑到表有两个元组T1值1和T2值2可以在下面的3个步骤中演示新行的创建MVCC在PostgreSQL中存储多个版本如图所示数据库中最初有两个元组其值分别为1和2。然后在第二步中将值2的行T2更新为值3。这时将使用新值创建一个新版本并将其存储为与现有元组相邻并将其存储在同一存储区域中。在此之前较旧的版本将分配给xmax并指向最新版本的元组。类似地在第三步中当删除具有值1的行T1时将在同一位置虚拟删除现有行即它为当前事务分配了xmax。没有为此创建新版本。接下来让我们看一下每个操作如何创建多个版本以及如何保持事务隔离级别而不用一些实际示例进行锁定。在下面的所有示例中默认情况下使用“ READ COMMITTED”隔离。插入每次插入记录时都会创建一个新的元组并将其添加到属于相应表的页面之一中。PostgreSQL并发INSERT操作正如我们在这里看到的逐步会话A启动事务并获取事务ID 495。会话B启动事务并获取事务ID 496。会话A插入一个新的元组获取存储在HEAP中现在添加了将xmin设置为当前事务ID 495的新元组。但是从会话B中看不到相同的内容因为xmin即495仍未提交。一旦提交。数据对两个会话均可见。更新PostgreSQL UPDATE不是“ IN-PLACE”更新即它不会使用所需的新值来修改现有对象。相反它将创建该对象的新版本。因此UPDATE大致涉及以下步骤它将当前对象标记为已删除。然后它添加该对象的新版本。将对象的旧版本重定向到新版本。因此即使许多记录保持不变HEAP也会占用空间就好像插入了多条记录一样。PostgreSQL并发INSERT操作正如我们在这里看到的逐步会话A启动事务并获取事务ID 497。会话B启动事务并获取事务ID 498。会话A更新现有记录。在这里会话A看到一个版本的元组更新的元组而会话B看到另一个版本旧元组但xmax设置为497。两个元组版本都存储在HEAP存储中甚至同一页面也取决于空间可用性一旦会话A提交了事务则由于提交了旧元组的xmax旧元组将过期。现在两个会话都看到相同版本的记录。删除删除几乎与UPDATE操作类似只是它不必添加新版本。只是将当前对象标记为DELETED如UPDATE情况中所述。PostgreSQL并发DELETE操作会话A启动事务并获取事务ID 499。会话B启动事务并获取事务ID 500。会话A删除现有记录。在这里会话A没有看到任何从当前事务中删除的元组。而Session-B看到该元组的较旧版本xmax为499删除该记录的事务。一旦会话A提交了事务则由于提交了旧元组的xmax旧元组将过期。现在两个会话都看不到已删除的元组。如我们所见没有任何操作可以直接删除对象的现有版本并且在需要的地方都可以添加对象的其他版本。现在让我们看一下如何在具有多个版本的元组上执行SELECT查询SELECT需要读取所有版本的元组直到根据隔离级别找到合适的元组为止。假设有元组T1它已更新并创建了新版本T1并在更新时又创建了T1SELECT操作将通过此表的堆存储并首先检查T1。如果提交了T1 xmax事务则它将移至该元组的下一个版本。假设现在也提交了T1元组xmax然后再次移动到该元组的下一个版本。最后它找到T1并看到xmax未提交或为null并且根据隔离级别T1xmin对于当前事务可见。最后它将读取T1元组。如我们所见它需要遍历元组的所有3个版本以便找到合适的可见元组直到过期的元组被垃圾收集器VACUUM删除为止。InnoDB中的MVCC为了支持多个版本InnoDB为每行维护其他字段如下所述DB_TRX_ID插入或更新该行的事务的事务ID。DB_ROLL_PTR它也称为回滚指针它指向写入回滚段的撤消日志记录在下一个更多内容中。与PostgreSQL一样InnoDB在所有操作中也会创建该行的多个版本但是旧版本的存储有所不同。对于InnoDB更改后的行的旧版本保存在单独的表空间/存储中称为undo段。因此与PostgreSQL不同InnoDB在主存储区中仅保留行的最新版本而在undo段中保留较旧的行。还原段中的行版本用于回滚时的撤消操作并根据隔离级别通过READ语句读取旧版本的行。考虑到表有两行T1值1和T2值2可以通过以下3个步骤来演示新行的创建MVCC在InnoDB中存储多个版本从图中可以看出数据库中最初有两行其值分别为1和2。然后在第二阶段中将值2的行T2更新为值3。这时将使用新值创建新版本并替换旧版本。在此之前较旧的版本将存储在撤消段中请注意UNDO段版本仅具有增量值。另外请注意回滚段中有一个从新版本到旧版本的指针。因此与PostgreSQL不同InnoDB更新是“ IN-PLACE”。类似地在第三步中当删除具有值1的行T1时则在主存储区域中虚拟删除了现有行即它只是在行中标记了一个特殊位并在其中添加了与之对应的新版本。撤消段。同样从主存储器到撤消段只有一个滚动指针。从外部看所有操作的行为均与PostgreSQL相同。只是多个版本的内部存储有所不同。MVCCPostgreSQL与InnoDB现在让我们分析PostgreSQL和InnoDB在MVCC实现方面的主要区别是什么旧版本的大小PostgreSQL只是在元组的较旧版本上更新xmax因此较旧版本的大小与相应的插入记录相同。这意味着如果您有3个版本的旧元组则所有版本都将具有相同的大小除非每次更新时实际数据大小有所不同。而对于InnoDB存储在Undo段中的对象版本通常小于相应的插入记录。这是因为仅将更改的值即差分写入UNDO日志。INSERT操作即使对于INSERTInnoDB也需要在UNDO段中写入一条额外的记录而PostgreSQL仅在UPDATE的情况下才创建新版本。在回滚的情况下还原旧版本PostgreSQL不需要任何特定的东西就可以在回滚的情况下恢复旧版本。请记住旧版本的xmax等于更新此元组的事务。因此在提交该事务ID之前对于并发快照它被视为活动元组。事务回滚后所有事务都会自动将相应的事务视为活动事务因为这将是中止的事务。而对于InnoDB则明确要求在回滚发生后重建对象的旧版本。回收旧版本占用的空间对于PostgreSQL仅当没有并行快照读取该版本时才可以将较早版本占用的空间视为已耗尽。旧版本失效后VACUUM操作可以回收它们所占用的空间。VACUUM可以手动触发也可以作为后台任务触发具体取决于配置。InnoDB UNDO日志主要分为INSERT UNDO和UPDATE UNDO。相应的事务提交后第一个将被丢弃。第二个需要保留直到与任何其他快照平行为止。InnoDB没有显式的VACUUM操作但是在类似的行上它具有异步的PURGE来丢弃作为后台任务运行的UNDO日志。延迟真空的影响如前所述在PostgreSQL的情况下延迟真空会产生巨大的影响。即使不断删除记录它也会导致表开始膨胀并导致存储空间增加。它也可能达到需要完全抽真空的地步这是非常昂贵的操作。如果表格过大则顺序扫描PostgreSQL顺序扫描必须遍历对象的所有旧版本即使所有旧版本都已失效直到使用真空将其删除为止。这是PostgreSQL中最典型且讨论最多的问题。请记住PostgreSQL将所有版本的元组存储在同一存储中。而对于InnoDB除非需要否则不需要读取撤消记录。如果所有撤消记录都已失效则仅足以读取对象的所有最新版本。指数PostgreSQL将索引存储在单独的存储中该存储与HEAP中的实际数据保持一个链接。因此即使INDEX不变PostgreSQL也必须更新INDEX部分。尽管稍后通过实现HOT仅堆元组更新解决了此问题但仍然存在一个局限即如果无法在同一页面中容纳新的堆元组则它将回退到常规UPDATE。InnoDB没有问题因为它们使用聚集索引。结论PostgreSQL MVCC没有什么缺点特别是在工作负载频繁更新/删除的情况下存储空间过大。因此如果您决定使用PostgreSQL则应该非常小心地配置VACUUM。PostgreSQL社区也承认这是一个主要问题他们已经开始研究基于UNDO的MVCC方法临时名称为ZHEAP我们可能会在以后的版本中看到同样的情况。
