Table of Contents

列式存储数据库

Examples of Column Store DBMSs

Hbase

Table

Row

Column

Column Family

Column Qualifier

Cell

Timestamp

Druid（德鲁依）

Cassandra

参考

列式存储数据库

列式数据库是以列相关存储架构进行数据存储的数据库，主要适合于批量数据处理和即时查询。相对应的是行式数据库，数据以行相关的存储体系架构进行空间分配，主要适合于大批量的数据处理，常用于联机事务型数据处理。

列存储数据库使用一个称为 keyspace 的概念。keyspace 有点像关系模型中的模式。keyspace 包含所有列族(有点像关系模型中的表)，其中包含行，包含列。

像这样，一个 keyspace 包含多个列族：

一个列族包含三行，每一行包含他们自己的列。

如上图所示：

• 列族由多行组成。
• 每一行可以包含与其他行不同数量的列。而且这些列不必与其他行的列匹配(例如，它们可以有不同的列名、数据类型、数量等)。
• 每行包含一列。它不像关系数据库那样跨所有行。每个列包含一个名称/值对，以及一个时间戳。

下面是每一行的结构：

• Row Key：每一行都有一个惟一的键，这是该行的惟一标识符。
• Column：每个列包含名称、值和时间戳。
• Name：KV 对的 K
• Value：KV 对的 V
• Timestamp：这提供了插入数据的日期和时间。这可以用来确定数据的最新版本。

一些 DBMSs 扩展了列族概念，以提供额外的功能/存储能力。例如，Cassandra 有复合列的概念，它允许您将对象嵌套在列中。

特点/优点

• 高效的压缩效率，节省磁盘空间和计算CPU和内存
• 基于 CPU L2 缓存高效的数据迭代
• 压缩算法：列式数据库由于其每一列都是分开储存的。所以很容易针对每一列的特征运用不同的压缩算法。常见的列式数据库压缩算法有Run Length Encoding ， Data Dictionary ， Delta Compression ， BitMap Index ， LZO ， Null Compression 等等。根据不同的特征进行的压缩效率从10W:1 到10:1 不等。而且数据越大其压缩效率的提升越为明显。
• 延迟物化：列式数据库由于其特殊的执行引擎，在数据中间过程运算的时候一般不需要解压数据而是以指针代替运算，直到最后需要输出完整的数据时。
• 聚合查询：由于它们的结构，柱状数据库在聚合查询(如SUM、COUNT、AVG等)方面表现得特别好。
• 可扩展性：列式存储数据库是可伸缩的。它们非常适合大规模并行处理(MPP)，这涉及到将数据分散到一个大的机器集群中——通常是数千台机器。
• 快速查询和写入：可以非常快地加载。可以在几秒钟内加载十亿行表。几乎可以立即开始查询和分析。

Examples of Column Store DBMSs

Hbase

在 HBase 中，数据存储在具有行和列的表中。这是一个与关系数据库(rdbms)重叠的术语，但这不是一个有用的类比。相反，将 HBase 表看作多维映射是合理的。

Table

HBase 表由多行组成。

Row

HBase 的行由一个 rowkey 和一个或多个 column 组成，其中的值与它们相关联。行在存储时按行键的字母顺序排序。因此，行键的设计非常重要。其目标是以相关行彼此相邻的方式存储数据。

一个常见的 rowkey 模式是一个网站域名。如果您的 rowkey 是域，您可能应该以相反的方式存储它们(org.apache.www, org.apache.mail, org.apache.jira)。通过这种方式，所有Apache域在表中彼此接近，而不是基于子域的第一个字母展开。

Column

HBase 中的列由一个列族和一个列限定符组成，它们由一个:(冒号)字符分隔。

Column Family

出于性能原因，列族在物理上共使用一组列及其值。每个列族都有一组存储属性，比如它的值是否应该缓存在内存中，它的数据是如何压缩的，或者它的 rowkey 是如何编码的，等等。表中的每一行都有相同的列族，尽管给定行可能不会在给定列族中存储任何内容。

Column Qualifier

列限定符被添加到列族中，以提供给定数据块的索引。给定一个列族内容，一个列限定符可能是content:html，另一个可能是content:pdf。虽然列族在表创建时是固定的，但是列限定符是可变的，而且行之间可能会有很大差异。即每一行列的数量是不一样的。

Cell

Cell 是行、列族和列限定符的组合，它包含一个值和一个时间戳，时间戳表示值的版本。

Timestamp

每个值旁边都有一个时间戳，它是给定版本的值的标识符。默认情况下，时间戳表示写入数据时在 RegionServer 上的时间，也可以在将数据放入计算单元时指定不同的时间戳值。

Druid（德鲁依）

