52

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

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

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

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

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

两个列族、内容和锚点

我对不同之处的猜测来自这样一个事实，即“多维地图”在侧面宽列存储中被提及。所以这是我的第二个问题：

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

4

2 回答 2

53

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

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

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

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

也许这是四个宽列数据库的更好图像。

宽列数据库

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

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

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 表中，也可以放在一起作为超级列族。

Column Family 和 Super Column family 只是为图片中的前两个模型提供了一个 row id，以便更快地检索信息。

于 2020-05-26T16:57:25.793 回答
8

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

宽列商店将具有不同的特征和行为。但是，例如，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..."  |
|----+---------+------------+---------|
于 2020-11-25T15:46:18.593 回答