什么是寬列存儲？

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 數據庫的一種。

也許這是四個寬列數據庫的更好圖像。

我的理解是頂部的第一張圖片，model 列，就是我們所說的實體/屬性/值表。 它是特定實體（列）中的屬性/值表。

對於客戶信息，第一個廣域數據庫示例可能如下所示。

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

營銷人員可以想象的任何屬性都可以被捕獲並存儲在屬性/值表中。 不同的客戶可以有不同的屬性。

超級列 model 以不同的格式保存相同的信息。

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

您可以擁有與實體一樣多的超級柱模型。 它們可以位於單獨的 NoSQL 表中，也可以放在一起作為超級列系列。

Column Family 和 Super Column family 只是為圖片中的前兩個模型提供了一個 row 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..."  |
|----+---------+------------+---------|