🥇遷移到 ClickHouse：3 年後

三年前，Yandex 的 Viktor Tarnavsky 和 Alexey Milovidov 登上舞台 高負載++ 告訴，ClickHouse 有多好，以及它如何不慢下來。在下一階段有 亞歷山大·扎伊采夫 с 報告關於搬到 點擊之家 另一個分析 DBMS 的結論是 點擊之家當然好，但是不是很方便。 2016年公司什麼時候 LifeStreet亞歷山大當時工作的地方，正在將一個多 PB 的分析系統轉換為 點擊之家，這是一條充滿未知危險的迷人「黃磚路」—— 點擊之家 那時它看起來就像一個雷區。

三年後 點擊之家 變得好多了 - 在此期間，Alexander 創立了 Altinity 公司，該公司不僅幫助人們搬到 點擊之家 數十個項目，同時也與 Yandex 的同事一起改進產品本身。現在 點擊之家 仍然不是無憂無慮的漫步，但不再是雷區。

Alexander 自 2003 年起致力於分散式系統，開發大型專案 MySQL、甲骨文 и Vertica的。在最後 高負載++ 2019 亞歷山大，使用的先驅之一 點擊之家，告訴我們這個 DBMS 現在是什麼。我們將了解主要功能 點擊之家：它與其他系統有何不同以及在什麼情況下使用它更有效。透過範例，我們將了解基於以下內容建構系統的最新實踐和經過專案測試的實踐： 點擊之家.

回顧：3年前發生的事情

三年前我們轉讓了公司 LifeStreet 上 點擊之家 來自另一個分析資料庫，廣告網路分析遷移如下所示：

2016 年 XNUMX 月。 開源的 出現 點擊之家 我們的專案開始了；
八月。 概念證明：大型廣告網路、基礎設施和 200-300 TB 的資料；
十月。第一生產數據；
十二月。完整的產品負載為每天 10-50 億個事件。
2017年XNUMX月，用戶成功遷移至 點擊之家，由 2,5 台伺服器組成的叢集上的 60 PB 資料。

在遷移過程中，人們越來越體認到： 點擊之家 是一個使用起來很愉快的好系統，但這是 Yandex 的內部專案。因此，存在細微差別：Yandex 會先處理自己的內部客戶，然後才處理社群和外部使用者的需求，而 ClickHouse 在許多功能領域都沒有達到企業層級。這就是我們在 2017 年 XNUMX 月成立 Altinity 的原因 點擊之家 不僅對 Yandex 而言更快、更方便，對其他用戶也是如此。現在我們：

我們培訓並幫助建立基於以下內容的解決方案 點擊之家 以免客戶陷入麻煩，並使解決方案最終發揮作用；
我們提供 24/7 支持 點擊之家- 裝置；
我們開發自己的生態系項目；
我們積極承諾自己 點擊之家，回應想要查看某些功能的使用者的請求。

當然，我們會幫助您搬到 點擊之家 с MySQL的, Vertica的, 神諭, 綠梅, 紅移和其他系統。我們參與了各種舉措，而且都取得了成功。

為什麼搬到點擊之家

不減慢速度！ 這是主要原因。 點擊之家 - 適用於不同場景的非常快速的資料庫：

長期與人共事的人的隨機引述 點擊之家.

可擴展性。 在其他一些資料庫上，您可以在一台硬體上實現良好的效能，但是 點擊之家 您不僅可以垂直擴展，還可以水平擴展，只需添加伺服器即可。一切並不像我們希望的那樣順利，但它確實有效。您可以隨著業務的成長擴展系統。重要的是，我們不被現在的解決方案所限制，並且永遠有發展的潛力。

可移植性。對一件事沒有執著。例如，與 亞馬遜Redshift 很難搬到某個地方。 A 點擊之家 您可以將其安裝在您的筆記型電腦、伺服器上，將其部署到雲端，前往 Kubernetes — 基礎設施的運作沒有任何限制。這對大家來說都是方便的，這是許多其他同類資料庫無法誇耀的一大優勢。

