ColumnStore存储架构

当您在MariaDB ColumnStore上创建表时，系统会为表中的每个列创建至少一个文件。例如，使用三个列创建的表将在SAN上或性能模块的本地磁盘上创建至少三个可分别寻址的逻辑对象。

ColumnStore将表模式写入/usr/local/mariadb/columnstore/mysql/db中，其中包括所有非ColumnStore表。您写入ColumnStore表的数据存储在DB Roots中的性能模块上，这些模块位于/usr/local/mariadb/columnstore/datax中。

Extent

表中的每个列都独立地存储在一个称为Extent的逻辑度量中，每个Extent包含8,388,608行。1字节数据类型的Extent占用8MB；2字节数据类型需要16MB；4字节数据类型需要32MB；8字节数据类型需要64MB；而变量大小数据类型需要64MB。一旦Extent变满，ColumnStore就会创建一个新的Extent。大于8个字符的字符串列在主列文件中存储索引，并在单独的字典文件中存储实际值。

Extent在物理上存储为一组块。每个块为8KB。每个数据库块都由其逻辑块标识符（LBID）唯一标识。

ColumnStore写入磁盘的物理文件称为段文件。一旦段文件达到最大数量的Extents，ColumnStore会自动创建一个新的段文件。您可以使用ColumnStore.xml文件中的ExtentsPreSegmentFile设置段文件中的最大Extent数量。它应该设置为DB Roots数量的倍数。默认值为2。

所有列的段文件的一个或多个Extents集合为分区。这是ColumnStore中的水平分区。分区按段（即文件夹）组织成分层结构。ColumnStore元数据存储将文件结构和位置映射到DB模式，以及在ColumnStore.xml文件中的FilesPerColumnPartition。默认值为4。此外，默认情况下，ColumnStore压缩数据。

Extent Maps

ColumnStore使用称为Extent Map的智能结构来提供逻辑范围以进行分区，并消除索引、手动表分区、物化视图、汇总表和其他行数据库必须实现的查询性能结构和对象。

Extent是存在于物理段文件中的逻辑空间块，大小在8到64MB之间。每个Extent支持相同数量的行，较小的数据类型使用较少的磁盘空间。Extent Map将Extent目录到其相应的块（LBID），以及Extent中列数据的最小值和最大值。

主性能模块具有Extent Map的主副本。系统启动时，该文件被读入内存，然后物理复制到所有其他参与用户和性能模块以进行灾难恢复和故障转移。节点将Extent Map保留在内存中以进行快速访问。随着Extent的修改，更新会广播到参与节点。

Extent Elimination

使用Extent Map，ColumnStore可以执行逻辑范围分区，并仅检索满足查询给定连接和过滤条件的块。这是通过Extent Elimination完成的，即消除不符合查询结果的Extent的过程，从而减少总体I/O操作。

在Extent Elimination中，ColumnStore会扫描连接和过滤条件中的列。然后提取每个Extent的逻辑水平分区信息以及列的最小值和最大值，以进一步消除Extent。在涉及到过滤器的列扫描时，如果过滤器值超出Extent中该列的最小值和最大值范围，则ColumnStore会消除该Extent。

这种行为是自动的，并且非常适合于系列、有序、模式化和基于时间的数据，其中数据经常加载并经常按时间引用。任何具有聚集值的列都是Extent Elimination的良好候选。

带实时解压缩的压缩

在列存储中，相似的数据存储在每个列文件中，这允许优秀的压缩率。虽然实际的空间节省取决于数据的随机性和存在的不同值的数量，但许多数据集显示出节省65%至95%的空间的压缩率。

ColumnStore优化其压缩策略以提高从磁盘读取的性能。它被调整为加速解压缩速率，从而在从磁盘读取时最大化性能优势。这使得I/O受限的系统可以提高磁盘读取性能。

默认情况下，在ColumnStore中启用了压缩。此外，您可以在表级别或列级别启用或禁用它，或通过设置infinidb_compression_type系统变量在会话级别控制它。启用时，ColumnStore使用snappy压缩。

版本缓冲区

MariaDB ColumnStore使用版本缓冲区来存储正在修改的磁盘块、管理事务回滚并服务于数据库的MVCC（多版本并发控制）或“快照读”功能。这使它能够提供查询一致的数据库视图。

ColumnStore中的所有语句都在数据库的特定版本（或快照）上运行，系统将其称为系统更改号（SCN）。

版本缓冲区的工作原理

版本缓冲区使用内存哈希表来提供对正在进行的事务信息的内存访问。它从4MB开始，内存区域从该数量增长以处理由事务修改的块。哈希表中的每个条目都是对正在修改的8KB块的40字节引用。

版本缓冲区的限制因素不是更新的行数，而是磁盘块的数量。您可以增加大小，但要小心，因为增加磁盘块的数量意味着长时间运行的UPDATE和DELETE语句在需要回滚更改时可能需要更长时间。

事务日志

MariaDB ColumnStore支持将已提交的事务记录到服务器的二进制日志。