什么是宽列存储？

Question

谷歌搜索定义要么返回面向列的数据库的结果，要么给出非常模糊的定义。

我的理解是宽列存储由列族组成，列族由行和列组成。所述系列中的每一行都一起存储在磁盘上。这听起来像是面向行的数据库存储数据的方式。这让我想到了我的第一个问题：

宽列存储与常规关系数据库表有何不同？这是我的看法：

* column family        -> table
* column family column -> table column
* column family row    -> table row

这张来自Database Internals 的图片看起来就像两个普通表：

我对有什么不同的猜测来自这样一个事实，即沿边宽的列商店提到了“多维地图”。所以这是我的第二个问题：

宽列存储是否从左到右排序？意思是，在上面的例子中，行是先按Row Key，然后按Timestamp，最后按Qualifier？

Answer 1

让我们从宽列数据库的定义开始。

它的架构使用 (a) 持久、稀疏矩阵、多维映射（行值、列值和时间戳），以表格格式表示，旨在实现大规模的可扩展性（超过 PB 级）。

关系数据库旨在维护实体与描述实体的列之间的关系。一个很好的例子是客户表。这些列包含描述客户姓名、地址和联系信息的值。所有这些信息对于每个客户都是相同的。

宽列数据库是一种 NoSQL 数据库。

也许这是四个宽列数据库的更好形象。

我的理解是顶部的第一个图像，列模型，就是我们所说的实体/属性/值表。它是特定实体（列）中的属性/值表。

对于客户信息，第一个广域数据库示例可能如下所示。

Customer ID    Attribute    Value
-----------    ---------    ---------------
     100001    name         John Smith
     100001    address 1    10 Victory Lane
     100001    address 3    Pittsburgh, PA  15120

是的，我们可以为关系数据库建模。属性/值表的强大之处在于更不寻常的属性。

Customer ID    Attribute    Value
-----------    ---------    ---------------
     100001    fav color    blue
     100001    fav shirt    golf shirt

营销人员可以想象的任何属性都可以被捕获并存储在属性/值表中。不同的客户可以有不同的属性。

Super Column 模型以不同的格式保存相同的信息。

Customer ID: 100001
Attribute    Value
---------    --------------
fav color    blue
fav shirt    golf shirt

您可以拥有与实体一样多的超级列模型。它们可以位于单独的 NoSQL 表中，也可以放在一起作为超级列族。

列族和超级列族只是简单地为图片中的前两个模型提供一个行 id，以便更快地检索信息。

Answer 2

大多数（如果不是全部）宽列存储确实是面向行的存储，因为记录的每个部分都存储在一起。您可以将其视为二维键值存储。密钥的第一部分用于跨服务器分发数据，密钥的第二部分可以让您快速找到目标服务器上的数据。

宽列商店将具有不同的特征和行为。但是，例如，Apache Cassandra 允许您定义数据的排序方式。以这张表为例：

| id | country | timestamp  | message |
|----+---------+------------+---------|
| 1  | US      | 2020-10-01 | "a..."  |
| 1  | JP      | 2020-11-01 | "b..."  |
| 1  | US      | 2020-09-01 | "c..."  |
| 2  | CA      | 2020-10-01 | "d..."  |
| 2  | CA      | 2019-10-01 | "e..."  |
| 2  | CA      | 2020-11-01 | "f..."  |
| 3  | GB      | 2020-09-01 | "g..."  |
| 3  | GB      | 2020-09-02 | "h..."  |
|----+---------+------------+---------|

如果您的分区键是(id)并且您的集群键是(country, timestamp)，则数据将像这样存储：

[Key 1]
1:JP,2020-11-01,"b..." | 1:US,2020-09-01,"c..." | 1:US,2020-10-01,"a..."
[Key2]
2:CA,2019-10-01,"e..." | 2:CA,2020-10-01,"d..." | 2:CA,2020-11-01,"f..."
[Key3]
3:GB,2020-09-01,"g..." | 3:GB,2020-09-02,"h..."

或以表格形式：

| id | country | timestamp  | message |
|----+---------+------------+---------|
| 1  | JP      | 2020-11-01 | "b..."  |
| 1  | US      | 2020-09-01 | "c..."  |
| 1  | US      | 2020-10-01 | "a..."  |
| 2  | CA      | 2019-10-01 | "e..."  |
| 2  | CA      | 2020-10-01 | "d..."  |
| 2  | CA      | 2020-11-01 | "f..."  |
| 3  | GB      | 2020-09-01 | "g..."  |
| 3  | GB      | 2020-09-02 | "h..."  |
|----+---------+------------+---------|

如果将主键（分区键和聚类键的组合）更改为(id, timestamp) WITH CLUSTERING ORDER BY (timestamp DESC)（id 是分区键，timestamp 是按降序排列的聚类键），结果将是：

[Key 1]
1:US,2020-09-01,"c..." | 1:US,2020-10-01,"a..." | 1:JP,2020-11-01,"b..." 
[Key2]
2:CA,2019-10-01,"e..." | 2:CA,2020-10-01,"d..." | 2:CA,2020-11-01,"f..."
[Key3]
3:GB,2020-09-01,"g..." | 3:GB,2020-09-02,"h..."

或以表格形式：

| id | country | timestamp  | message |
|----+---------+------------+---------|
| 1  | US      | 2020-09-01 | "c..."  |
| 1  | US      | 2020-10-01 | "a..."  |
| 1  | JP      | 2020-11-01 | "b..."  |
| 2  | CA      | 2019-10-01 | "e..."  |
| 2  | CA      | 2020-10-01 | "d..."  |
| 2  | CA      | 2020-11-01 | "f..."  |
| 3  | GB      | 2020-09-01 | "g..."  |
| 3  | GB      | 2020-09-02 | "h..."  |
|----+---------+------------+---------|