靈活性. 點擊之家 並不局限於一件事，例如Yandex.Metrica，而是在越來越多的不同專案和產業中開發和使用。它可以透過添加新功能來擴展以解決新問題。例如，人們認為將日誌儲存在資料庫中是不禮貌的行為，因此他們想出了 Elasticsearch。但得益於靈活性 點擊之家，您也可以在其中儲存日誌，通常這比在 Elasticsearch -在 點擊之家 這所需的鐵量減少了十倍。

免費開源。您無需支付任何費用。無需協商在筆記型電腦或伺服器上安裝系統的許可。無隱藏費用。同時，沒有其他開源資料庫技術可以在速度上與 點擊之家. MySQL、MariaDB、Greenplum - 他們都慢得多。

社區、驅動力和樂趣。在 點擊之家 優秀的社區：聚會、聊天和阿列克謝·米洛維多夫（Alexey Milovidov），他為我們所有人帶來了活力和樂觀。

遷移到 ClickHouse

要去 點擊之家 由於某些原因，你只需要三件事：

了解限制 點擊之家 以及它不適合什麼。
充分利用 技術及其最大的優勢。
實驗。甚至了解它是如何運作的 點擊之家，並不總是能夠預測什麼時候會更快，什麼時候會更慢，什麼時候會更好，什麼時候會更差。所以試試看吧。

搬家問題

只有一個「但是」：如果你搬到 點擊之家 如果是由於其他原因造成的，那麼通常會出現問題。我們已經習慣了一些在我們最喜歡的資料庫中有效的實踐和事物。例如，任何與 SQL-資料庫認為以下一組功能是強制性的：

交易；
限制；
一致性;
指數；
更新/刪除;
空值;
毫秒；
自動類型轉換；
多重連結；
任意分區；
集群管理工具。

招聘是強制性的，但三年前 點擊之家 這些功能都無法使用！現在，還剩下不到一半尚未實現的內容：交易、限制、一致性、毫秒和類型轉換。

最主要的是在 點擊之家 一些標準做法和方法不起作用或與我們習慣的方式不同。出現在的所有內容 點擊之家，對應於“ClickHouse方式「， IE。功能與其他資料庫不同。例如：

索引未被選擇，而是被跳過。
更新/刪除 不是同步，而是異步。
有多個連接，但沒有查詢規劃器。對於資料庫領域的人來說，它們的執行方式通常不是很清楚。

ClickHouse 腳本

1960年，一位匈牙利裔美國數學家 維格納EP 寫了一篇文章“數學在自然科學中的不合理有效性」（《數學在自然科學中難以理解的有效性》）認為，由於某種原因，我們周圍的世界可以用數學定律很好地描述。數學是一門抽象的科學，以數學形式表達的物理定律並非微不足道，而且 維格納EP 強調這很奇怪。

從我的觀點， 點擊之家 ——同樣的陌生感。用維格納的話來說，我們可以這樣說：不可思議的效率是驚人的 點擊之家 在各種分析應用中！

例如，我們以 即時資料倉儲，資料幾乎連續載入到其中。我們希望在第二次延遲後收到來自它的請求。請-使用它 點擊之家，因為這是它設計的場景。 點擊之家 這正是它的使用方式，不僅在網路上，而且在行銷和財務分析中， AdTech，以及在 詐欺識別名詞在 即時資料倉儲 使用像“星”或“雪花”這樣的複雜結構方案，許多表都帶有註冊（有時是多個），並且資料通常在某些系統中儲存和更改。

讓我們來看另一個場景—— 時間序列：設備、網路、使用統計、物聯網的監控。在這裡，我們遇到了按時間順序排列的相當簡單的事件。 點擊之家 最初並不是為此開發的，但已證明其運作良好，這就是大公司使用的原因 點擊之家 作為監控資訊的儲存庫。來探討一下是否合適 點擊之家 對於時間序列，我們根據方法和結果制定了基準 數據庫 и 時標數據庫 - 專精 時間序列 資料庫. 結果是該 點擊之家，即使沒有對此類任務進行最佳化，也能在國外領域獲勝：

