SQLite数据库的事务性FTL.pptVIP

BEA Confidential. | * SQLite的事务性FTL X-FTL: Transactional FTL for SQLite Databases BEA Confidential. | * 摘要 在智能手机和移动计算的时代,许多流行的应用Facebook,twitter,Gmail,甚至愤怒的小鸟游戏都在使用SQLite管理他们的数据。这主要是由于进步发展的生产力和坚实的事务处理能力在支持。然而,在事务原子性这层面来说，SQLite依赖于不那么复杂但昂贵的页面日志机制。因此,这被认为是移动应用程序产生延迟反应的主要原因。 闪存并不允许数据被更新时覆盖，并且目前大部分闪存设备都采用写时拷贝策略。本文中，我们提出了X-FTL，一个SQLite数据库中事务性的闪存转换层，通过把保证事物原子性的负担从宿主系统转移到闪存并且充分利用FTLs中写时拷贝策略，X-FTL在没有使用昂贵的日志机制的情况下极大的提高了事物的吞吐量。我们已经实现了X-FTL应用在固态硬盘开发板中，我们称这种开发板为openSSD，我们稍稍修改了SQLite和ext4文件系统，以此 让它们能与X-FTL所带来的扩展性质相匹配。我们也证明了X-FTL在智慧手机应用的SQLite中，TPC-C基准的OLTP数据库中，以及FIO基准的文件系统中运用的有效性。 BEA Confidential. | * SQLite的日志模式 BEA Confidential. | * 问题称述 如果SQLite运行在回滚运行模式,当一个事务开始时创建日志文件，事务结束时日志文件将被删除。这显著地增加了更新元数据时的I/O活动。如果SQLite在预写日志模式下运行,在许多交易中日志文件是重用和共享的,直到日志被一个检查点操作才被删除。因此,更新元数据的开销是SQLite在预写日志模式下运行时低得多。I/O行为流程的另一个方面是如何文件被同步的频率有多少。SQLite调用fsync系统调用在回滚运行模式比预写日志模式要多一些。由于日志文件的标题页需要与数据页分开来同步,每个正在提交的事务，SQLite至少需要调用一个fsync命令。 SQLite严重依赖使用回滚日志文件和预写日志模式就像事务的原子性与持久性依赖频繁的文件同步操作一样。该策略的I / O效率低下是的拥有SQLite的应用程序有迟缓响应的主要原因。 BEA Confidential. | * X-FTL在存储设备层提供了一个扩展的抽象部分,保证事务的原子性和持久性的改变几乎没有成本开销。SQLite和日志文件系统可以构建X-FTL来最小化事务支持和元数据日志记录的开销。 通过像文中提到的X-FTL的特点优化其FTL代码，使其在openSSD开发硬件平台上实现了X-FTL。我们证明了SQLite和ext4文件系统可以利用X-FTL仅仅只需要小小的修改下他们代码的情况下。 为什么需要X-FTL X-FTL运行时,日志文件系统可能关闭日志,但是仍然可以实现相同级别的一致性就像使用完整的日志记录机制所提供的效果一样。这表明一个轻量级的事务性文件系统可以开发不采取额外的负担用于复制数据和元数据以及执行同步的写操作命令。 BEA Confidential. | * X-FTL架构 BEA Confidential. | * SQLite上做的改变 如果X-FTL在SQLite?上运行,它都不会在这这两种模式下运行。相反,它可以简单地关掉它们,因为在存储器这个层面，X-FTL支持事务的原子性和持久性。在关闭模式下运行时,SQLite变化直接对数据库页面和数据库的元数据文件进行更新。就像先前说的那样,即使不在这些模式里,数据库缓冲区的管理将会采用强制占取的管理政策。 所有页面更新通过正在提交的事务传递给数据库，这时使用fsync底层文件系统的系统调用来执行强制写来实现强制的策略。事务一旦中途中断,因为SQLite运行在关闭模式，滚回策略将不会执行。因此,一个中断的事务可能留下一个数据库处于不一致的状态。这是因为占取政策允许没有提交的事务复制到数据库，然后SQLite也没有撤销未提交的变化，当其处于关闭的模式的时候。 不幸的是,没有对应的fsync系统调用可以撤消更改已经写入了文件。解决这个问题的唯一途径是通过X-FTL放弃事务的信息,以便在存储介质中可以回滚未提交的更改。这是通过修改SQLite,这样它调用一个新的系统调用一个abort的事务,这是SQLite唯一的变化。新系统调用通过添加一个新文件系统的ioctl系统调用中请求类型“中止”命令来实现。 BEA Confidential. | * 文件系统上做的改变 一个文件系统其实扮演着信使的角