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

? ? ? ? ? ? ? ? 内存数据库解析与主流产品对比（二） ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? — 数据库管理系统中的数据组织— 定长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就是一个行列混合的存储，前端的事务引擎是行存储，通过合并整合以后，后端转为了列存储。 — 内存数据库系统对比— 接下来