В 時間序列 通常使用窄表 - 幾個小列。監控可以產生大量數據——每秒數百萬筆記錄——而且它們通常是小突發的（實時的 串流）。因此，需要不同的插入腳本，並且查詢本身有自己的細節。

日誌管理。將日誌收集到資料庫通常是不好的，但是 點擊之家 這可以透過如上所述的一些註釋來完成。許多公司使用 點擊之家 正是為了這個目的。在這種情況下，我們使用一個平坦的寬表來儲存整個日誌（例如，以形式 JSON），或切成塊狀。資料通常是大批量（文件）載入的，我們透過某個欄位進行搜尋。

對於這些功能中的每一個，通常使用專門的資料庫。 點擊之家 一個人可以做所有的事情，而且做得很好，甚至超越了他們。現在讓我們仔細看看 時間序列 情景，以及如何正確“做飯” 點擊之家 對於這種情況。

時間序列

目前主要場景是這樣的 點擊之家 考慮標準解決方案。 時間序列 是一組按時間排序的事件，表示某個過程隨時間的變化。例如，這可能是每天的心率或系統中的進程數。一切能夠給時間滴答聲和某些維度的東西都是 時間序列:

大多數此類事件來自監控。這不僅可以監控網絡，還可以監控真實設備：汽車、工業系統、 物聯網、工廠或無人駕駛計程車，Yandex 已經將其放入後備箱中 點擊之家-伺服器.

例如，有些公司從船舶收集資料。每隔幾秒鐘，貨櫃船上的感測器就會發送數百個不同的測量結果。工程師研究它們，建立模型，並試圖了解船舶的使用效率，因為貨櫃船不應該閒置一秒鐘。任何停機都會造成金錢損失，因此預測路線非常重要，這可以最大限度地減少停機時間。

如今，測量專業資料庫的數量不斷增加 時間序列. 在網站上 數據庫引擎 不同的資料庫以某種方式排名，您可以按類型查看它們：

成長最快的類型是 時間序列s。圖資料庫也在成長，但是 時間序列過去幾年成長速度更快。該資料庫家族的典型代表是 數據庫, 普羅米修斯, KDB, 時標數據庫 （建立在 PostgreSQL的），解決方案來自 Amazon. 點擊之家 這裡也可以使用，並且被使用。我舉幾個公開的例子。