德鲁依是一个高性能的实时分析数据库。用于大数据集的 OLAP 查询。Druid 通常用作支持实时摄取、快速查询性能和高正常运行时间的用例的数据库。因此，德鲁依通常被用于支持分析应用的 GUIs，或者作为需要快速聚合的高并发 APIs 的后端。德鲁依最擅长处理面向事件的数据。

Druid 的核心架构结合了数据仓库、时间序列数据库和日志搜索系统的思想。德鲁依的一些主要特点是：

1. 列式存储：Druid 使用面向列的存储，这意味着它只需要加载特定查询所需的精确列。这极大地提高了只访问几列的查询的速度。此外，每个列的存储都针对其特定的数据类型进行了优化，该数据类型支持快速扫描和聚合。
2. 可扩展分布式系统：德鲁依通常部署在数十到数百台服务器的集群中，可以提供每秒数百万条记录的吞吐率，上万亿条记录的保存率，以及亚秒到几秒的查询延迟。
3. 大规模并行处理：德鲁依可以在整个集群中并行处理一个查询。
4. 实时或批量摄取：德鲁依可以实时或者批量的获取数据。
5. 自愈，自平衡，操作方便：作为操作员，要减小或扩展集群，只需添加或删除服务器，集群就会在后台自动地重新平衡自己，而不会有任何停机时间。如果德鲁依的服务器失败了，系统会自动绕过失败的直到这些服务器可以被替换。德鲁依被设计成24/7运行，不需要任何原因的停机计划，包括配置变化和软件更新。
6. 云本地的、容错的架构，不会丢失数据：一旦德鲁依摄取了你的数据，副本就会安全的存储在后端存储器中(通常是云存储，HDFS，或者共享文件系统)。就算是德鲁依的服务器坏掉了，数据也会从后端存储中恢复。对于小部分服务器不可用的情况下，副本机制可以保证服务器恢复时，数据仍然可以被查询。
7. 快速过滤索引：Druid 使用 CONCISE 或 Roaring 的压缩位图索引来创建索引，支持跨多列的快速过滤和搜索。
8. 基于时间的分区：德鲁依首先按时间分区数据，并且可以根据其他字段进行分区。这意味着基于时间的查询将只访问与查询的时间范围匹配的分区。这将显著提高基于时间的数据的性能。
9. 近似算法：德鲁伊包括近似计数-区分，近似排序，近似直方图和分位数的计算算法。这些算法提供有限的内存使用，通常比精确计算快得多。对于精度比速度更重要的情况，德鲁依也提供精确的计数-清晰和精确的排名。
10. 自动生成摄取时间：德鲁依选择性地支持数据自动汇总在摄入的时候。这种汇总在一定程度上预先聚合了您的数据，可以节省大量成本并提高性能。

哪些情况使用德鲁依：

• 插入率非常高，但是更新不太常见。
• 大多数查询是聚合和报告查询(“group by”查询)。您还可以进行搜索和扫描查询。
• 您的查询延迟目标是100ms到几秒。
• 你的数据有一个时间组件(德鲁伊包括优化和设计选择具体相关的时间)。
• 可能有多个表，但是每个查询只访问一个大型分布式表。查询可能会碰到多个较小的“查找”表。
• 您有较高的基数数据列(例如 url、用户 id)，需要对它们进行快速计数和排序。
• 您希望从Kafka、HDFS、本地文件或Amazon S3之类的对象存储加载数据。

Cassandra

当您需要可伸缩性和高可用性而又不影响性能时，Apache Cassandra 数据库是正确的选择。在普通硬件或云基础设施上的线性可伸缩性和经过验证的容错能力使其成为关键任务数据的完美平台。Cassandra 对跨多个数据中心复制的支持是同类产品中最好的，它为用户提供了更低的延迟，并让您安心地知道可以在区域中断中幸存下来。

参考

https://searchdatabase.techtarget.com.cn/7-20958/

http://hbase.apache.org/book.html#datamodel

https://database.guide/what-is-a-column-store-database/

https://druid.apache.org/docs/latest/design/index.html

http://cassandra.apache.org/

一、列式存储和行式存储

列式存储是指一列中的数据在存储介质中是连续存储的；

行式存储是指一行中的数据在存储介质中是连续存储的。

简单的说，你可以把列式数据库认为是每一列都是一个表，这个表只有一列，如果只在该列进行条件查询，速度就很快。

那这两种不同的存储方式对数据的CRUD有什么不同的影响呢？

看了一些文章，一般说的是下面两点：

1。行数据库适用于读取出少行，多列的情况；
   列数据库相反，适用于读取出少数列，多数行的情况。

2。列数据库可以节省空间，如果某一行的某一列没有数据，那在列存储时，就可以不存储该列的值。

