本文 字數：13234 ； 估計閱讀時間：34 分鐘
作者：
Dale McDiarmid & Ryadh Dahimene
審 校： 莊曉東 （魏莊）
Meetup活動
ClickHouse Chengdu User Group第1屆 Meetup 火熱報名中，詳見文末海報！
簡介
在生產環境中操作任何復雜的技術堆疊而沒有適當的可觀察性，就好比在沒有儀器的情況下駕駛飛機。雖然這樣做可能有效，飛行員也經過訓練，但風險/報酬比遠非有利，應始終將其視為最後的手段。
作為可觀察性的初始支柱，集中式日誌記錄可用於各種目的：從偵錯生產事件、解決客戶支持問題、減輕安全漏洞，甚至了解客戶如何使用產品。
任何集中式日誌儲存的最重要特性是其能夠快速聚合、分析和搜尋來自不同來源的大量日誌數據。這種集中化簡化了故障排除，使得更容易準確定位服務中斷的根本原因。無需看更遠，只需看Elastic、Datadog和Splunk，它們利用了這個價值主張獲得了巨大的成功。
隨著使用者越來越註重價格，發現這些現成解決方案的成本相對較高且不可預測，與它們帶來的價值相比，成本高效且可預測的日誌儲存，其中查詢效能是可以接受的，比以往任何時候都更有價值。
在這篇文章中，我們介紹了CGW堆疊（ClickHouse、Grafana、WarpStream或「不會錯」），並演示了當與儲存和計算分離相結合時，對典型日誌數據的壓縮率超過10倍的優勢，使得ClickHouse Cloud開發層例項可以舒適地承載超過1.5TiB的日誌數據（假設列數與我們的樣本數據相似，大約為50億行）：將其壓縮到不到100GiB。一個完全並列化的查詢執行引擎，結合低階別的最佳化，確保對這些數據量上的大多數典型SRE查詢的查詢效能保持在1秒以下，正如我們的基準所示。
在我們的基準測試中，透過多達14倍的壓縮比，這個集群（允許高達1TiB的壓縮數據）潛在地可以儲存高達14TiB的未壓縮日誌數據。使用者可以利用這些多余的容量進一步增加儲存密度，如果查詢效能不是關鍵問題，也可以簡單地將其用於延長數據保留時間。我們展示了與其他解決方案相比的巨大節省，例如Elastic和Datadog，對於相同的數據量，它們的成本是原來的23倍到42倍。
雖然ClickHouse可以作為一個獨立的日誌儲存引擎使用，但我們意識到使用者通常更喜歡一種架構，即數據在插入ClickHouse之前首先在Kafka中進行緩沖。這提供了許多好處，主要是在吸收流量峰值的同時保持對ClickHouse的插入負載恒定，並允許將數據轉發到其他下遊系統。在我們提出的架構中，希望盡可能降低成本和操作，我們考慮了一個Kafka實作，也將儲存和計算分開：WarpStream。我們將其與我們的標準建議一起使用，即用於日誌收集的OTEL和用於視覺化的Grafana。
為什麽選擇ClickHouse？
作為高效能的OLAP資料庫，ClickHouse用於許多用例，包括時間序列數據的實分時析。它的多樣化的用例幫助推動了大量的分析功能，這些功能有助於查詢大多數數據型別。這些查詢功能和由於列式設計和可自訂編解碼器而產生的非常高的壓縮率，越來越多地導致使用者選擇ClickHouse作為日誌數據儲存。透過分離儲存和計算，並利用物件儲存作為其主要數據儲存，ClickHouse Cloud進一步提高了這種成本效益。
盡管我們過去通常看到大型CDN提供商使用ClickHouse來儲存日誌，但隨著日誌解決方案的成本越來越受關註，我們現在越來越多地看到中小型企業也在考慮將ClickHouse作為日誌儲存替代方案。
什麽是WarpStream？
WarpStream是一個與Apache Kafka®協定相容的數據流平台，可以直接執行在任何商品物件儲存上。與ClickHouse一樣，WarpStream是從頭開始設計用於分析用例，並盡可能成本有效地管理大量機器生成的數據流。
WarpStream沒有Kafka代理，而是有「代理」。代理是無狀態的Go二進制檔（沒有JVM！），可以使用Kafka協定，但與傳統的Kafka代理不同，任何WarpStream代理都可以作為任何主題的「領導者」，為任何消費者組送出偏移量，或者作為集群的協調者。沒有一個代理是特殊的，所以根據CPU使用率或網路頻寬來自動擴充套件它們是微不足道的。
這是由於WarpStream將計算與儲存以及數據與後設資料分開。每個WarpStream「虛擬集群」的後設資料儲存在一個客製的後設資料資料庫中，該資料庫是從頭開始編寫的，以最有效和最具成本效益的方式解決這個確切的問題。
WarpStream使用物件儲存作為主要且唯一的儲存層，沒有本地磁盤，這使得與其他Apache Kafka實作相比，它在分析數據方面表現得更加突出。
具體來說，WarpStream使用物件儲存作為儲存層和網路層，完全避免了區域間頻寬成本，而這些費用往往可以輕松占據傳統Apache Kafka實作的總成本的80%。此外，代理的無狀態性使得將工作負載擴充套件到每秒多GB的數據是切實可行的（甚至容易）。
這些內容使得WarpStream非常適合日誌記錄解決方案，其中吞吐量往往相當大，價格敏感性至關重要，並且幾秒鐘的交付延遲是完全可以接受的。
對於希望部署WarpStream進行測試的使用者，可以按照這些說明在Fly.io上部署測試集群，也可以按照這些說明在Railway上部署。
ClickHouse Cloud開發層
ClickHouse Cloud允許使用者將ClickHouse部署為儲存和計算分離的服務。雖然使用者可以控制為生產層分配的CPU和記憶體，或者允許其在不使用時自動動態擴充套件，但開發層為我們的成本效益日誌儲存提供了理想的解決方案。建議將儲存限制為1TiB，計算限制為4個CPU和16 GiB的記憶體，此例項型別的價格不能超過193美元/月（假設使用了全部1TiB）。對於其他用例，由於服務在不使用時可以處於空閑狀態，因此成本通常低於此。我們假設持續的日誌攝取的性質使這不可行。盡管如此，對於需要儲存高達14TiB原始日誌數據的使用者來說，此服務非常理想，考慮到ClickHouse實作的預期14倍壓縮比。
請註意，開發層與生產層相比使用了較少數量的復制節點 - 2個而不是3個。這種可用性水平對於日誌記錄用例來說也足夠，其中復制因子為2通常足以滿足SLA要求。最後，壓縮數據的有限儲存量允許開發一個簡單的成本模型，我們將在下面介紹。
範例數據集
為了為ClickHouse Cloud中的日誌記錄用例基準測試開發層例項，我們需要一個代表性數據集。為此，我們使用了一個公開可用的Web伺服器存取日誌數據集。雖然這個數據集的模式很簡單，但它等同於常見的nginx和Apache日誌。
54.36.149.41 - - [22/Jan/2019:03:56:14 +0330] "GET /filter/27|13 مگاپیکسل,27|کمتر از 5 مگاپیکسل,p53 HTTP/1.1"20030577"-""Mozilla/5.0 (compatible; AhrefsBot/6.1; +http://ahrefs.com/robot/)""-"31.56.96.51 - - [22/Jan/2019:03:56:16 +0330] "GET /image/60844/productModel/200x200 HTTP/1.1"2005667"https://www.zanbil.ir/m/filter/b113""Mozilla/5.0 (Linux; Android 6.0; ALE-L21 Build/HuaweiALE-L21) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.158 Mobile Safari/537.36""-"31.56.96.51 - - [22/Jan/2019:03:56:16 +0330] "GET /image/61474/productModel/200x200 HTTP/1.1"2005379"https://www.zanbil.ir/m/filter/b113""Mozilla/5.0 (Linux; Android 6.0; ALE-L21 Build/HuaweiALE-L21) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.158 Mobile Safari/537.36""-"
這個3.5GiB的數據集包含大約1000萬行日誌，並涵蓋2019年的4天。更重要的是，列的基數和數據的周期性模式代表了真實數據。利用一個公開可用的指令碼，我們已將此數據集轉換為CSV*以簡化插入。各個檔的大小保持可比。下面顯示了生成的ClickHouse模式：
CREATETABLElogs(`remote_addr`String,`remote_user`String,`runtime` UInt64,`time_local` DateTime,`request_type`String,`request_path`String,`request_protocol`String,`status` UInt64,`size` UInt64,`referer`String,`user_agent`String)ENGINE = MergeTreeORDERBY (toStartOfHour(time_local), status, request_path, remote_addr)
這代表了一個樸素的、非最佳化的模式。在我們的測試中，還有可能進行進一步的最佳化，可以提高壓縮率約5%。但上述模式代表了新使用者的入門體驗。因此，我們測試的是最不利的配置。可以在這裏找到替代方案，展示了壓縮的變化。
我們已復制了這些數據，以涵蓋一個月的時間，以便我們可以預測更典型的保留間隔。雖然這會導致固有數據模式的重復，但這被認為對我們的測試足夠，並且類似於日誌記錄用例中看到的典型的每周周期性。
本月的封包括 6600 萬行和 20GiB 的原始 CSV/log 數據。為了復制這些數據以進行更大規模的測試並保持其數據內容，我們使用了一種簡單的技術。與其簡單地復制數據，我們將現有數據與一個順序已被隨機化的副本進行合並。這涉及一個簡單的指令碼，逐行叠代遍歷兩個授權檔和隨機化檔。來自隨機化檔和授權檔的行被復制到目的檔中。兩者的「配對行」都被分配了授權檔中的日期。這確保了上面顯示的周期模式得以保留。這與簡單地復制行形成對比，簡單地復制行會導致重復的行相鄰放置。這會有利於壓縮並提供不公平的比較 - 隨著數據的復制而惡化。下面，我們展示了使用上述技術復制的相同數據，分別為 1.33 億、5.34 億和 10 億行日誌。
載入日誌數據使用ClickPipes - 不到一分鐘的數據管道
用於我們基準測試的所有檔都可在S3儲存桶
s3://datasets-documentation/http_logs/
中下載，以允許使用者復制測試。這些數據以CSV格式提供方便。對於希望將這些數據載入到代表性環境中的使用者，我們提供了以下實用程式。這將數據推播到WarpStream例項，如下所示。
clickpipes -broker $BOOTSTRAP_URL -username $SASL_USERNAME -password $SASL_PASSWORD -topic $TOPIC -file data-66.csv.gzwrote 0 records in 3.5µs, rows/s: 0.000000generated schema: [time_local remote_addr remote_user runtime request_type request_path request_protocol status size referer user_agent]wrote 10000 records in 63.2115ms, rows/s: 158198.854156wrote 20000 records in 1.00043025s, rows/s: 19991.397861wrote 30000 records in 2.000464333s, rows/s: 14996.517996wrote 40000 records in 3.000462042s, rows/s: 13331.279947wrote 50000 records in 4.000462s, rows/s: 12498.556286
消費WarpStream中的數據，使用者可以反過來使用ClickPipes，ClickHouse Cloud的本地攝取工具，將這些數據插入到ClickHouse中。我們在下面進行演示。
對於只想對ClickHouse進行測試的使用者，可以使用單個命令從ClickHouse客戶端載入範例數據檔，如下所示。
INSERTINTOlogsFROMINFILE'data-66.csv.gz'FORMAT CSVWithNames
壓縮
為了評估ClickHouse的儲存效率，我們展示了上述數據集中日誌事件數量增延長表的未壓縮和壓縮大小。這裏的未壓縮大小可以類比為CSV或原始日誌格式中的原始數據量（雖然略小）。
SELECTtable, formatReadableQuantity(sum(rows)) AS total_rows, formatReadableSize(sum(data_compressed_bytes)) AS compressed_size, formatReadableSize(sum(data_uncompressed_bytes)) AS uncompressed_size,round(sum(data_uncompressed_bytes) / sum(data_compressed_bytes), 2) AS ratioFROM system.partsWHERE (tableLIKE'logs%') AND activeGROUPBYtableORDERBYsum(rows) ASC┌─table─────┬─total_rows─────┬─compressed_size─┬─uncompressed_size─┬─ratio─┐│ logs_66 │ 66.75 million │ 1.27 GiB │ 18.98 GiB │ 14.93 ││ logs_133 │ 133.49 million │ 2.67 GiB │ 37.96 GiB │ 14.21 ││ logs_267 │ 266.99 million │ 5.42 GiB │ 75.92 GiB │ 14 ││ logs_534 │ 533.98 million │ 10.68 GiB │ 151.84 GiB │ 14.22 ││ logs_1068 │ 1.07 billion │ 20.73 GiB │ 303.67 GiB │ 14.65 ││ logs_5340 │ 5.34 billion │ 93.24 GiB │ 1.48 TiB │ 16.28 │└───────────┴────────────────┴─────────────────┴───────────────────┴───────┘
我們的壓縮比約為14倍，不論數據量如何增加，都保持不變。我們的最大數據集，包含超過50億行和1.5TiB的未壓縮數據，具有更高的壓縮率。我們將這歸因於由於最初的樣本大小僅為1000萬行而導致的數據中更多的重復。請註意，透過進一步的模式最佳化，可以使磁盤上的數據總大小提高約5%。
重要的是，即使是我們最大的數據集也消耗不到我們開發服務儲存的10%，不到100GiB。如果需要，使用者可以以極小的成本增加保留時間達十個月（見下文的成本分析）。
視覺化日誌數據
對於視覺化，我們建議使用Grafana和官方的ClickHouse外掛程式。為了在代表性查詢負載下評估ClickHouse的效能，我們利用以下儀表板。這包含7個視覺化，每個都使用各種聚合：
顯示隨時間變化的日誌的折線圖
顯示總入站IP地址的指標
顯示存取的前5個網站路徑的條形圖
多線圖顯示隨時間變化的狀態程式碼
多線圖顯示隨時間變化的平均和第99個響應時間
每種HTTP請求型別傳輸的數據量作為條形圖
按計數排列的頂部IP地址的條形圖
每個視覺化背後的完整查詢可以在此找到。 （https://github.com/ClickHouse/simple-logging-benchmark/tree/main/queries）
然後，我們將此儀表板送出給一系列使用者下鉆，以復制使用者診斷特定問題的情況。我們捕獲結果查詢，並將其用於下面的基準測試。下面顯示了操作序列。所有篩選器是累積的，因此復制了使用者逐步操作的過程：
開啟儀表板，檢視最近6小時的數據。
透過過濾404狀態碼（即 status=404 ）來尋找錯誤。
透過為 request_path 添加額外的篩選器來隔離錯誤。
透過使用 remote_addr 列篩選到特定IP來隔離受影響的使用者。
透過記錄響應時間超過4秒的存取來評估SLA違規情況。
縮小到一個月的數據，以辨識隨時間變化的模式。
盡管這些行為是人為的，沒有特定的事件，但它們旨在模擬SRE使用集中式日誌記錄解決方案的典型使用模式。可以在這裏找到完整的結果查詢。
（https://github.com/ClickHouse/simple-logging-benchmark/tree/main/queries）
下面，我們評估了這些查詢在不斷增加的日誌量下的效能。
查詢效能
在該儀表板中包含7個圖表和6個下鉆功能，總共觸發了42次查詢。這些查詢按照使用者使用儀表板的方式執行，即同時執行7個查詢，並啟用相應的下鉆功能。在執行任何查詢負載之前，我們都會確保清空所有緩存（包括檔案系統緩存）。每個查詢會執行3次。下面我們列出了不斷增加的數據量下的平均效能，但完整結果可以在此找到。
所有測試均可使用此儲存庫中提供的指令碼進行復現。下面我們展示了不斷增加的日誌量下的平均效能、95th 和 99th 百分位的效能。
| Rows (millions) | Uncompressed data (GiB) | 95th | 99th | Average |
|---|---|---|---|---|
| 66.75 | 18.98 | 0.36 | 0.71 | 0.1 |
| 133.5 | 37.96 | 0.55 | 1.04 | 0.14 |
| 267 | 75.92 | 0.78 | 1.72 | 0.21 |
| 534 | 151.84 | 1.49 | 3.82 | 0.4 |
| 1095.68 | 303.67 | 5.18 | 8.42 | 1.02 |
| 5468.16 | 1515.52 | 31.05 | 47.46 | 5.48 |
平均效能在所有查詢中保持在1秒以下，直到10億行。如圖所示，隨著數據量增加，大多數查詢的效能並沒有明顯下降，這要歸功於ClickHouse的稀疏索引，表現比線性更好。
更高的百分位數可以歸因於冷查詢，在我們的基準測試中沒有預熱時間。如下圖所示，這些較慢的查詢也與我們最後的下鉆行為相關聯，其中我們將數據視覺化超過30天。這種存取型別通常不頻繁，SRE更專註於較短的時間範圍。盡管如此，即使在我們的最大測試中（1.5TiB），平均效能也保持在6秒以下。
下面，我們展示了不同下鉆和數據量的儀表板視覺化的平均效能。
在6600萬行或19GB數據時，所有查詢的效能平均在0.1秒以下。
將數據量增加4倍後，26700萬行或76GB的效能保持與先前的測試相當。盡管數據增加，所有查詢的效能仍然可比。
如果我們將數據量進一步增加4倍至300GB或約10億行，則所有查詢的效能平均保持在1秒以下。
對於最後的測試，我們將容量增加到1.5TiB的未壓縮數據或53億行。與開啟儀表板時相關的查詢（在此期間僅套用了時間以外的篩選器）是最慢的查詢，大約為1.5到3秒。所有涉及下鉆的查詢都在1秒內輕松完成。
敏銳的讀者會註意到，我們上面沒有包含最後一組查詢的效能，這些查詢與使用者「縮小」以覆蓋整個月份相關聯。這些是最昂貴的查詢，其時間會扭曲上面的圖表。因此，我們在下面單獨呈現這些查詢的結果。
如圖所示，此操作的效能嚴重取決於所查詢數據的量，直到較大的1.5TiB負載，效能平均保持在5秒以下。我們預計這些查詢，涵蓋全數據集，將不頻繁，並且不是常規SRE工作流程的典型部份。但是，即使這些查詢很少，我們可以采取措施利用ClickHouse功能來提高其效能。我們將在下文中探討這些措施，以更大的數據集為背景。
提高查詢效能
以上結果顯示，我們大多數儀表板查詢的效能平均在幾秒鐘以下。我們的「放大」查詢，其中我們的 SRE 試圖在整個月份內辨識趨勢，最多需要 50 秒。雖然這不是完全的線性掃描，因為我們仍然在套用過濾器，但這個特定的查詢受到 CPU 的限制，因為我們的開發服務中的每個節點只有兩個核心。預設情況下，查詢僅在查詢的接收節點上執行。因此，這些查詢將從在集群中分配計算，使得四個核心被分配給聚合。
在 ClickHouse Cloud 中，可以透過使用並列副本來實作這一點。此功能允許聚合查詢的工作在集群中的所有節點之間分布，從同一單個分片讀取。盡管這個功能目前還處於試驗階段，但在 ClickHouse Cloud 中的一些工作負載中已經在使用，並且預計將很快普遍提供。
下面，我們展示了當並列副本被啟用時，如何使用完整的集群資源執行作為最終放大步驟的所有查詢的結果。這些結果是針對 1.5TiB 的最大數據集的。完整的結果可以在這裏找到。 （https://github.com/ClickHouse/simple-logging-benchmark/blob/main/results/parallel_replicas.md）
| simple count over time | count by status over time | unique count of remote_addr | request_path by count | remote_addr by count | average and 99th percentile response time transferred over time | total bytes transferred by request_type | |
|---|---|---|---|---|---|---|---|
| With Parallel Replicas | 24.8 | 10.81 | 10.84 | 9.74 | 9.75 | 9.31 | 8.89 |
| No Parallel Replicas | 52.46 | 31.35 | 40.26 | 20.41 | 15.14 | 25.29 | 23.2 |
| Speedup | 2.12 | 2.9 | 3.71 | 2.1 | 1.55 | 2.72 | 2.61 |
如圖所示，啟用並列副本將我們的查詢平均加速了2.5倍。這確保了我們的查詢最多在24秒內響應，大多數在10秒內完成。請註意，根據我們的測試，只有當需要聚合大量行時，並列副本才能提供好處。對於其他較小的數據集，分發的成本超過了好處。在ClickHouse的未來版本中，我們計劃使此功能的使用更加自動化，而不是依賴使用者根據數據量手動套用適當的設定。
成本分析
ClickHouse
利用ClickHouse Cloud的開發層的成本主要由計算單元主導，另外還有儲存的額外費用。相對而言，由於ClickHouse雲中使用了物件儲存，因此此工作負載的儲存成本很小。因此，鼓勵使用者在不擔心累積成本的情況下延長數據保留時間。
每小時0.2160美元。假設我們的服務始終處於活動狀態，這大約是0.2160美元 x 24 x 30 = 155.52美元
每月壓縮數據每TiB 35.33美元
基於此，我們可以使用簡單的計算來估算我們對早期數據量的成本。
| Uncompressed size (GiB) | Compressed size (GiB) | Number of rows (millions) | Retain cost (1 month) for compute ($) | Storage cost ($) | Total Cost per month ($) |
|---|---|---|---|---|---|
| 18.98 | 1.37 | 66.75 | 155.52 | 0.05 | 155.57 |
| 37.96 | 2.96 | 133.49 | 155.52 | 0.1 | 155.62 |
| 75.92 | 5.42 | 267 | 155.52 | 0.19 | 155.71 |
| 151.84 | 10.68 | 534 | 155.52 | 0.37 | 155.89 |
| 303.67 | 20.73 | 1070 | 155.52 | 0.72 | 156.24 |
| 1515.52 | 93.24 | 5370 | 155.52 | 3.22 | $158.74 |
| 14336 | 1024 | 58976 | 155.52 | 35.33 | $190.85 |
如前所述，這裏的未壓縮大小可以被視為CSV和非結構化格式的原始日誌格式的等效。顯然，我們這裏的儲存成本是很小的，對於我們最大的測試案例，即包含1.5TiB未壓縮數據的情況，只需3美元。
上表中的最後一行將展示如果我們利用開發層提供的全部1TiB壓縮儲存空間的成本。這可以透過延長數據的保留時間或增加每月的數據量來實作，這相當於超過580億行數據和14TiB未壓縮日誌。這仍然只需要每月190美元。由於物件儲存成本低廉，這僅比儲存我們最大的1.5TiB未壓縮測試案例多出32美元！
WarpStream
WarpStream的定價工作更簡單，沒有復雜的查詢需要執行。在這種情況下，WarpStream充當了一種成本高效且可延伸的緩沖區。我們假設在傳輸過程中的壓縮比為4倍，因為數據不是以列形式組織的，並且客戶端可能會根據其配置生成或消耗小批次數據。最後，我們還假設48小時的保留時間足夠，因為WarpStream只是作為ClickHouse前的臨時緩沖區，而不是最終目的地。以下是完整14TiB數據的成本。
| Uncompressed Size (GiB) | Throughput MiB/s | Compute cost for agent($) | Storage cost (2 days) ($) | S3 API Costs | Total Cost per month ($) |
|---|---|---|---|---|---|
| 18.98 | 1.8Kib/s | $21.4 | $0.007 | $58 | $80 |
| 37.96 | 3.6KiB/s | $21.4 | $0.014 | $58 | $80 |
| 75.92 | 7KiB/s | $21.4 | $0.028 | $58 | $80 |
| 151.84 | 14KiB/s | $21.4 | $0.057 | $58 | $80 |
| 303.67 | 29KiB/s | $21.4 | $0.116 | $58 | $80 |
| 1515.52 | 146KiB/s | $21.4 | $0.58 | $58 | $80 |
| 14336 | 1.38 MiB/s | $21.4 | $5.49 | $58 | $85 |
上面使用了 Fly.io 2x shared-cpu-1x，配備了 2GiB 的 RAM。
需要註意的是，WarpStream 計算和 S3 API 成本相對來說是「固定」的成本，工作負載的大小可以進一步增長 5-10 倍，而這兩項成本都不會增加。這是因為我們至少需要執行兩個代理以確保高可用性。然而，即使在這個設定中使用的兩個小代理也可以輕松容忍每秒 10-20MiB 的寫入量，這比最高行的數量要大一個數量級。因此，計算成本保持不變。
此外，S3 API 成本也基本上是固定的，因為代理必須每 250 毫秒生成一個檔，無論負載如何。然而，隨著寫入量的增加，批次處理也會增加，直到工作負載的總寫入吞吐量超過每個檔的最大攝入大小（8MiB）之前，成本都保持不變。
總結
以下是 CGW 堆疊在各種日誌容量下的每月總成本。
| Uncompressed size (GiB) | WarpStream cost per month ($) | ClickHouse cost per month ($) | Total cost ($) |
|---|---|---|---|
| 18.98 | 80 | 155.57 | 235.57 |
| 37.96 | 80 | 155.62 | 235.62 |
| 75.92 | 80 | 155.71 | 235.71 |
| 151.84 | 80 | 155.89 | 235.89 |
| 303.67 | 80 | 156.24 | 236.89 |
| 1515.52 | 80 | 158.74 | 238.74 |
| 14336 | 85.43 | 190.85 | 276.28 |
上述成本不包括 OTEL 收集器（或等效物）的成本，我們假設這些收集器將在邊緣執行，並且代表著可以忽略的開銷。
成本比較
為了提供一些相對比較的元素，我們決定將我們的 CGW 堆疊的成本與日誌領域的兩個領先解決方案進行比較，即 Datadog 和 Elastic Cloud。
讀者應記住，我們在這裏並不進行完全一致的蘋果對蘋果比較，因為 Elastic 和 Datadog 都提供了除主要儲存/查詢功能以外的全面日誌使用者體驗。另一方面，所呈現的兩個替代解決方案都不包括 Kafka 或與 Kafka 相容的排隊機制。
然而，從功能的角度來看，主要目標是相同的，而 CGW 對於核心日誌使用案例來說是一個有效的替代方案。我們根據公開可用的定價小算盤數據和以下假設在下表中顯示了成本差異：
每月 CGW 成本：包括上述 Warpstream 和 ClickHouse Cloud 的成本，並假設使用 Grafana Cloud 免費版例項。
每月 Elastic Cloud 成本：假設執行在通用硬體配置檔上的 Elastic 標準層（最低層），具有 2 個可用性區域和 1 個免費的 Kibana 例項。我們還假設數據的壓縮比為 1:1。
每月 Datadog 成本：假設僅有 30 天的保留期，並且有一年的承諾期（30 天是 datadoghq.com/pricing 上公開價格列出的最高周期）。
此外，所呈現的兩個替代解決方案都不包括必須單獨部署和評估的 Kafka 或與 Kafka 相容的排隊機制的成本。我們放棄了替代解決方案的這部份成本。
| Uncompressed size (GiB) | Compressed size (GiB) | Number of rows (millions) | CGW Cost Per Month ($) | Elastic Cloud Cost Per Month ($) | Elastic Cloud / CGW multiple | Datadog Cost Per Month ($) | Datadog / CGW multiple |
|---|---|---|---|---|---|---|---|
| 18.98 | 1.37 | 66.75 | 241 | $82 | x 0.3 | $143 | x 0.6 |
| 37.96 | 2.96 | 133.49 | 241.05 | $82 | x 0.3 | $143 | x 0.6 |
| 75.92 | 5.42 | 267 | 241.14 | $131 | x 0.5 | $234 | x 1.0 |
| 151.84 | 10.68 | 534 | 241.32 | $230 | x 1.0 | $415 | x 1.7 |
| 303.67 | 20.73 | 1070 | 241.67 | $428 | x 1.8 | $776 | x 3.2 |
| 1515.52 | 93.24 | 5370 | 244.17 | $3,193 | x 13.1 | $5,841 | x 23.9 |
| 14336 | 1024 | 58976 | 276.28 | $6,355 | x 23.0 | $11,628 | x 42.1 |
如上所示，對於任何小型工作負載（<150 GiB 未壓縮數據），CGW 堆疊幾乎固定的成本並不合理，而替代解決方案更具吸重力。然而，一旦超過這個閾值，我們很快就會觀察到成本增長速度高於替代解決方案管理的數據量，對於 1.5 TiB 的日誌數據，達到了 Elastic Cloud 的 23 倍和 Datadog 的 42 倍。
基於上述結果，我們得出結論，CGW 堆疊提供了一種成本效益高的替代方案，可以輕松擴充套件到多 TB 規模，而不會增加成本。成本的可預測性為那些預計系統增長並希望避免未來出現意外的使用者提供了明顯的優勢。在超過這個規模之後，使用者總是可以決定升級到生產級別的 ClickHouse Cloud 服務，以跟上不斷增長的數據量。我們預計在這種情況下的成本節省將更加可觀，正如大型 CDN 提供商使用 ClickHouse 儲存日誌所證明的那樣。
除了成本效益之外，擁有完全成熟的現代分析儲存意味著您可以將用例擴充套件到基本的日誌儲存和檢索之外，從 ClickHouse 充滿活力的整合生態系中獲益。一個例子是，您可以決定使用 S3 表函式將大量日誌以 Parquet 格式儲存在遠端物件儲存桶中，以進行存檔，從而擴充套件您的保留能力。
結論
在本文中，我們介紹了 CGW 堆疊，這是一個基於 ClickHouse Cloud、WarpStream 和 Grafana 的日誌解決方案。如果使用 ClickHouse Cloud 開發服務，這個堆疊為每月儲存高達 14TiB 未壓縮數據提供了一種高效的方式，成本不到 300 美元。這比可比較的 Elastic Cloud 部署要高出 23 倍，比同等數據量的 DataDog 要便宜多達 42 倍。
Meetup 活動報名通知
好訊息： ClickHouse Chengdu User Group第1屆 Meetup 已經開放報名了，將於2024年4月13日在 成都市雙流區華陽鎮街道梓州大道6288號成都OPPO大廈18層1801會議室 舉行，掃碼免費報名
征稿啟示
面向社群長期正文，文章內容包括但不限於關於 ClickHouse 的技術研究、計畫實踐和創新做法等。建議行文風格幹貨輸出&圖文並茂。品質合格的文章將會釋出在本公眾號，優秀者也有機會推薦到 ClickHouse 官網。請將文章稿件的 WORD 版本發信件至： [email protected]