公司是先驅者之一 CloudFlare的 (加- 提供者）。他們監控他們的加通過 點擊之家 (DNS-要求， HTTP-查詢）具有巨大的負載 - 每秒 6 萬個事件。一切都會過去 卡夫卡，轉到 點擊之家，它提供了即時查看系統中事件的儀表板的能力。

康卡斯特 - 美國電信領域的領導者之一：網路、數位電視、電話。他們創建了一個類似的控制系統加框架內開源該項目 阿帕契流量控制 處理您的海量資料。 點擊之家 用作分析的後端。

佩爾科納 內建 點擊之家 在你的裡面 PMM儲存各種監控 MySQL的.

具體要求

時間序列資料庫有其特定的要求。

來自多個代理的快速插入。我們必須非常快速地從許多流中插入資料。 點擊之家 它做得很好，因為它的所有插入都是非阻塞的。任何插是磁碟上的一個新文件，小插入可以以一種或另一種方式緩衝。在 點擊之家 最好批量插入數據，而不是一次插入一行。
靈活的方案。在 時間序列 我們通常不完全了解資料結構。可以為特定應用程式建立監控系統，但很難將其用於其他應用程式。這就需要一個更有彈性的方案。 點擊之家，允許您執行此操作，即使它是強類型基礎。
資料的高效儲存和遺忘。通常在 時間序列 資料量龐大，因此必須盡可能有效率地儲存。例如，在 數據庫 良好的壓縮性是其主要特徵。但除了儲存之外，您還需要能夠「忘記」舊資料並執行某種操作 下採樣 — 聚合體的自動計數。
聚合資料快速查詢。有時以毫秒的精度查看最後 5 分鐘很有趣，但對於每月的數據，可能不需要分鐘或秒的粒度 - 一般統計數據就足夠了。這種支援是必要的，否則3個月的請求即使在國內也需要很長時間才能完成。 點擊之家.
請求如“最後一點，截至»。這些是典型的 時間序列 查詢：查看系統某一時刻的最後一次測量或狀態 t。對於資料庫來說，這些查詢並不是非常令人愉快的查詢，但您也需要能夠執行它們。
“黏合”時間序列. 時間序列 是一個時間序列。如果有兩個時間序列，往往需要將它們連接起來並相互關聯。在所有資料庫上執行此操作並不方便，尤其是對於未對齊的時間序列：這裡有一些時間點，還有其他時間點。你可以考慮平均，但是突然那裡還是會有一個洞，所以不清楚。

讓我們看看如何滿足這些要求 點擊之家.

駕駛

В 點擊之家 計劃 時間序列 根據資料的規律性程度，可以透過不同的方式來完成。當我們事先知道所有指標時，就可以基於常規資料建構系統。例如，我這樣做了 CloudFlare的 帶監控加是一個優化良好的系統。您可以建立一個更通用的系統來監控整個基礎設施和各種服務。在資料不規則的情況下，我們事先並不知道我們正在監控什麼——這可能是最常見的情況。

常規數據。列。 方案很簡單 - 具有所需類型的列：

CREATE TABLE cpu (
  created_date Date DEFAULT today(),  
  created_at DateTime DEFAULT now(),  
  time String,  
  tags_id UInt32,  /* join to dim_tag */
  usage_user Float64,  
  usage_system Float64,  
  usage_idle Float64,  
  usage_nice Float64,  
  usage_iowait Float64,  
  usage_irq Float64,  
  usage_softirq Float64,  
  usage_steal Float64,  
  usage_guest Float64,  
  usage_guest_nice Float64
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

這是一個監視某種系統載入活動的常規表（用戶, 系統, 閒置, 尼斯）。簡單方便，但不靈活。如果我們想要更靈活的方案，那麼我們可以使用陣列。

不規則資料。陣列:

CREATE TABLE cpu_alc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metrics Nested(
    name LowCardinality(String),  
    value Float64
  )
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

SELECT max(metrics.value[indexOf(metrics.name,'usage_user')]) FROM ...

結構嵌套是兩個數組： 指標名稱 и 指標值。在這裡，您可以將任意監控資料儲存為每個事件的名稱陣列和測量值陣列。為了進一步優化，您可以建立多個這樣的結構，而不是一個。例如，一個用於浮動-值，另一個 - 為 INT- 意思是因為 INT 我想更有效地存儲。

但這樣的結構比較難訪問。您將必須使用特殊的構造，使用特殊的函數來先提取索引的值，然後提取數組的值：

SELECT max(metrics.value[indexOf(metrics.name,'usage_user')]) FROM ...

但它仍然工作得很快。儲存不規則資料的另一種方法是按行。

不規則資料。弦樂。在這種傳統方法中，沒有數組，名稱和值是同時儲存的。如果一台設備同時發出 5 個測量值，則資料庫中會產生 000 行：

CREATE TABLE cpu_rlc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metric_name LowCardinality(String),  
  metric_value Float64
) ENGINE = MergeTree(created_date, (metric_name, tags_id, created_at), 8192);


SELECT 
    maxIf(metric_value, metric_name = 'usage_user'),
    ... 
FROM cpu_r
WHERE metric_name IN ('usage_user', ...)

點擊之家 解決這個問題 - 它有特殊的擴展 點擊之家 的SQL。例如， 最大If — 一種特殊函數，在滿足某些條件時計算度量的最大值。您可以在一個請求中編寫多個此類表達式，並立即計算多個指標的值。

讓我們比較一下三種方法：

詳細信息

這裡我為一些測試資料集添加了「磁碟資料大小」。就列而言，我們擁有最小的資料大小：最大壓縮、最大查詢速度，但我們必須一次記錄所有內容。

對於數組來說，一切都有點糟糕。資料仍然被很好地壓縮並且可以儲存不規則的模式。但 點擊之家 - 列式資料庫，當我們開始將所有內容儲存在陣列中時，它就會變成行一，我們為靈活性和效率付出了代價。對於任何操作，您都必須將整個數組讀入內存，然後在其中找到所需的元素 - 如果數組增長，則速度會降低。

在使用這種方法的公司之一（例如，尤伯杯），數組被切割成 128 個元素的塊。每天200TB資料量的數千個指標的資料不是儲存在一個陣列中，而是儲存在具有特殊儲存邏輯的10或30個陣列中。

最簡單的方法是使用字串。但資料壓縮率很差，表大小很大，即使基於多個指標進行查詢，ClickHouse 也無法以最佳方式運作。

混合方案

假設我們選擇了陣列電路。但是，如果我們知道大多數儀表板僅顯示使用者和系統指標，那麼我們也可以透過以下方式將這些指標具體化為表格層級陣列中的欄位：

CREATE TABLE cpu_alc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metrics Nested(
    name LowCardinality(String),  
    value Float64
  ),
  usage_user Float64 
             MATERIALIZED metrics.value[indexOf(metrics.name,'usage_user')],
  usage_system Float64 
             MATERIALIZED metrics.value[indexOf(metrics.name,'usage_system')]
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

插入時 點擊之家 會自動計算它們。這樣您就可以將工作與娛樂結合：該方案靈活且通用，但我們提取了最常用的列。請注意，這不需要更改插入件和 ETL它繼續將數組插入表中。我們剛剛做了 更改表，添加了幾個揚聲器，我們得到了一個混合且更快的方案，您可以立即開始使用。

編解碼器和壓縮

為 時間序列 資料打包的好壞很重要，因為資訊量可能非常大。在 點擊之家 有一組工具可以實現1:10、1:20、有時甚至更多的壓縮效果。這意味著磁碟上 1 TB 的解壓縮資料佔用 50-100 GB。尺寸越小越好，可以更快地讀取和處理資料。

為了實現高水準的壓縮， 點擊之家 支援以下編解碼器：

範例表：

CREATE TABLE benchmark.cpu_codecs_lz4 (
    created_date Date DEFAULT today(), 
    created_at DateTime DEFAULT now() Codec(DoubleDelta, LZ4), 
    tags_id UInt32, 
    usage_user Float64 Codec(Gorilla, LZ4), 
    usage_system Float64 Codec(Gorilla, LZ4), 
    usage_idle Float64 Codec(Gorilla, LZ4), 
    usage_nice Float64 Codec(Gorilla, LZ4), 
    usage_iowait Float64 Codec(Gorilla, LZ4), 
    usage_irq Float64 Codec(Gorilla, LZ4), 
    usage_softirq Float64 Codec(Gorilla, LZ4), 
    usage_steal Float64 Codec(Gorilla, LZ4), 
    usage_guest Float64 Codec(Gorilla, LZ4), 
    usage_guest_nice Float64 Codec(Gorilla, LZ4), 
    additional_tags String DEFAULT ''
)
ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

這裡我們定義編解碼器 雙三角洲 在一種情況下，在第二種情況下 - 大猩猩，我們肯定會添加更多 LZ4 壓縮。結果，磁碟上資料的大小大大減少：

這顯示了相同的資料佔用多少空間，但使用不同的編解碼器和壓縮：

在磁碟上的 GZIP 檔案中；
在 ClickHouse 中，沒有編解碼器，但使用 ZSTD 壓縮；
在 ClickHouse 中，具有編解碼器和壓縮 LZ4 和 ZSTD。

可以看出，有編解碼器的表格佔用的空間要少得多。

尺寸很重要

同樣重要 выбрать 正確的資料型態：

在上面的所有例子中我都使用了 浮動64。但如果我們選擇 浮動32，那就更好了。 Perkona 的人在上面鏈接的文章中很好地證明了這一點。使用適合該任務的最緊湊的類型非常重要：磁碟大小甚至小於查詢速度。 點擊之家 對此非常敏感。

如果你可以使用 intxnumx 而不是 intxnumx，那麼預計性能將提高近兩倍。資料佔用的記憶體更少，所有的「算術」運行得更快。 點擊之家 在內部，它是一個類型非常嚴格的系統；它最大限度地利用了現代系統提供的所有可能性。

聚合和物化視圖

聚合和物化視圖可讓您為不同場合建立聚合：

例如，您可能有非聚合的來源數據，您可以透過特殊引擎將各種物化視圖附加到它們上並自動求和 求和合併樹 (SMT). SMT 是一種特殊的聚合資料結構，可以自動計算聚合。原始資料被插入資料庫，自動聚合，並且可以立即在其上使用儀表板。

TTL - “忘記”舊數據

如何「忘記」不再需要的數據？ 點擊之家 知道如何做到這一點。建立表格時可以指定 TTL 表達式：例如，我們儲存一天的分鐘數據，30天的每日數據，並且從不觸及每週或每月的數據：

CREATE TABLE aggr_by_minute
…
TTL time + interval 1 day

CREATE TABLE aggr_by_day
…
TTL time + interval 30 day

CREATE TABLE aggr_by_week
…
/* no TTL */

多層 - 將資料劃分到磁碟上

進一步發展這個想法，資料可以儲存在 點擊之家 在不同的地方。假設我們想將上週的熱數據儲存在一個非常快的本地 SSD，我們把更多的歷史數據放在另一個地方。在 點擊之家 現在這是可能的：

您可以設定儲存策略（儲存策略）所以 點擊之家 達到一定條件時會自動將資料傳輸到另一個儲存。

但這還不是全部。在特定表格的級別，您可以準確定義資料何時進入冷儲存的規則。例如，資料在非常快速的磁碟上儲存 7 天，較舊的所有內容都會轉移到慢速磁碟上。這很好，因為它允許您使系統保持最佳性能，同時控製成本並且不會在冷數據上浪費金錢：

CREATE TABLE 
... 
TTL date + INTERVAL 7 DAY TO VOLUME 'cold_volume', 
    date + INTERVAL 180 DAY DELETE

獨特的機會點擊之家

幾乎在所有事情上 點擊之家 確實有這樣的“亮點”，但它們被排他性所抵消——這是其他資料庫所沒有的。例如，以下是一些獨特的功能 點擊之家:

數組。在 點擊之家 對數組非常好的支持，以及對它們執行複雜計算的能力。
聚合資料結構。這是「殺手級功能」之一 點擊之家。儘管 Yandex 的人說我們不想聚合數據，但所有內容都聚合在 點擊之家，因為它又快又方便。
物化視圖。與聚合資料結構一起，物化視圖使您可以方便地 實時的 聚合。
ClickHouse SQL。這是一個語言擴展 的SQL 具有一些僅在 點擊之家。以前，一方面像是擴張，另一方面又像是一種劣勢。現在幾乎所有的缺點相比 SQL 92. 我們刪除了它，現在它只是一個擴充。
拉姆達– 表達式。它們還在資料庫中嗎？
ML-支持。這在不同的資料庫中可用，有些更好，有些更差。
開源。我們可以擴展 點擊之家 一起。現在在 點擊之家 大約有 500 名貢獻者，而且這個數字還在持續增加中。

棘手的查詢

В 點擊之家 做同一件事有很多不同的方法。例如，您可以透過三種不同的方式傳回表格中的最後一個值： 中央處理器 （還有第四種，但更奇特）。

第一個顯示了它是多麼方便 點擊之家 當你想檢查時查詢元組包含在子查詢中。這是我個人在其他資料庫中真正錯過的東西。如果我想將某些內容與子查詢進行比較，那麼在其他資料庫中只能與標量進行比較，但是對於幾個列，我需要編寫註冊。在 點擊之家 你可以使用元組：

SELECT *
  FROM cpu 
 WHERE (tags_id, created_at) IN 
    (SELECT tags_id, max(created_at)
        FROM cpu 
        GROUP BY tags_id)

第二種方法做同樣的事情，但使用聚合函數 最大精量:

SELECT 
    argMax(usage_user), created_at),
    argMax(usage_system), created_at),
