你必须知道一些其他存储——列式存储

从数据存储讲起
我们最先接触的数据库系统，大部分都是行存储系统。大学的时候学数据库，老师让我们将数据库想象成一张表格，每条数据记录就是一行数据，每行数据包含若干列。所以我们对大部分数据存储的思维也就是一个复杂一点的表格管理系统。我们在一行一行地写入数据，然后按查询条件查询过滤出我们想要的行记录。

大部分传统的关系型数据库，都是面向行来组织数据的。如 Mysql，Postgresql。近几年，也越来越多传统数据库加入了列存储的能力。虽然列存储的技术在十几年前就已经出现，却从来没有像现在这样成为一种流行的存储组织方式。

行存储和列存储，是数据库底层组织数据的方式。（和文档型、K-V 型，时序型等概念不在一个层次）

行存储
行存储系统以行的方式来组织数据。假设现在有以下 blog 数据(大学时老师布置系统课题作业总是让我们做一个博客系统，大概因为他们最先接触的互联网就是 BBS 吧)：

[
  {
    "title": "Oriented Column Store",
    "author": "Alex",
    "publish_time": 1508423456,
    "like_num": 1024
  },{
    "title": "Apache Druid",
    "author": "Bob",
    "publish_time": 1504423069,
    "like_num": 10
  },{
    "title": "Algorithm",
    "author": "Casey",
    "publish_time": 1512523069,
    "like_num": 16
  }
]

行存储将会以下列方式将数据存储在磁盘上。我们可以思考一下，这样的方式利于什么样的存储？（此处停顿 5 秒思考一下）它利于数据一行一行的写入，写入一条数据记录时，只需要将数据追加到已有数据记录后面即可。

行模式存储适合 OLTP(Online Transaction Processing)系统。因为数据基于行存储，所以数据的写入会更快。对按记录查询数据也更简单。

这种经常需要通过大量数据集来聚合统计数据的需求其实是 OLAP 系统的常见行为。基于这个需求我们也可以明白为什么这几年列式存储开始流行。因为数据，大数据，数据分析，也就是 OLAP(Online Analytical Processing)在线分析系统的需求增多了，数据写入的事务和按记录查询数据都不是它的关注点，它关注的是数据过滤。

同样是上面的示例数据，我们来看列式存储是怎样组织数据的。

[
  {
    "title": "Oriented Column Store",
    "author": "Alex",
    "publish_time": 1508423456,
    "like_num": 1024
  },{
    "title": "Apache Druid",
    "author": "Bob",
    "publish_time": 1504423069,
    "like_num": 10
  },{
    "title": "Algorithm",
    "author": "Casey",
    "publish_time": 1512523069,
    "like_num": 16
  }
]

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

自动索引

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

利于数据压缩

利于压缩有两个原因。一来你会发现大部分列数据基数其实是重复的，拿上面的数据来说，因为同一个 author 会发表多篇博客，所以 author 列出现的所有值的基数肯定是小于博客数量的，因此在 author 列的存储上其实是不需要存储博客数量这么大的数据量的；二来相同的列数据类型一致，这样利于数据结构填充的优化和压缩，而且对于数字列这种数据类型可以采取更多有利的算法去压缩存储。

最后
目前列存储模式在很多分析型数据库中都很常见。而且因为大数据分析型需求的增多，越来越多传统的行存储数据库也加入了列存储的模式，比如 Oracle 和 Sql Server 都有了列存储的特性。

之前讲的 Apache Druid 底层数据存储就是基于列模式。有兴趣的可以回顾一下。另外 HBase 是一个比较有代表性的列存储模式数据库。有时间可以来聊一聊 HBase 底层是如何存储数据的。也可以讲一讲数字列的压缩方式（大家也可以先思考一下可以如何压缩数字列）。

特朗普：英国想要200台呼吸机 我们会想想办法