目錄
- 建表語法
- 使用場景
- 合并演算法
- 使用例子、
- 資料分享
- 參考文章
VersionedCollapsingMergeTree引擎繼承自MergeTree并將折疊行的邏輯添加到合并資料部分的演算法中，VersionedCollapsingMergeTree用于相同的目的折疊樹但使用不同的折疊演算法，允許以多個執行緒的任何順序插入資料，特別是，Version列有助于正確折疊行，即使它們以錯誤的順序插入，相比之下,CollapsingMergeTree只允許嚴格連續插入，
VersionedCollapsingMergeTree引擎的作用如下：
- 允許快速寫入不斷變化的物件狀態，
- 洗掉后臺中的舊物件狀態， 這顯著降低了存盤體積，
建表語法
CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
(
name1 [type1] [DEFAULT|MATERIALIZED|ALIAS expr1],
name2 [type2] [DEFAULT|MATERIALIZED|ALIAS expr2],
...
) ENGINE = VersionedCollapsingMergeTree(sign, version)
[PARTITION BY expr]
[ORDER BY expr]
[SAMPLE BY expr]
[SETTINGS name=value, ...]
針對于VersionedCollapsingMergeTree(sign, version)兩個特殊的引數，
sign — 指定行型別的列名:1是一個“state”行,-1是一個“cancel”行列資料型別應為Int8.
version — 指定物件狀態版本的列名，列資料型別應為UInt*.
使用場景
考慮一種情況，您需要為某個物件保存不斷變化的資料，對于一個物件有一行，并在發生更改時更新該行是合理的，但是，對于資料庫管理系統來說，更新操作非常昂貴且速度很慢，因為它需要重寫存盤中的資料，如果需要快速寫入資料，則不能接受更新，但可以按如下順序將更改寫入物件，使用 Sign 列寫入行時，如果Sign=1這意味著該行是一個物件的狀態（讓我們把它稱為“state”行），如果Sign=-1它指示具有相同屬性的物件的狀態的取消（讓我們稱之為“cancel”行）， 還可以使用 Version 列，它應該用單獨的數字標識物件的每個狀態，
例如，我們要計算用戶在某個網站上訪問了多少頁面以及他們在那里的時間，在某個時間點，我們用用戶活動的狀態寫下面的行:
┌──────────────UserID─┬─PageViews─┬─Duration─┬─Sign─┐
│ 4324182021466249494 │ 5 │ 146 │ 1 │
└─────────────────────┴───────────┴──────────┴──────┘
在稍后的某個時候，我們注冊用戶活動的變化，并用以下兩行寫入它，
┌──────────────UserID─┬─PageViews─┬─Duration─┬─Sign─┐
│ 4324182021466249494 │ 5 │ 146 │ -1 │
│ 4324182021466249494 │ 6 │ 185 │ 1 │
└─────────────────────┴───────────┴──────────┴──────┘
第一行取消物件（用戶）的先前狀態，它應該復制已取消狀態的所有欄位，除了Sign，
第二行包含當前狀態，
因為我們只需要用戶活動的最后一個狀態，所以需要洗掉，折疊物件的無效（舊）狀態，VersionedCollapsingMergeTree會在在合并資料部分時執行此操作，
最終折疊之后的結果如下，
┌──────────────UserID─┬─PageViews─┬─Duration─┬─Sign─┬─Version─┐
│ 4324182021466249494 │ 5 │ 146 │ 1 │ 1 |
│ 4324182021466249494 │ 5 │ 146 │ -1 │ 1 |
└─────────────────────┴───────────┴──────────┴──────┴─────────┘
對于使用VersionedCollapsingMergeTree有下面三個需要注意的點，
- 寫入資料的程式應該記住物件的狀態以取消它，該“cancel”字串應該是“state”與相反的字串Sign，這增加了存盤的初始大小，但允許快速寫入資料，
- 列中長時間增長的陣列由于寫入負載而降低了引擎的效率，資料越簡單，效率就越高，
- SELECT結果很大程度上取決于物件變化歷史的一致性，準備插入資料時要準確，不一致的資料將導致不可預測的結果，例如會話深度等非負指標的負值，
合并演算法
合并演算法主要是下面兩個，
- 當ClickHouse合并資料部分時，它會洗掉具有相同主鍵和版本但Sign值不同的一對行.行的順序并不重要，
- 當ClickHouse插入資料時，它會按主鍵對行進行排序，如果Version列不在主鍵中，ClickHouse將其隱式添加到主鍵作為最后一個欄位并使用它進行排序，
ClickHouse不保證具有相同主鍵的所有行都將位于相同的結果資料部分中，甚至位于相同的物理服務器上，對于寫入資料和隨后合并資料部分都是如此，此外，ClickHouse流程SELECT具有多個執行緒的查詢，并且無法預測結果中的行順序，這意味著，如果有必要從VersionedCollapsingMergeTree表中得到完全“collapsed”的資料，聚合是必需的，
也就是說ClickHouse并不保證查詢出來的資料一定是經過合并折疊的，如果要保證一定經過折疊合并，需要查詢的時候使用GROUP BY和聚合函式，
要計算數量，使用sum(Sign)而不是count()，要計算的東西的總和，使用sum(Sign * x)而不是sum(x)，并添加HAVING sum(Sign) > 0，可以在一定程度上避免資料未折疊導致的資料問題，
如果您需要手動折疊合并，但是，如果沒有聚合（例如，要檢查是否存在其最新值與某些條件匹配的行），則可以使用FINAL修飾FROM條件這種方法效率低下，不應與大型表一起使用，
使用例子、
示例資料:
┌──────────────UserID─┬─PageViews─┬─Duration─┬─Sign─┬─Version─┐
│ 4324182021466249494 │ 5 │ 146 │ 1 │ 1 |
│ 4324182021466249494 │ 5 │ 146 │ -1 │ 1 |
│ 4324182021466249494 │ 6 │ 185 │ 1 │ 2 |
└─────────────────────┴───────────┴──────────┴──────┴─────────┘
創建表:
CREATE TABLE UAct
(
UserID UInt64,
PageViews UInt8,
Duration UInt8,
Sign Int8,
Version UInt8
)
ENGINE = VersionedCollapsingMergeTree(Sign, Version)
ORDER BY UserID
插入資料:
INSERT INTO UAct VALUES (4324182021466249494, 5, 146, 1, 1)
INSERT INTO UAct VALUES (4324182021466249494, 5, 146, -1, 1),(4324182021466249494, 6, 185, 1, 2)
我們用兩個INSERT查詢以創建兩個不同的資料部分，
如果我們使用單個查詢插入資料，ClickHouse將創建一個資料部分，并且永遠不會執行任何合并，
獲取資料:
SELECT * FROM UAct
┌──────────────UserID─┬─PageViews─┬─Duration─┬─Sign─┬─Version─┐
│ 4324182021466249494 │ 5 │ 146 │ 1 │ 1 │
└─────────────────────┴───────────┴──────────┴──────┴─────────┘
┌──────────────UserID─┬─PageViews─┬─Duration─┬─Sign─┬─Version─┐
│ 4324182021466249494 │ 5 │ 146 │ -1 │ 1 │
│ 4324182021466249494 │ 6 │ 185 │ 1 │ 2 │
└─────────────────────┴───────────┴──────────┴──────┴─────────┘
我們在這里看到了什么，折疊的合并部分在哪里？我們使用兩個創建了兩個資料部分INSERT查詢，該SELECT查詢是在兩個執行緒中執行的，結果是行的隨機順序，由于資料部分尚未合并，因此未發生折疊合并， ClickHouse在我們無法預測的未知時間點合并資料部分，
這就是為什么我們需要聚合:
SELECT
UserID,
sum(PageViews * Sign) AS PageViews,
sum(Duration * Sign) AS Duration,
Version
FROM UAct
GROUP BY UserID, Version
HAVING sum(Sign) > 0
┌──────────────UserID─┬─PageViews─┬─Duration─┬─Version─┐
│ 4324182021466249494 │ 6 │ 185 │ 2 │
└─────────────────────┴───────────┴──────────┴─────────┘
如果我們不需要聚合，并希望強制折疊，我們可以使用 FINAL 修飾符 FROM 條款
SELECT * FROM UAct FINAL
┌──────────────UserID─┬─PageViews─┬─Duration─┬─Sign─┬─Version─┐
│ 4324182021466249494 │ 6 │ 185 │ 1 │ 2 │
└─────────────────────┴───────────┴──────────┴──────┴─────────┘
資料分享
ClickHouse經典中文檔案分享
參考文章
- ClickHouse(01)什么是ClickHouse,ClickHouse適用于什么場景
- ClickHouse(02)ClickHouse架構設計介紹概述與ClickHouse資料分片設計
- ClickHouse(03)ClickHouse怎么安裝和部署
- ClickHouse(04)如何搭建ClickHouse集群
- ClickHouse(05)ClickHouse資料型別詳解
- ClickHouse(06)ClickHouse建表陳述句DDL詳細決議
- ClickHouse(07)ClickHouse資料庫引擎決議
- ClickHouse(08)ClickHouse表引擎概況
- ClickHouse(09)ClickHouse合并樹MergeTree家族表引擎之MergeTree詳細決議
- ClickHouse(10)ClickHouse合并樹MergeTree家族表引擎之ReplacingMergeTree詳細決議
- ClickHouse(11)ClickHouse合并樹MergeTree家族表引擎之SummingMergeTree詳細決議
本文來自博客園，作者：張飛的豬，轉載請注明原文鏈接：https://www.cnblogs.com/the-pig-of-zf/p/17495702.html
公眾號：張飛的豬大資料分享，不定期分享大資料學習的總結和相關資料，歡迎關注，
個人網站"張飛的豬編程作業室"鏈接: https://zhangfeidezhu.com
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/555794.html
標籤：大數據
下一篇：返回列表