...
 FROM cpu

В 點擊之家 有幾十個聚合函數，如果使用組合器，那麼根據組合定律，您將獲得大約一千個。 最大精胺酸 - 計算最大值的函數之一：請求返回值 使用用戶，此時達到最大值 創建時間:

SELECT now() as created_at,
       cpu.*
  FROM (SELECT DISTINCT tags_id from cpu) base 
  ASOF LEFT JOIN cpu USING (tags_id, created_at)

加入 — 用不同的時間「黏合」行。 這是資料庫獨有的功能，僅在 kdb +。如果有兩個不同時間的時間序列，加入允許您在一個請求中移動和合併它們。對於一個時間序列中的每個值，找到另一個時間序列中最接近的值，並將它們在同一行上傳回：

解析函數

在標準 SQL-2003 你可以這樣寫：

SELECT origin,
       timestamp,
       timestamp -LAG(timestamp, 1) OVER (PARTITION BY origin ORDER BY timestamp) AS duration,
       timestamp -MIN(timestamp) OVER (PARTITION BY origin ORDER BY timestamp) AS startseq_duration,
       ROW_NUMBER() OVER (PARTITION BY origin ORDER BY timestamp) AS sequence,
       COUNT() OVER (PARTITION BY origin ORDER BY timestamp) AS nb
  FROM mytable
