内存数据库的架构设计及原理.docx

内存数据库的架构设计及原理内存数据库的架构设计及原理 内存数据库把数据全部或者当前工作部分驻留在内存 中，消除了传统磁盘数据库系统中 I/O 瓶颈，极大的提高 了系统的性能和吞吐量，但是由于所有操作都作用于内存 数据库的主拷贝上，数据库及易遭到操作系统和应用软件 造成的破坏，因此 MMDB 的恢复技术十分关键。日志恢复是 传统的 MMDB 恢复技术之一，它能满足当前 MMDB 系统对事 务响应和快速系统恢复的要求，但是在大量事务吞吐量情 况下造成的日志暴增所带来很大问题，会对 MMDB 性能产生 很大影响。 本文提出 MMDB 系统快速日志恢复技术，它是在不阻碍 系统正常运行的情况下，控制日志的产生数量，使得在系 统崩溃并重新启动时，能以最快的速度恢复到系统崩溃前 的最近一致点上。 快速恢复模型的整体架构如图 1 所示。事务处理模块 负责根据用户请求产生事务，并由事务管理器调度。事务 管理器将负责各个事务的日志记录，交给日志产生规则处 理。检查点模块根据日志产生规则才产生的日志数量动态 调整检查点启动时间。当日志记录数达到一定值时，检查 点程序启动。它读取所有日志记录，交给日志筛选器。日 志筛选器根据筛选算法，从当前所有日志项中筛选出实际 有效的日志记录，并将这些有效日志记录交给日志分发结 点。日志分发结点主要做两项工作：第一是它将日志传送 给日志磁盘管理器，由其负责将日志回写到日志磁盘上， 第二是日志分发结点将日志传送给备份更新发生器。备份 更新发生器利用快速恢复算法，触发各类更新操作，根据 日志更新磁盘上的数据。 图 1 快速恢复模型的整体架构 该快速恢复模型具有如下的特点： 快速恢复模型以日志驱动方式做检查点，异步更新 磁盘上的备份数据镜象。 系统只维护全局 Redo 日志，以 Redo 日志来驱动备 份更新发生器，各个事务维护私有 Redo 日志和 Undo 日志 在事务提交时将私有 Redo 日志写入全局 Redo 日志中。 使用日志筛选算法，近一步减少 Redo 日志的数量， 提升检查点程序的性能。 备份数据镜象只反应己提交事务的更新状态，因此 在系统重载时不需要回退未提交的事务。 快速恢复算法为并发重载算法。在系统恢复过程中， 能继续接受新事务的请求。 快速日志驱动检查点的基本思想是，检查点程序仍然 由日志来驱动，根据读取到的日志项来更新数据镜象上的 内容，维持数据镜象与内存中数据库的基本同步。但是， 与以往日志驱动检查点算法不同的是，它通过日志产生规 则和日志筛选算法两个策略克服了以往日志驱动检查点算 法中日志数量可能过快增长的问题。 日志产生规则 快速日志驱动检查点算法中设立的日志产生规则是： 系统中日志被分为全局日志和私有日志两类。系统只维护 全局 Redo 日志，而不维护 Undo 日志，由事务自身维护私 有的 Redo 日志和 Undo 日志。在事务提交时，依照事务提 交的先后顺序，将事务的私有 Redo 日志添加到全局 Redo 日志中。因此，在事务运行过程中，会产生 Redo 日志和 Undo 日志。Redo 日志用于在系统恢复过程中，重做已提交 事务。而 Undo 日志用于在事务 Abort 时回退事务，或者在 系统恢复过程中回退未提交的事务。如果恢复模型的设计 能够保证系统恢复过程中，没有需要回退的未提交事务， 那么系统只需要读取 Redo 日志而不需要读取 Undo 日志。 因而系统只需要维护全局的 Redo 日志，而不需要维护 Undo 日志，将 Undo 日志交给事务自身维护，Undo 日志只用于事 务自身 Abort 时回退。这样就可以减少全局日志的总量。 图 2 具体描述了全局日志和私有日志的使用。在事务 T1，T2， T3 的内存空间内，各自维护自己的私有 Redo 日 志和 Undo 日志。在非易失性内存(SRAM)上，MMDB 系统开辟 全局 Redo 日志缓冲区，让事务在提交时事务的私有 Redo 日志写入该缓冲区。检查点程序将定期读取日志缓冲区中 的数据，将日志写入磁盘，并驱动检查点程序更新磁盘镜 象数据。 图 2 全局日志和私有日志 各事务将按如下阶段操作日志： 事务启动时，需要在事务的各自空间内建立私有 Redo 日志和私有 Undo 日志，并将在私有 Redo 日志中写入 事务启动记录。 事务运行过程中，事务的每次更新操作，需要在私 有 Redo 日志中添加 Redo 记录，并在私有 Undo 日志中添加 Undo 记录。 事务提交时，需要按如下步骤完成： 向事务的私有 Redo 日志内添加事体 Commit 记录。 将事务的私有 Redo 日志写入全局 Redo 日志中。 释放事务的私有 Redo 日志和私有 Undo 日志，释放 事务所占用的其他资源，完成提交。 事务 Abort 时，需要按照如下步骤完成： 事务反向扫描私有 Undo 日志，回退事务的更新操作。 释放事务的私有 Redo 日志和私有 Undo 日志，释放 事务所占用的其他资源，结束事务。 由此可见，事务只在提交时才将私有 Redo 日志写入全 局日志缓冲区。从而也保证了，检查点程序运行时，只看 到己提交事务的 Redo 日志，磁盘上的数据镜象也只反映已 提交事务的更新操作。 日志筛选算法 用日志产生规则能明显减少日志产生的数量，但是在 更新事务吞吐量较大的情况下，检查点程序从全局日志缓 冲区读取 Redo 日志时，仍然可能会面对 Redo 日志量过大 的问题。产生的原因是这样的：如果对一份数据做两次更 新操作，那么两个事务各自产生一条对同一物理地址上值 更新的物理日志，但只有第 2 次更新事务产生的日志为有 效的。本文利用日志筛选算法来避免日志量过大问题。该 算法认为，当 LOG1(T1，addr，valuel)和 LOG2(T2, addr, value2)按照事务的提交顺序通过日志筛选器时，当 T1 的 提交时间在 T2 提交时间前，那么只有 LOG2(T2, addr, value2)被认为是有效，而 LOGI(T1，addr，valuel)被忽略。 日志筛选器需要关注物理日志中被修改值的地址的相关性。 对相同修改地址的物理日志依据日志的提交顺序进行筛选。 为加快日志的筛选速度，将全日志缓冲区划分为多个区域， 这将日志记录中操作地址具有空间相关性的日志按照所属 事务的提交顺序聚合在一个区域内，能加速日志筛选算法 的筛选速度。使得在筛选过程中，只需在小范围内(也就是 一个区域)搜索可以被筛选的日志。当全局 Redo 日志缓冲 区中的某一个区域满时，就唤醒检查点程序，将这一区域 中的 Redo 日志写入日志磁盘，并驱动备份更新发生器更新 磁盘上的数据镜象 在系统崩溃后，MMDB 系统需要通过恢复过程，将数据 库恢复到崩溃前的最近一致点上。在系统恢复过程中，重 载程序将数据从磁盘镜象上加载到 MMDB 系统中，同时根据 日志，重做(Redo)或者取消(Undo)部分事务，来恢复数据 库的一致性。 快速恢复算法如下算法步骤: 当系统崩溃重启时，先启动日志检查和分配程序， 检查非易失性内存(SM)中提供给事务提交时用于写入私有 Redo 日志的缓冲区中是否有完整写入的 Redo 日志。如果有 完整的 Redo 日志，则日志检查和分配程序将这些完整的日 志分配到全局 Redo 日志缓冲区的不同区域中。 统计全局 Redo 日志缓冲区中的日志数量，并标记这 些日志。当前 Redo 日志缓冲区中的日志将被用于恢复内存 中 MMDB 系统的一致性，同时也要用于维护磁盘上数据镜象 的一致性。 恢复程序从磁盘数据镜象上加载一些重要的系统表 以后，MMDB 系统可以启动，并可以接受新事务的请求。系 统的正常事务处理和系统恢复过程同时进行。 触发检查点程序从全局 Redo 日志缓冲区中读取日志， 驱动备份更新发生器更新磁盘上的数据镜象。在这过程中， 驱动备份更新发生器向缓冲区管理区询问将被更新的记录 所在的镜象数据页面是否已经被加载到内存中。如果己经 被加载，则不但需要更新磁盘上的镜象数据页，还需要更 新内存中的数据页面。如果全局 Redo 日志缓冲区中所有被 标记的日志都已经被用于驱动备份更新发生器，那么此时 备份更新发生器可以告诉重载程序恢复工作已经完成，没 有其他镜象页面需要更新。 MMDB 在接受新事务的请求时，对于事务的所访问到 的数据，如果数据还没有被加载内存中时，则系统向重载 程序要求将所需数据从磁盘镜象上加载到内存中。此时， 重载程序先要检查要求加载的数据页面是否会被备份更新 发生器修改。如果是，则需要等待备份更新发生器更新镜 象页面后再加载到内存中，否则就直接将镜象页面加载到 内存中。 当所有镜象都加载完成后，MMDB 系统恢复过程结束。 恢复技术是保证内存数据库运行可靠的关键技术。传 统日志恢复技术由于存在产生过多不必要的日志的缺点， 本文研究了一种新的日志恢复技术来尽可能的减少日志数 量，并在此基础上提出了快速日志恢复算法。本文提出的 恢复技术算法简单可以大大的节约系统的资源。然而，内 存数据库恢复是一个十分复杂而庞大的技术，所以该方法 还有待完善。 参考文献 刘云生，潘琳. 实时数据库系统的内存数据库组织与