是 Yandex 創建的用於聯機分析查詢處理 (OLAP) 的開源列式數據庫管理系統。 Yandex、CloudFlare、VK.com、Badoo 和世界各地的其他服務都使用它來存儲大量數據（每秒插入數千行或磁盤上存儲的 PB 數據）。
在普通的“字符串”DBMS 中，例如 MySQL、Postgres、MS SQL Server，數據按以下順序存儲：
在這種情況下，與一行相關的值在物理上並排存儲。 在列式DBMS中，不同列的值分別存儲，一列的數據存儲在一起：
列式 DBMS 的示例有 Vertica、Paraccel（Actian Matrix、Amazon Redshift）、Sybase IQ、Exasol、Infobright、InfiniDB、MonetDB（VectorWise、Actian Vector）、LucidDB、SAP HANA、Google Dremel、Google PowerDrill、Druid、kdb+。
公司是郵件轉運商 我在 2018 年開始使用 Clickhouse 進行報告，它的簡單性、可擴展性、SQL 支持和速度給我留下了深刻的印象。 這個 DBMS 的速度近乎神奇。
簡單
Clickhouse 使用單個命令在 Ubuntu 上安裝。 如果您了解 SQL，您可以立即開始使用 Clickhouse 來滿足您的需求。 但是，這並不意味著您可以在 MySQL 中“顯示創建表”並在 Clickhouse 中復制粘貼 SQL。
與 MySQL 相比，此 DBMS 中的表模式定義存在重要的數據類型差異，因此您仍然需要一些時間來更改表模式定義並學習表引擎才能適應。
Clickhouse 在沒有任何額外軟件的情況下工作得很好，但如果你想使用複制，你需要安裝 ZooKeeper。 查詢性能分析顯示出極好的結果——系統表包含了所有的信息，所有的數據都可以使用舊的、無聊的 SQL 來獲取。
Производительность
- 配置服務器上的 Clickhouse 與 Vertica 和 MySQL 比較：兩個插槽 Intel® Xeon® CPU E5-2650 v2 @ 2.60GHz； 128 GiB 內存； md RAID-5 在 8 個 6TB SATA 硬盤上，ext4。
- Clickhouse 與 Amazon RedShift 雲存儲的比較。
- 博客摘錄 :
ClickHouse 數據庫的設計非常簡單——集群中的所有節點都具有相同的功能，並且只使用 ZooKeeper 進行協調。 我們構建了一個由多個節點組成的小型集群並進行了測試，在此期間我們發現該系統具有相當可觀的性能，這與分析型 DBMS 基準測試中聲稱的優勢相對應。 我們決定仔細研究 ClickHouse 背後的概念。 研究的第一個障礙是缺乏工具和 ClickHouse 的小社區，因此我們深入研究了這個 DBMS 的設計以了解它是如何工作的。
ClickHouse 不支持直接從 Kafka 接收數據，因為它只是一個數據庫，所以我們用 Go 編寫了自己的適配器服務。 它從 Kafka 讀取 Cap'n Proto 編碼的消息，將它們轉換為 TSV，並通過 HTTP 接口將它們批量插入到 ClickHouse 中。 我們後來重寫了此服務，以結合我們自己的 ClickHouse 接口使用 Go 庫來提高性能。 在評估接收數據包的性能時，我們發現了一件重要的事情——事實證明，對於 ClickHouse，這種性能在很大程度上取決於數據包的大小，即同時插入的行數。 為了理解為什麼會發生這種情況，我們研究了 ClickHouse 如何存儲數據。
ClickHouse 用於存儲數據的主要引擎，或者更確切地說，是一系列表引擎，是 MergeTree。 該引擎在概念上類似於 Google BigTable 或 Apache Cassandra 中使用的 LSM 算法，但避免構建中間內存表並將數據直接寫入磁盤。 這使其具有出色的寫入吞吐量，因為每個插入的數據包僅按“主鍵”主鍵排序、壓縮並寫入磁盤以形成一個段。
沒有內存表，沒有任何數據“新鮮度”的概念，也意味著它們只能被添加，系統不支持更改或刪除。 截至今天，刪除數據的唯一方法是按日曆月刪除數據，因為段永遠不會跨越月份邊界。 ClickHouse 團隊正在積極致力於使此功能可定制。 另一方面，它使寫入和合併段無爭用，因此接收吞吐量與並行插入的數量成線性比例關係，直到 I/O 或內核飽和。
但是，這種情況也意味著系統不適合小包，因此使用Kafka服務和插入器進行緩衝。 進一步的，ClickHouse在後台不斷的合併segments，這樣很多小塊的信息會被合併記錄更多次，從而增加記錄的強度。 但是，只要合併繼續，太多不相關的部分將導致插入的積極節流。 我們發現實時數據攝取和攝取性能之間的最佳折衷是每秒接受有限數量的插入到表中。
表讀取性能的關鍵是磁盤上數據的索引和位置。 無論處理速度有多快，當引擎需要從磁盤掃描數 TB 的數據並且只使用其中的一小部分時，都需要時間。 ClickHouse 是一個列存儲，因此每個段都包含一個文件，用於每一列（column），每一行都有排序後的值。 因此，可以首先跳過查詢中不存在的整個列，然後可以使用矢量化執行並行處理多個單元格。 為避免全掃描，每個段都有一個小索引文件。
鑑於所有列都按“主鍵”排序，索引文件僅包含每第 N 行的標籤（捕獲的行），以便即使對於非常大的表也能將它們保存在內存中。 例如，您可以將默認設置設置為“標記每 8192 行”，然後對具有 1 萬億的表進行“微薄”索引。 易於記憶的行只需要 122 個字符。
系統開發
Clickhouse的發展和完善可以追溯到 並確保“成長”的過程以令人印象深刻的速度發生。
聲望
Clickhouse 的受歡迎程度似乎呈指數級增長，尤其是在俄語社區。 去年的 High load 2018 會議（莫斯科，8 年 9 月 2018 日至 40 日）顯示，像 vk.com 和 Badoo 這樣的怪物使用 Clickhouse，它同時從數万台服務器插入數據（例如，日誌）。 在一段 XNUMX 分鐘的視頻中 . 很快我們將在 Habr 上發布成績單，以方便使用這些材料。
應用
在花了一些時間研究之後，我認為 ClickHouse 在某些領域是有用的或能夠完全取代其他更傳統和流行的解決方案，如 MySQL、PostgreSQL、ELK、Google Big Query、Amazon RedShift、TimescaleDB、Hadoop、MapReduce、Pinot 和德魯伊。 下面是使用ClickHouse升級或完全替代上述DBMS的詳細介紹。
擴展 MySQL 和 PostgreSQL
最近，我們在時事通訊平台上用 ClickHouse 部分替換了 MySQL . 問題在於，由於設計不當，MySQL 使用 base64 哈希記錄了每封發送的電子郵件和該電子郵件中的每個鏈接，從而創建了一個巨大的 MySQL 表（email_stats）。 在向該服務的訂閱者發送了僅 10 萬封電子郵件後，該表佔用了 150 GB 的文件空間，MySQL 開始在簡單查詢上“變傻”。 為了解決文件空間問題，我們成功地使用了 InnoDB 表壓縮，將其減少了 4 倍。 然而，僅僅為了讀取歷史記錄而在 MySQL 中存儲超過 20-30 百萬封電子郵件仍然沒有意義，因為由於某種原因必須進行全面掃描的任何簡單查詢都會導致交換和繁重的 I/O開銷，我們經常收到 Zabbix 警告。
Clickhouse 使用兩種壓縮算法，將數據量減少了大約 ，但在這種特殊情況下，數據特別“可壓縮”。
麋鹿更換
根據我自己的經驗，ELK 堆棧（ElasticSearch、Logstash 和 Kibana，在本例中為 ElasticSearch）需要比存儲日誌所需的資源更多的資源來運行。 如果您想要良好的全文日誌搜索（我認為您並不真正需要），ElasticSearch 是一個很棒的引擎，但我想知道為什麼它已成為事實上的標準日誌記錄引擎。 它的攝取性能與 Logstash 相結合，即使在相當輕的工作負載下也給我們帶來了問題，並且需要添加越來越多的 RAM 和磁盤空間。 作為數據庫，Clickhouse 優於 ElasticSearch 的原因如下：
- SQL方言支持；
- 存儲數據的最佳壓縮程度；
- 支持正則表達式搜索而不是全文搜索；
- 改進的查詢調度和更好的整體性能。
目前，ClickHouse 與 ELK 比較出現的最大問題是缺乏上傳日誌的解決方案，以及缺乏這方面的文檔和教程。 同時，每個用戶都可以使用Digital Ocean手冊設置ELK，這對於此類技術的快速落地非常重要。 這裡有一個數據庫引擎，但是還沒有用於 ClickHouse 的 Filebeat。 就在這裡 和一個處理日誌的系統 , 有一個工具 將日誌文件數據輸入 ClickHouse，但這一切都需要更多時間。 然而，ClickHouse 仍然以其簡單性而領先，因此即使是初學者也可以輕鬆安裝它並在 10 分鐘內開始完整的功能使用。
我更喜歡極簡主義的解決方案，嘗試將 FluentBit 與 ClickHouse 一起使用，這是一種非常低內存的日誌上傳工具，同時盡量避免使用 Kafka。 但是，需要解決一些小的不兼容問題，例如 在沒有將數據從 FluentBit 轉換為 ClickHouse 的代理層之前就可以完成。
作為 Kibana 的替代方案，您可以使用 ClickHouse 作為後端 . 據我所知，這可能會在渲染大量數據點時導致性能問題，尤其是對於舊版本的 Grafana。 在 Qwintry 中，我們還沒有嘗試過這個，但 Telegram 中的 ClickHouse 支持頻道不時出現對此的投訴。
替換 Google Big Query 和 Amazon RedShift（大公司解決方案）
BigQuery 的理想用例是加載 1TB 的 JSON 數據並對其運行分析查詢。 Big Query 是一款出色的產品，其可擴展性不容小覷。 這是一個比運行在內部集群上的 ClickHouse 複雜得多的軟件，但是從客戶端的角度來看，它與 ClickHouse 有很多共同點。 一旦您開始為每個 SELECT 付費，BigQuery 就會迅速“定價”，因此它是一個真正的 SaaS 解決方案，具有所有優點和缺點。
當您運行大量計算量大的查詢時，ClickHouse 是最佳選擇。 您每天運行的 SELECT 查詢越多，用 ClickHouse 替換 Big Query 的意義就越大，因為在處理數 TB 的數據時，這樣的替換將為您節省數千美元。 這不適用於存儲的數據，在 Big Query 中處理這些數據的成本非常低。
在 Altinity 聯合創始人 Alexander Zaitsev 的一篇文章中 描述了這種 DBMS 遷移的好處。
TimescaleDB 替換
TimescaleDB 是一個 PostgreSQL 擴展，它優化了在常規數據庫中使用時間序列（, ).
雖然 ClickHouse 在時間序列利基市場上不是一個重要的競爭對手，但在列結構和向量查詢執行方面，在處理分析查詢的大多數情況下，它比 TimescaleDB 快得多。 同時，接收 ClickHouse 數據包的性能提高了約 3 倍，此外，它使用的磁盤空間減少了 20 倍，這對於處理大量歷史數據非常重要： .
與 ClickHouse 不同，在 TimescaleDB 中節省一些磁盤空間的唯一方法是使用 ZFS 或類似的文件系統。
即將推出的 ClickHouse 更新可能會引入增量壓縮，這將使它更適合處理和存儲時間序列數據。 在以下情況下，TimescaleDB 可能是比裸 ClickHouse 更好的選擇：
- RAM 很少 (<3 GB) 的小型安裝；
- 您不想緩衝成大片段的大量小 INSERT；
- 更好的一致性、均勻性和 ACID 要求；
- PostGIS支持；
- 與現有的 PostgreSQL 表合併，因為 Timescale DB 本質上是 PostgreSQL。
與 Hadoop 和 MapReduce 系統的競爭
Hadoop 和其他 MapReduce 產品可以執行很多複雜的計算，但它們往往會以巨大的延遲運行。ClickHouse 通過處理 TB 級數據並幾乎立即產生結果來解決這個問題。 因此，ClickHouse 在執行快速、交互式分析研究方面效率更高，數據科學家應該對此感興趣。
與皮諾和德魯伊競爭
ClickHouse 最接近的競爭對手是柱狀、線性可擴展的開源產品 Pinot 和 Druid。 比較這些系統的出色工作發表在文章中 1 年 2018 月 XNUMX 日
這篇文章需要更新——它說 ClickHouse 不支持 UPDATE 和 DELETE 操作，這對於最新版本來說並不完全正確。
我們對這些 DBMS 沒有太多經驗，但我不喜歡運行 Druid 和 Pinot 所需的底層基礎設施的複雜性——它是一大堆被 Java 從各個方麵包圍的“移動部件”。
Druid 和 Pinot 是 Apache 孵化器項目，Apache 在其 GitHub 項目頁面上對它們進行了詳細介紹。 Pinot 於 2018 年 8 月出現在孵化器中，Druid 則提前 XNUMX 個月——XNUMX 月誕生。
缺乏關於 AFS 如何工作的信息對我提出了一些也許是愚蠢的問題。 不知道Pinot的作者們有沒有註意到Apache基金會對Druid比較有好感，這種對待競爭對手的態度是不是有種羨慕的感覺？ 如果支持前者的讚助商突然對後者感興趣，德魯伊的發展會不會變慢，皮諾的發展會加速？
ClickHouse 的缺點
不成熟：顯然，這仍然是一項無聊的技術，但無論如何，在其他列式 DBMS 中都沒有看到這樣的技術。
小插入在高速下表現不佳：必須將插入分成大塊，因為小插入的性能與每行中的列數成比例地降低。 這就是 ClickHouse 在磁盤上存儲數據的方式 - 每列表示 1 個文件或更多，因此要插入包含 1 列的 100 行，您需要打開並寫入至少 100 個文件。 這就是插入緩衝需要中介（除非客戶端本身提供緩衝）的原因——通常是 Kafka 或某種排隊系統。 您還可以使用 Buffer 表引擎稍後將大塊數據複製到 MergeTree 表中。
表連接受服務器 RAM 的限制，但至少它們存在！ 例如，Druid 和 Pinot 根本沒有這樣的連接，因為它們很難在不支持在節點之間移動大塊數據的分佈式系統中直接實現。
發現
在未來幾年，我們計劃在 Qwintry 中廣泛使用 ClickHouse，因為該 DBMS 在性能、低開銷、可擴展性和簡單性之間實現了出色的平衡。 我敢肯定，一旦 ClickHouse 社區提出更多在中小型安裝中使用它的方法，它就會迅速傳播。
一些廣告🙂
感謝您與我們在一起。 你喜歡我們的文章嗎？ 想看更多有趣的內容？ 通過下訂單或推薦給朋友來支持我們， , 我們為您發明的入門級服務器的獨特模擬： （適用於 RAID1 和 RAID10，最多 24 個內核和最多 40GB DDR4）。
Dell R730xd 在阿姆斯特丹的 Equinix Tier IV 數據中心便宜 2 倍？ 只有這裡 在荷蘭！ Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 美元起！ 閱讀
來源： www.habr.com