ORDER BY origin, timestamp;

В 點擊之家 你不能這樣做——它不支援標準 SQL-2003 並且可能永遠不會這樣做。相反，在 點擊之家 習慣上這樣寫：

我答應過 lambda - 它們就在這裡！

這是標準中分析查詢的模擬 SQL-2003: 他計算兩者之間的差異 時間戳、持續時間、序數 - 我們通常認為的分析函數的所有內容。在 點擊之家 我們透過數組對它們進行計數：首先我們將資料折疊到一個數組中，然後我們對數組執行我們想要的所有操作，然後將其擴展回來。它不是很方便，至少需要熱愛函數式編程，但它非常靈活。

特殊功能

此外，在 點擊之家 許多專門的功能。例如，如何決定有多少會話同時進行？一項典型的監控任務是決定一個請求的最大負載。在 點擊之家 為此有一個特殊的函數：

總的來說，ClickHouse 有多種用途的特殊功能：

runningDifference、runningAccumulate、neighbor；
sumMap(鍵, 值);
timeSeriesGroupSum(uid, 時間戳記, 值);
timeSeriesGroupRateSum(uid, 時間戳記, 值);
skewPop、skewSamp、kurtPop、kurtSamp；
附填充/附繫帶；
簡單線性迴歸，隨機線性迴歸。

