柱状数据库如何进行索引？

Question

据我所知，柱状数据库将列数据放在磁盘而不是行上。我也理解在传统的行式RDBMS中，B-Tree的叶索引节点包含指向实际行的指针。

但是由于columnar没有将行存储在一起，并且它们特别适用于柱状操作，它们在索引技术方面有何不同？

1. 他们还使用B-tress吗？
2. 他们如何在他们使用的数据结构内部进行索引？
3. 或者没有可接受的格式，每个供应商都有自己的索引方案来满足他们的需求？

我一直在搜索，但无法找到任何文字。我找到的每个文本都是用于行式DBMS。

Answer 1

如果您了解 1）列式DB如何实际存储数据，以及 2）索引的工作方式（它们如何存储数据） 那么您可能会觉得不需要在列式Db中建立索引。

对于任何种类的数据库，rowid都非常重要，就像存储数据的地址一样。 索引不过是将行ID映射到按排序顺序索引的列而已。 列式数据库就是基于这种逻辑而诞生的。他们尝试以这种方式本身存储数据，这意味着-他们以序列化的方式将数据存储为键值对，其中，实际列值为Key，当数据驻留为其值时，如果发现任何行值，则为rowid重复的密钥，它们只是压缩和存储。

因此，如果您比较列式数据库在磁盘上实际存储数据的格式，则几乎是相同的（但不完全是因为，因为压缩的区别在于键值的表示方式相反，相反）面向数据库存储索引。

这就是您不再需要单独索引的原因。并且找不到任何尝试实现索引的列式数据库。

Answer 2

没有BTrees。 （或者，如果它们是，它们不是设计的主要部分。）

Infinidb每块存储64K行。该块中的每个列都被压缩并编入索引。对于每个列，chunk是一个列表，例如min，max，avg等，这些列可能对查询有帮助，也可能没有帮助。

首先运行SELECT查看每个块的摘要信息，以查看块中任何行是否满足WHERE子句 。

通过该过滤的块会更详细地查看。

没有行的副本。相反，如果您要求SELECT a,b,c ... , then the compressed info for 64K rows (in one chunk) for each of a, b, c need to be decompressed to further filter and deliver the row. So, it behooves you to list only the desired columns, not blindly say SELECT *`。

由于每列都是单独索引的，因此无需说INDEX(a)。 （我不知道是否可以为列式数据库指定INDEX(a,b)。）

警告：我正在描述Infinidb，它可以与MariaDB一起使用。我不知道任何其他柱状引擎。

Answer 3

列索引（也称为“垂直数据存储”）以散列和压缩模式存储数据。索引键中调用的所有列均被单独索引。散列会减少存储的数据量。压缩方法对于重复出现（字典式，最终是部分式）仅使用一个值。

该技术有两个主要困难：

• 首先，您可能会发生冲突，因为哈希结果可能相同 两个不同的值。因此索引必须管理冲突。
第二，使用的哈希和压缩算法是 CPU之类的资源。

这些类型的索引存储为向量。

通常，这些类型的索引仅用于只读表，尤其是用于商业智能（OLAP数据库）。

列索引只能以“可搜索”方式用于相等谓词（COLUMN_A = OneValue）。但这对于GROUPING或DISTINCT操作也是足够的。列索引不支持范围查找，包括LIKE'foo％'。

一些数据库供应商通过添加一些减少CPU的中间算法来解决插入或更新时所需的巨大资源。对于将增量存储用于新修改的行的Microsoft SQL Server就是这种情况。通过这种技术，可以像任何传统的OLTP数据库一样以关系方式使用该表。

例如，Microsoft SQL Server首先在2012年版本中引入了列存储索引，但这使该表成为只读的。在2014年，发布了群集的列存储索引（表的所有列都已建立索引），并且该表是可写的。最后，在2016版中，列存储索引是否已聚簇，不再要求表的任何部分都是只读的。 之所以能够做到这一点，是因为Microsoft Research开发了一种名为“批处理模式”的特殊搜索算法，并且该算法不能通过逐行读取数据来工作...

阅读：

Enhancements to SQL Server Column Stores

Columnstore and B+ tree –Are Hybrid Physical Designs Important?