在過去的幾年裡，時間序列資料庫已經從一個奇怪的東西（高度專業化地用於開放監控系統（並與特定解決方案相關）或大數據專案中）變成了「消費性產品」。 在俄羅斯聯邦境內，必須為此特別感謝 Yandex 和 ClickHouse。 到目前為止，如果您需要存儲大量時間序列數據，您要么必須接受構建龐大的 Hadoop 堆疊並維護它的需求，要么與每個系統的單獨協議進行通信。
2019年，一篇關於哪個TSDB值得用的文章似乎只有一句話：「就用ClickHouse吧」。 但是…存在細微差別。
事實上，ClickHouse 正在積極發展，用戶群正在成長，支持也非常積極，但是我們是否成為 ClickHouse 公眾成功的人質，它已經蓋過了其他也許更有效/可靠的解決方案？
去年年初，我們開始改造自己的監控系統，期間就出現了選擇一個合適的資料庫來儲存資料的問題。 我想在這裡談談這個選擇的歷史。
制定問題
首先，必要的前言。 為什麼我們需要自己的監控系統？它是如何設計的？
我們在2008 年開始提供支援服務，到2010 年，很明顯，用當時存在的解決方案（我們正在談論，上帝原諒我，Cacti，Zabbix）聚合有關客戶端基礎設施中發生的流程的數據變得很困難和新興的石墨）。
我們的主要要求是：
- 在一個系統內支援（當時是數十個，將來是數百個）客戶端，同時存在集中式警報管理系統；
- 管理警報系統的彈性（值班人員之間的警報升級、調度、知識庫）；
- 深入描述圖表細節的能力（Zabbix當時以圖片的形式渲染圖表）；
- 長期儲存大量資料（一年或更長時間）並能夠快速檢索。
在本文中，我們對最後一點感興趣。
說到存儲，要求如下：
- 系統必須快速運作；
- 系統最好有SQL介面；
- 系統必須穩定並且有活躍的用戶基礎和支持（曾經我們面臨需要支持系統，例如不再開發的MemcacheDB，或MooseFS分佈式存儲，其錯誤跟踪器保留為中文：我們為我們的項目重複這個故事並不想要）；
- 遵守CAP定理：一致性（必要）－資料必須是最新的，我們不希望警報管理系統無法接收新資料並吐出所有專案資料未到達的警報； 分區容錯性（必需）－我們不想得到裂腦系統； 可用性（並不重要，如果有活動副本）－我們可以在發生事故時使用程式碼自行切換到備份系統。
奇怪的是，當時 MySQL 竟然成為我們的理想解決方案。 我們的資料結構非常簡單：伺服器id、計數器id、時間戳記和值； 大緩衝池保證熱點資料的快速取樣，SSD保證歷史資料的取樣。
因此，我們獲得了兩週的新鮮資料樣本，詳細資訊可精確到資料完全渲染前的第二個 200 毫秒，並在該系統中存活了相當長的時間。
同時，時間流逝，數據量不斷增長。 到 2016 年，資料量達到數十 TB，這對於租用 SSD 儲存來說是一筆龐大的開支。
這時候，列式資料庫已經積極普及，我們開始積極思考：在列式資料庫中，數據按照你可以理解的方式儲存在列中，如果你看我們的數據，很容易看到一個很大的數據。如果您使用列式資料庫，則可以使用壓縮來壓縮它的重複項數。
不過，該公司的關鍵系統繼續穩定運行，我不想嘗試切換到其他系統。
2017 年，在聖荷西舉行的 Percona Live 會議上，Clickhouse 開發者可能首次宣布了自己的身分。 乍一看，該系統已做好生產準備（Yandex.Metrica 是一個苛刻的生產系統），支援快速而簡單，最重要的是，操作也很簡單。 自2018年起，我們開始了轉型過程。 但到那時，已經有許多「成熟」且經過時間考驗的 TSDB 系統，我們決定投入大量時間來比較替代方案，以確保根據我們的要求，沒有 Clickhouse 的替代解決方案。
除了已經指定的儲存要求之外，還出現了新的要求：
- 新系統應該在相同數量的硬體上至少提供與MySQL相同的效能；
- 新系統的儲存佔用空間應顯著減少；
- DBMS 仍然必須易於管理；
- 我想在更改 DBMS 時對應用程式進行最少的更改。
我們開始考慮哪些系統？
Apache Hive/Apache Impala
一個經過考驗的舊 Hadoop 堆疊。 本質上，它是一個建立在 HDFS 上以本機格式儲存資料之上的 SQL 介面。
優點。
- 運作穩定，資料擴容非常容易。
- 資料儲存有列式解決方案（空間較小）。
- 當資源可用時，並行任務的執行速度非常快。
缺點。
- 它是 Hadoop，而且很難使用。 如果我們還沒有準備好在雲端中採用現成的解決方案（而且我們在成本方面還沒有準備好），那麼整個堆疊將必須由管理員來組裝和支持，我們真的不希望這。
- 數據已匯總 .
但：
速度是透過擴展計算伺服器的數量來實現的。 簡單地說，如果我們是一家大公司，從事分析，並且盡快聚合資訊對業務至關重要（即使是以使用大量計算資源為代價），這可能是我們的選擇。 但我們還沒準備好增加硬體群來加速任務。
德魯伊/皮諾
關於 TSDB 的具體內容還有很多，但也是 Hadoop 堆疊。
有 .
簡而言之：在以下情況下，Druid/Pinot 看起來比 Clickhouse 更好：
- 您具有異質的資料性質（在我們的例子中，我們只記錄伺服器指標的時間序列，事實上，這是一張表。但可能還有其他情況：設備時間序列、經濟時間序列等- 每個都有它自己的結構，需要聚合和處理）。
- 而且，這樣的數據還有很多。
- 具有時間序列的表格和資料出現和消失（即，某些資料集到達、被分析和刪除）。
- 沒有明確的數據劃分標準。
在相反的情況下，ClickHouse 表現更好，這就是我們的情況。
點擊之家
- 類似SQL
- 易於管理。
- 人們說它有效。
進入測試候選名單。
數據庫
ClickHouse 的國外替代品。 缺點： 高可用性僅存在於商業版本中，但需要進行比較。
進入測試候選名單。
卡桑德拉
一方面，我們知道它用於儲存監控系統的指標時間序列，例如： 或 OkMeter。 不過，也有具體情況。
Cassandra並不是傳統意義上的列式資料庫。 它看起來更像是行視圖，但每行可以有不同數量的列，從而可以輕鬆組織柱狀視圖。 從這個意義上講，很明顯，在 2 億列的限制下，可以在列中儲存一些資料（以及相同的時間序列）。 例如，在 MySQL 中，列數限制為 4096，如果您嘗試執行相同的操作，很容易發現程式碼 1117 的錯誤。
Cassandra引擎專注於在沒有master的分散式系統中儲存大量數據，而上述Cassandra CAP定理更多的是關於AP，即關於數據可用性和抗分區性。 因此，如果您只需要寫入該資料庫而很少從中讀取數據，那麼該工具可能會非常有用。 在這裡，使用 Cassandra 作為「冷」儲存是合乎邏輯的。 也就是說，作為一個長期、可靠的地方來儲存大量很少需要但可以在必要時檢索的歷史資料。 儘管如此，為了完整起見，我們也會對其進行測試。 但是，正如我之前所說，我們不想主動重寫所選資料庫解決方案的程式碼，因此我們將對其進行有限的測試 - 不根據 Cassandra 的具體情況調整資料庫結構。
普羅米修斯
出於好奇，我們決定測試 Prometheus 儲存的效能 - 只是為了了解我們是否比目前解決方案快或慢以及慢了多少。
測試方法和結果
因此，我們在以下 5 個組態中測試了 6 個資料庫：ClickHouse（1 個節點）、ClickHouse（3 個節點的分散式表）、InfluxDB、Mysql 8、Cassandra（3 個節點）和 Prometheus。 測試計劃如下：
- 上傳一週歷史資料（每天840億個數值；208萬個指標）；
- 我們產生一個記錄負載（考慮了 6 種負載模式，見下文）；
- 在記錄的同時，我們定期進行選擇，模擬使用圖表的使用者的請求。 為了不讓事情變得太複雜，我們選擇了一週 10 個指標的資料（這正是 CPU 圖表上的數量）。
我們透過模擬監控代理的行為來加載，該代理每 15 秒向每個指標發送一次值。 同時，我們對改變：
- 寫入資料的指標總數；
- 向一個指標發送值的時間間隔；
- 批量大小。
關於批量大小。 由於不建議透過單一插入來載入幾乎所有實驗資料庫，因此我們需要一個中繼來收集傳入指標並將它們分組並將它們作為批次插入寫入資料庫。
另外，為了更好地理解如何解釋接收到的數據，讓我們想像一下，我們不僅發送一堆指標，而且將指標組織到伺服器中 - 每個伺服器 125 個指標。 這裡伺服器只是一個虛擬實體——只是為了理解，例如，10000 個指標對應大約 80 個伺服器。
考慮到所有這些，這裡是我們的 6 種資料庫寫入載入模式：
這裡有兩點。 首先，對於 Cassandra 來說，這些批量大小太大，因此我們使用了 50 或 100 的值。其次，由於 Prometheus 嚴格在拉模式下工作，即它本身會從指標來源收集資料（甚至pushgateway，儘管有這個名字，並沒有從根本上改變情況），相應的負載是使用靜態配置的組合來實現的。
測試結果如下：
有什麼值得注意的：來自 Prometheus 的樣本速度極快，來自 Cassandra 的樣本速度極慢，來自 InfluxDB 的樣本速度慢得令人無法接受； 在記錄速度方面，ClickHouse贏得了所有人，而Prometheus不參與競爭，因為它自己進行插入，我們不測量任何東西。
其結果是，：ClickHouse和InfluxDB證明了自己是最好的，但是Influx的集群只能建立在企業版的基礎上，需要花錢，而ClickHouse不花錢，而且是俄羅斯製造的。 合乎邏輯的是，在美國，選擇可能會支援 inInfluxDB，而在我們國家，選擇可能會支援 ClickHouse。
來源： www.habr.com