這不是完整的功能列表，總共有 500-600 個。提示：所有函數 點擊之家 位於系統表中（並非所有內容都有記錄，但所有內容都很有趣）：

select * from system.functions order by name

點擊之家 它儲存了很多關於自身的信息，包括 紀錄表, 查詢日誌、追蹤日誌、資料塊操作日誌（部分日誌）、指標日誌和系統日誌，通常將其寫入磁碟。日誌指標是 時間序列 в 點擊之家 實際上 點擊之家：資料庫本身就可以發揮作用 時間序列 資料庫，從而「吞噬」自身。

這也是一件獨特的事——因為我們做得很好 時間序列，為什麼我們不能把我們需要的一切都儲存在自己身上呢？我們不需要 普羅米修斯，我們把一切都留給自己。連接的 格拉法納 我們監控自己。然而，如果 點擊之家 跌倒了，我們不知道為什麼，所以他們通常不會這樣做。

大簇或許多小簇點擊之家

一個大型集群和許多小型 ClickHouse 哪個更好？傳統方法 DWH 是一個大集群，其中為每個應用程式分配了電路。我們找到資料庫管理員 - 給我們一張圖表，他們給了我們一個：

В 點擊之家 你可以用不同的方式來做。您可以將每個應用程式變成您自己的應用程式 點擊之家:

我們不再需要那個巨大的怪物了 DWH 和棘手的管理員。我們可以為每個應用程式提供自己的 點擊之家，開發者可以自己做，因為 點擊之家 安裝非常簡單，不需要複雜的管理：

