MariaDB ColumnStore调研

Posted 2023-03-21

参考技术A ColumnStore（2016.12.14 GA）实际是 mariaDB 版的 InfiniDB。InfiniDB 倒闭于2014年9月，开源版本继续放在 github 上开源。老版本InfiniDB 的 mysql 版本是5.1.39（数据来源网络）。ColumnStore目前使用 MariaDB 10.1。

Daniel Lee
Nishant Vyas

GPL

由构架图可见，主要有两个组件，User Module（UM），Performance Module（PM）

所有 ColumnStore 的数据的获取和管理都是通过 PM 节点进行。

在每个 Extent 和 Block 中，MC 存储列的值使用固定长度的数据类型在1到8 bytes 长。对于 string 类型超过这个长度的情况，一个额外的Dictionary extent 会创建来存储 string 的值。这种情况下，column extent 存储对应 string 在 Dictionary extent 的指针。

因为MC 使用固定长度的数据类型，对于同一行的其他列，可以直接定位。例如，如果我们有“NAME”列的 extent 里的行234的，query engine 可以快速定位行234的列“AMOUNT”。这对于快速形成一行的查询有极大帮助(因为通常来说，单条查询对于列存是比较弱的)。

默认，列和字典值都是压缩的。这个设定消耗 CPU 来换取 I/O 的减少，可以加快 query 的响应时间。MC 使用 Snappy library ( https://google.github.io/snappy/ ) 提供压缩特性。这种压缩算法在列的去重值较少时非常优秀，在一些场景下能提供10倍的压缩。

物理上，Segment 文件存储在 DBRoot 文件夹里。一个 DBRoot 包含一个物理存储单元，并且指定给一个物理 PM 服务器。系统会自动分布数据到可用的 DBRoots 上。

系统维护Extent 的元数据依靠 Extent Map。这个 Extent Map 包括 Extent 的最大值和最小值。这将帮助 MariaDB ColumnStore 提供一个简单但是有用的 horizontal partitioning scheme。在查询时，优化器可以消除不在 WHERE 条件里的 Extents。

例如：

如果一个查询的 WHERE 语句有“COL1 BETWEEN 220 and 250”，那优化器就可以消除 COL1的 Extent1，2和4。这就节省了75%的 IO以及很多比较操作。并且这个支持多个 column 的比较。原理相同就不细说了。

在时间序列，半排序的数据以及时间列中使用这个 MAP 非常有效。

额外的，系统在使用 Extent Map 的最大值和最小值可以进行 Bulk deletion 操作。（没有明说，但是猜测，一个 extent 如果没有全部清空，空间应该不释放，这一条不一定对。）

MariaDB Community Server 10.5 Alpha 上的 MariaDB Columnstore 1.4

【中文标题】MariaDB Community Server 10.5 Alpha 上的 MariaDB Columnstore 1.4

【英文标题】：MariaDB Columnstore 1.4 on MariaDB Community Server 10.5 Alpha

【发布时间】：2020-02-27 20:11:01

【问题描述】：

根据 MariaDB 的网站，在 Columnstore 部分 (https://mariadb.com/downloads/#mariadb_platform-mariadb_columnstore)：

MariaDB ColumnStore 1.4 现在是 MariaDB Enterprise Server 10.4 的一部分， 将成为下一个 MariaDB 社区服务器 10.5 alpha 的一部分 发布。

但是，MariaDB Community Server 10.5 alpha（最近发布）的 .tar 不包含任何包含文本“columnstore”的 .deb 文件（我希望看到类似于“MariaDB-columnstore-platform”的内容和“MariaDB-columnstore-engine”基于我能为 Columnstore 1.4 找到的唯一文档，该文档不是为社区版本而是为企业版编写的：https://mariadb.com/docs/deploy/col14/）。我在 MariaDB Community 10.5 alpha 中找不到任何与 Columnstore 1.4 相关的等效文档，尽管 MariaDB 的网站声明 Columnstore 1.4 是在该版本中发布的，并且在其他网站上发布的几篇文章也将其引用为包含在该版本中。

有人在 MariaDB Community 10.5 alpha 上使用过 Columnstore 1.4 吗？也许 Columnsotre 在 10.5 alpha 中的包含被简单地取消了，并且在整个网站上从未删除过对其包含的引用？如果有人让它工作，你能概述一下如何工作吗？

谢谢

【问题讨论】：

如果你已经安装了10.5，请执行SHOW VARIABLES LIKE 'has%';

@RickJames 没有结果。您认为可能会返回哪些变量？ MariaDB 文档中没有以“has”开头的变量 (mariadb.com/kb/en/server-system-variables)

糟糕，SHOW VARIABLES LIKE 'have%'; -- 正在寻找类似 @​​987654326@ 的内容。

没有have_columnstore 变量，或任何包含文本“columnstore”的变量

所以，听起来 ColumnStore 要么不可用，要么需要以某种方式添加。

【参考方案1】：

但是 10.5 还没有“发布”。发布周期是发布 10.x.0，这可能会充满问题。然后是 10.x.1，它清除了一些最严重的问题。等等。最终，10.x.y 作为“候选版本”发布。顽强的“早期采用者”应该尝试一下，但不要将其投入生产。最后，在 10.x.10 左右，他们将发布一个“GA”（通用）版本。这包含了 10.x 的所有功能，并处理了所有显示停止器错误。

请注意，10.5 的页面正在调用 10.5.1“测试版”；它还不是 RC 或 GA。 https://mariadb.com/kb/en/what-is-mariadb-105/

一个功能不进入“.0”版本的情况并不少见。但它很可能会在 RC 发布之前出现。我猜他们试图将 Columnstore 放入 .0，但发生了非常糟糕的事情，所以他们放弃了。

也许 MariaDB 中的某个人会发现此问答并为您提供更好的答案。

耐心。

【讨论】：

可以在 jira.mariadb.org 提交错误。