二、列式存储和行式存储优比较理解

传统的行式数据库将一个个完整的数据行存储在数据页中。这种方式在大数据量查询的时候会出现以下问题：

1、在没有索引的情况下，会把一行全部查出来，查询会使用大量IO
2、虽然建立索引和物化视图可以可以快速定位列，但是也需要花费大量时间

但是如果处理查询时需要用到大部分的数据列，这种方式在磁盘IO上是比较高效的。
一般来说，OLTP（Online Transaction Processing，联机事务处理）应用适合采用这种方式。

一个OLAP类型的查询可能需要访问几百万甚至几十亿个数据行，且该查询往往只关心少数几个数据列。例如，查询今年销量最高的前20个商品，这个查询只关心三个数据列：时间（date）、商品（item）以及销售量（sales amount）。商品的其他数据列，例如商品URL、商品描述、商品所属店铺，等等，对这个查询都是没有意义的。

列式数据库是将同一个数据列的各个值存放在一起。插入某个数据行时，该行的各个数据列的值也会存放到不同的地方。例如上例中列式数据库只需要读取存储着“时间、商品、销量”的数据列，而行式数据库需要读取所有的数据列。因此，列式数据库大大地提高了OLAP大数据量查询的效率。当然，列式数据库不是万能的，每次读取某个数据行时，需要分别从不同的地方读取各个数据列的值，然后合并在一起形成数据行。因此，如果每次查询涉及的数据量较小或者大部分查询都需要整行的数据，列式数据库并不适用。

很多列式数据库还支持列组（column group，Bigtable系统中称为locality group），即将多个经常一起访问的数据列的各个值存放在一起。如果读取的数据列属于相同的列组，列式数据库可以从相同的地方一次性读取多个数据列的值，避免了多个数据列的合并。列组是一种行列混合存储模式，这种模式能够同时满足OLTP和OLAP的查询需求。

由于同一个数据列的数据重复度很高，因此，列式数据库压缩时有很大的优势。例如，Google Bigtable列式数据库对网页库压缩可以达到15倍以上的压缩率。另外，可以针对列式存储做专门的索引优化。比如，性别列只有两个值，“男”和“女”，可以对这一列建立位图索引：

如上图所示，“男”对应的位图为100101，表示第1、4、6行值为“男”；“女”对应的位图为011010，表示第2、3、5行值为“女”。如果需要查找男性或者女性的个数，只需要统计相应的位图中1出现的次数即可。另外，建立位图索引后0和1的重复度高，可以采用专门的编码方式对其进行压缩。

三、列式存储优势

基于列模式的存储，天然就会具备以下几个优点：

1. 自动索引

因为基于列存储，所以每一列本身就相当于索引。所以在做一些需要索引的操作时，就不需要额外的数据结构来为此列创建合适的索引。

2. 利于数据压缩

利于压缩有两个原因。

一来你会发现大部分列数据基数其实是重复的，例如，因为同一个 author 会发表多篇博客，所以 author 列出现的所有值的基数肯定是小于博客数量的，因此在 author 列的存储上其实是不需要存储博客数量这么大的数据量的；

二来相同的列数据类型一致，这样利于数据结构填充的优化和压缩，而且对于数字列这种数据类型可以采取更多有利的算法去压缩存储。

四、小结

列式存储： 每一列单独存放，数据即是索引。
          只访问涉及得列，如果我们想访问单独一列（比如NAME）会相当迅捷。
          一行数据包含一个列或者多个列，每个列一单独一个cell来存储数据。

行式存储： 把一行数据作为一个整体来存储。

什么时候应该使用行式存储？什么时候应该使用列式存储呢？

简单来讲：

如果你大部分时间都是关注整张表的内容，而不是单独某几列，并且所关注的内容是不需要通过任何聚集运算的，那么推荐使用行式存储。

列式存储的话，比如你比较关注的都是某几列的内容，或者有频繁聚集需要的，通过聚集之后进行数据分析的表。

列式存储应用场景

基于一列或比较少的列计算的时候
经常关注一张表某几列而非整表数据的时候
数据表拥有非常多的列的时候
数据表有非常多行数据并且需要聚集运算的时候
数据表列里有非常多的重复数据，有利于高度压缩

行式存储应用场景

关注整张表内容，或者需要经常更新数据
需要经常读取整行数据
不需要聚集运算，或者快速查询需求
数据表本身数据行并不多
数据表的列本身有太多唯一性的数据

Ending！
更多课程知识学习记录随后再来吧！

就酱，嘎啦！

注：
1、人生在勤，不索何获。
2、什么是列存储，一文秒懂参见文章;
https://zhuanlan.zhihu.com/p/127823207