但如果我們有很多 點擊之家，並且您需要經常安裝它，那麼您希望自動化此過程。為此，我們可以例如使用 Kubernetes и 點擊之家-操作員。在 Kubernetes ClickHouse 您可以將其“單擊”：我可以單擊一個按鈕，運行清單，資料庫就準備好了。我可以立即建立圖表，開始上傳指標，5 分鐘內我就準備好了儀表板 格拉法納。就這麼簡單！

結果如何呢？

因此， 點擊之家 - 這是：

Быстро。每個人都知道這一點。
只是。有點爭議，但我認為訓練難，戰鬥容易。如果你明白如何 點擊之家 它有效，那麼一切就非常簡單了。
普遍地。適用於不同場景： DWH、時間序列、日誌存儲。但事實並非如此 OLTP 資料庫，所以不要嘗試在那裡進行短插入和讀取。
有趣。可能是和他一起工作的人 點擊之家，經歷了許多有趣的時刻，無論是好的還是壞的。例如，新版本發布後，一切都停止了。或者當你在一項任務上苦苦掙扎了兩天，但在 Telegram 聊天中提出問題後，任務在兩分鐘內就解決了。或者像 Lesha Milovidov 的報告中的會議一樣，截圖來自 點擊之家 打破了廣播 高負載++。這種事情時常發生，讓我們的生活變得困難。 點擊之家 明亮又有趣！

您可以觀看演示這裡.

期待已久的高負載系統開發人員會議高負載++ 將於 9 月 10 日至 XNUMX 日在斯科爾科沃舉行。最後，這將是一次線下會議（儘管採取了所有預防措施），因為 HighLoad++ 的能量無法在線上打包。

在這次會議上，我們找到並向您展示有關技術最大能力的案例：HighLoad++ 過去、現在和將來都是您可以在兩天內了解 Facebook、Yandex、VKontakte、Google 和 Amazon 如何工作的唯一場所。

自2007年以來，我們的會議從未間斷過，今年我們將舉行第14次會議。在此期間，會議規模擴大了 10 倍；去年，這項重要的產業盛會匯集了 3339 名參與者、165 位演講嘉賓、報告和聚會，16 個分會場同時進行。
去年有20輛公車、5280公升茶和咖啡、1650公升果汁飲料和10200瓶水。還有2640公斤食物、16個盤子和000個杯子。順便說一句，我們用回收紙籌集的資金種植了 25 棵橡樹苗:)

你可以買票這裡，獲取有關會議的新聞 - 這裡，並在所有社交網絡上討論： Telegram, Facebook, VKontakte等 и Twitter.

來源： www.habr.com

搬到 ClickHouse：3 年後

回顧：3年前發生的事情

為什麼搬到點擊之家

遷移到 ClickHouse

搬家問題

ClickHouse 腳本

時間序列

具體要求

駕駛

混合方案

編解碼器和壓縮

尺寸很重要

聚合和物化視圖

TTL - “忘記”舊數據

多層 - 將資料劃分到磁碟上

獨特的機會點擊之家

棘手的查詢

解析函數

我答應過 lambda - 它們就在這裡！

特殊功能

大簇或許多小簇點擊之家

結果如何呢？

添加評論取消回复

搬到 ClickHouse：3 年後

回顧：3年前發生的事情

為什麼搬到 點擊之家

遷移到 ClickHouse

搬家問題

ClickHouse 腳本

時間序列

具體要求

駕駛

混合方案

編解碼器和壓縮

尺寸很重要

聚合和 物化視圖

TTL - “忘記”舊數據

多層 - 將資料劃分到磁碟上

獨特的機會 點擊之家

棘手的查詢

解析函數

我答應過 lambda - 它們就在這裡！

特殊功能

大簇或許多小簇 點擊之家

結果如何呢？

添加評論 取消回复

為什麼搬到點擊之家

聚合和物化視圖

獨特的機會點擊之家

大簇或許多小簇點擊之家

添加評論取消回复