内存数据库解析与主流产品对比（一）.doc

? ? ? ? ? ? ? ? 内存数据库解析与主流产品对比（一） ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? — 基于磁盘的数据库管理系统— 传统的数据库管理系统（DBMS）通常是采用基于磁盘的设计，原因在于早期数据库管理系统设计时受到了硬件资源如单CPU、单核、可用内存小等条件的限制，把整个数据库放到内存里是不现实的，只能放在磁盘上。由于磁盘是一个非常慢的存储设备（相对于CPU的速度），因此学术界和工业界发展出的数据库管理系统在架构上都必须适应当时的硬件条件，沿用至今的Oracle和MySQL等数据库管理系统仍然采用的是这种架构设计。 伴随着技术的发展，内存已经越来越便宜，容量也越来越大。单台计算机的内存可以配置到几百GB甚至TB级别。对于一个数据库应用来说，这样的内存配置已经足够将所有的业务数据加载到内存中进行使用。虽然大数据处理的数据量可能是PB级别的，但那些数据一般是非结构化的数据。通常来讲，结构化数据的规模并不会特别大，例如一个银行10年到20年的交易数据加在一起可能只有几十TB。这样规模的结构化数据如果放在基于磁盘的DBMS中，在面对大规模SQL查询和交易处理时，受限于磁盘的I/O性能，很多时候数据库系统会成为整个应用系统的性能瓶颈。 如果我们为数据库服务器配置足够大的内存，是否可以仍然采用原来的架构，通过把所有的结构化数据加载到内存缓冲区中，就可以解决数据库系统的性能问题呢？这种方式虽然能够在一定程度上提高数据库系统的性能，但在日志机制和更新数据落盘等方面仍然受限于磁盘的读写速度，远没有发挥出大内存系统的优势。内存数据库管理系统和传统基于磁盘的数据库管理系统在架构设计和内存使用方式上还是有着明显的区别。 —缓冲区管理方式— 在传统的数据库管理系统中，数据的主存储介质是磁盘。例如，逻辑上的一张表通常会被映射到磁盘上的一个文件，文件是以数据块（Data Block，也称作Page）的形式存储在磁盘上。对于结构化数据来说，一条记录会被保存在磁盘上的某个数据块中，可以用数据块ID和Offset/偏移量来表示该条记录的具体位置。这种形式的数据块也被称作 Slotted Page，顾名思义是把数据块划分成很多槽位，然后一个Record放在某一个槽位上。在对某条记录进行处理时，可以通过代表该记录地址的Page ID + Offset从磁盘上获取该记录；随后系统会把存储有该条记录的数据块从磁盘读到缓冲区（Buffer Pool分为多个Frame，每个Frame可以保存一个磁盘块），再从缓冲区将该条记录读到线程或事务的工作区进行处理；处理结束后将更新的记录写回缓冲区中的数据块，再由数据库管理系统将修改过的数据块写回到磁盘上。 ?? ? ? ? ? ? ? ? ??基于磁盘的数据库管理系统中的数据访问示例 在基于磁盘的数据库管理系统中，处理查询时通常会把整个索引加载到内存，而B+树索引中一个索引节点的大小通常是一个数据块。每个被索引的key值在索引叶子节点中都有对应的索引项，索引项中包含该key值所对应记录的存储位置（Page ID + Offset）；当一个数据块被加载到内存中的缓冲区时，DBMS通过Page Table结构来维护Page ID + Offset的地址与内存缓冲区地址的转换。在访问数据时，先在Page Table中查找是否存在对应的Page ID + Offset，如果没有则说明这条记录仍然在磁盘上，需要先把磁盘上数据块的读进缓冲区，然后再在Page Table中维护好地址映射关系。具体的实现过程是，DBMS首先会在缓冲区中寻找可用的Frame，如果没有就根据缓冲区替换算法选取脏页（Dirty Page）替换出去；假如选中了某个脏页进行替换，则需要对该位置加Latch锁来保证在替换过程中该位置不会被其他事务访问（Latch后面会介绍）。在脏页写回磁盘后，系统就可以把目标数据块读入到缓冲区中的该位置，再将其在缓冲区中的地址写到Page Table，维护好地址映射关系；在这些操作完成后再将Frame上的Latch锁释放。 传统DBMS中的内存地址映射 对于传统基于磁盘的DBMS而言，即使内存缓 冲区足够大，可以将所有数据加载到内存中，但访问数据过程中的地址映射和转换依然存在，只是省掉了将数据块从磁盘加载到内存的开销。即使数据已经全部被加载到内存，基于磁盘的DBMS性能上与内存数据库相比还是有很大差距，这是其中一个重要的原因。 总结来看，基于磁盘的DBMS和内存数据库在实现技术上一个重要区别是：在访问数据时，基于磁盘的DBMS需要通过地址映射将数据在磁盘上的地址转换成在内存中地址，而内存数据库在设计上则是直接使用数据在内存中的地址 。 —事务ACID属性保证— 在数据