内存数据库解析与主流产品对比(二)

在上一篇文章《内存数据库解析与主流产品对比(一)》中 , 我们介绍了基于磁盘的数据库管理系统相关知识 , 并简述了内存数据库的技术发展 。 本篇文章将从数据组织和索引的角度来介绍内存数据库的特点 , 并介绍几款产品实际的技术实现 。
— 数据库管理系统中的数据组织—
定长Block VS 变长Block
内存数据库在内存中对数据进行管理时 , 虽然不再需要通过Slotted Page的形式对数据进行组织 , 但也不能在内存中任意为数据分配地址空间 , 依然需要把数据组织成块(Block/Page)的形式 。 传统基于磁盘的DBMS采用Slotted Page的形式组织数据是为了读写性能的考虑 , 因为磁盘接口是以Block/Page为读写单位 。 而内存数据库采用块的方式组织数据是为了便于寻址和管理 , 通常会将数据块分为定长数据块(Fixed-Length Data Block)和变长数据块(Variable-Length Data Block)两种 。
假设一个数据集已经全部被加载进内存 , 为了使用方便 , 内存数据库在进行数据组织时会把记录的定长的属性全部分出来 , 放到定长数据块;所有变长的属性保存在另外的变长数据块中 。 例如 , 通常将数据表中所有小于8个字节的属性都放在定长数据块中 , 将变长属性和超过8个字节的属性单独放在变长数据块中 , 并在定长数据块中放一个指向其地址的指针 。 采用定长数据块管理数据的好处是寻址快 , 可以通过记录长度和编号确定记录在数据块中存储的位置;记录地址指针所需要的空间少 , 使得索引结构或其他结构中存放这条记录的内存地址最为精简 , 并且CPU做Pre-Fetch时预测较准 。
在传统基于磁盘的DBMS中 , 索引叶子节点保存的记录地址是Page ID + Offset , Page Table负责将Page ID映射到Buffer的Frame;内存数据库中 , 索引的叶子节点保存的记录地址则是直接的内存地址 。 在传统基于磁盘的DBMS中 , 访问Buffer中的Page时需要对Page进行加锁/解锁/修改锁的操作 , 由于现实系统中锁(Latch)的类型可能会很多 , 一个线程如果要访问一个Page , 往往要加好几种类型的Latch 。 现在内存数据库中没有了Buffer , 因此就省去了Latch的开销 , 性能上有很大提升 。
数据组织:数据分区、多版本、行/列存储
在多核或多CPU共享内存的系统中 , 对数据的并发访问冲突是始终存在的 。 目前的内存数据库系统可以分为Partition System和Non-Partition System两种 。 Partition System是把所有的数据切分成互不相交的多个Partition , 每一个Partition被分配给一个核(或分布式系统中的一个节点) , 所有操作都是串行执行 , 没有并发的数据访问 , 理想情况下可以获得最好的性能 。 但这类系统的缺点也很明显 , 例如如何划分Partition以及跨Partition的事务怎么处理等 。 对于Non-Partition System , 所有的核以及所有的线程都可以访问所有的数据 , 因此一定会存在并发访问冲突 , 必须采用支持并发访问的数据结构 。 目前 , 通用数据库更多的是采用Non-Partition System设计 , 之所以不采用Partition设计的主要原因是:通用场景下很难对数据进行有效分区 , Partition数据库无法使用 。
在Non-Partition System中 , 如果两个线程访问同一个数据项会发生冲突 , 这时可以考虑Multi-Version的解决方案 。 Multi-Version的优势在于可以提高并发程度 , 其基本的思想是通过多版本的数据让所有的读操作不阻塞写操作 , 从而提高整个系统的性能 。 对于那些读多写少的系统 , Multi-Version性能会很好 , 但对于一些Write Heavy的系统 , 性能并不理想 。
数据组织还有一个需要考虑的是Row和Column的组织形式 。 传统数据库系统在磁盘上维护数据时 , 分为行式存储和列式存储 。 顾名思义 , 行式存储是按行存储数据 , 列式存储是按列存储数据 。 如果对少量记录的所有属性进行操作 , 行式存储更加合适 , 如果只读大量记录的部分列数据 , 则列式存储性能比较好 。 比如一条记录有100个属性 , 本次读操作需要读取所有记录的其中一个属性 , 如果按行存储 , Block读进来后还需要再筛选列;如果按列存储 , 可以只读取这列数据所对应的Block , 所以性能会比较好 , 适合去做统计分析 。 但内存数据库不会有这个问题 , 所有数据都放在内存 , 无论行存还是列存 , 访问的代价是差不多的 。 所以在内存数据库中 , 行存/列存是可以做交换或任意选择的 。 当然对于TP应用而言 , 更多的还是用行存 , 因为可以一次性把所有属性都读出来 。 但即使是列存 , 性能也并没有在基于磁盘的数据库系统中那么糟糕 。 比如SAP HANA就是一个行列混合的存储 , 前端的事务引擎是行存储 , 通过合并整合以后 , 后端转为了列存储 。