HighLoad++ 莫斯科 2018 年，國會大廳。 9月15日 00:XNUMX
摘要與示範：
Yuri Nasretdinov（VKontakte）：報告會講我們公司實施ClickHouse的經驗——為什麼我們需要它，我們儲存了多少數據，我們如何編寫等等。
其他材料：
尤里‧納斯雷迪諾夫： - 大家好！ 我的名字是尤里·納斯雷迪諾夫（Yuri Nasretdinov），正如我已經被介紹過的那樣。 我在 VKontakte 工作。 我將討論如何將資料從我們的伺服器群組（數萬）插入 ClickHouse 中。
什麼是日誌以及為什麼要收集它們？
我們將告訴您什麼：我們做了什麼，為什麼我們需要“ClickHouse”，為什麼我們選擇它，在不進行任何特殊配置的情況下您大約可以獲得什麼樣的性能。 我將進一步告訴您有關緩衝表的資訊、我們遇到的問題以及我們從開源開發的解決方案 - KittenHouse 和 Lighthouse。
為什麼我們需要做任何事情（VKontakte 上一切都很好，對吧？）。 我們想要收集調試日誌（那裡有數百 TB 的數據），也許不知何故計算統計數據會更方便； 我們擁有一支由數萬台伺服器組成的艦隊，所有這些工作都需要透過它們來完成。
我們為什麼決定？ 我們可能有儲存日誌的解決方案。 這裡——有這樣一個公共的「後端VK」。 我強烈建議訂閱它。
什麼是日誌？ 這是一個傳回空數組的引擎。 VK 中的引擎就是其他人所說的微服務。 這是一個微笑的貼紙（很多人喜歡）。 為何如此？ 嗯，再聽聽！
可以用什麼來儲存日誌？ 不能不提哈杜普。 然後，例如Rsyslog（將這些日誌儲存在文件中）。 迷幻藥。 誰知道LSD是什麼？ 不，不是這種LSD。 也分別儲存文件。 嗯，ClickHouse 是一個奇怪的選擇。
Clickhouse 和競爭對手：要求和機會
我們想要什麼？ 我們希望確保不必過多擔心操作，以便它開箱即用，最好使用最少的配置。 我們想寫很多，而且寫得很快。 我們希望將其保留數月、數年，即很長一段時間。 我們可能想了解一些問題，他們來找我們並說“這裡有些東西不起作用”，那是 3 個月前的事了），我們希望能夠看到 3 個月前發生了什麼“ 資料壓縮——很明顯為什麼它會是一個優點——因為它減少了佔用的空間量。
我們有一個這樣有趣的需求：我們有時會寫入一些指令的輸出（例如日誌），它很容易就超過 4 KB。 如果這個東西透過 UDP 工作，那麼它就不需要花費......它不會有任何連接的“開銷”，對於大量伺服器來說，這將是一個優點。
讓我們看看開源為我們提供了什麼。 首先，我們有日誌引擎──這是我們的引擎； 原則上，他可以做任何事情，甚至可以寫長行。 好吧，它不會透明地壓縮資料 - 如果我們願意，我們可以自己壓縮大列......當然，我們不想（如果可能的話）。 唯一的問題是，他只能給出適合他記憶的內容； 要閱讀其餘部分，您需要取得該引擎的binlog，因此需要相當長的時間。
還有哪些其他選擇？ 例如，「哈杜普」。 易於操作...誰認為 Hadup 很容易設定？ 當然，錄音是沒有問題的。 閱讀時，有時會產生疑問。 原則上，我會說可能不會，特別是對於日誌。 長期儲存——當然，是的，資料壓縮——是的，長字串——很明顯你可以記錄。 但大量伺服器的錄影…你還是得自己做點什麼！
Rsyslog。 事實上，我們將它用作備份選項，以便我們可以在不轉儲 binlog 的情況下讀取它，但它不能寫入長行；原則上，它不能寫入超過 4 KB。 您必須自己以同樣的方式進行資料壓縮。 讀取將來自檔案。
然後是 LSD 的“badushka”開發。 本質上與“Rsyslog”相同：它支援長字串，但它不能通過 UDP 工作，事實上，不幸的是，因此，很多東西需要在那裡重寫。 LSD 需要重新設計，以便能夠從數萬台伺服器進行記錄。
和這裡！ 一個有趣的選擇是 ElasticSearch。 怎麼說？ 他閱讀做得很好，也就是說，他讀得很快，但寫作不太好。 首先，如果它壓縮數據，它的強度就非常弱。 最有可能的是，完整搜尋需要比原始磁碟區更大的資料結構。 操作起來比較困難，而且常常會出現問題。 再說一次，在 Elastic 中錄製 - 我們必須自己做所有事情。
這裡 ClickHouse 當然是個理想的選擇。 唯一的問題是從數萬台伺服器進行記錄是一個問題。 但至少有一個問題，我們可以嘗試以某種方式解決它。 報告的其餘部分就是關於這個問題的。 您對 ClickHouse 有何期望？
我們要如何插入它？ 合併樹
你們當中誰沒有聽過或不知道「ClickHouse」？ 我需要告訴你，不是嗎？ 非常快。 那裡的插入- 每秒1-2 GB，每秒高達10 GB 的突發實際上可以承受這種配置- 有兩個6 核Xeon（也就是說，甚至不是最強大的），256 GB RAM， 20 TB在 RAID 中（未配置，預設）。 ClickHouse 開發人員 Alexey Milovidov 可能坐在那裡哭泣，因為我們沒有配置任何東西（一切對我們來說都是如此）。 因此，如果資料被很好地壓縮，則可以獲得每秒約6億行的掃描速度。 如果您確實喜歡文字字串上的 % - 每秒 100 億行，也就是說，它看起來相當快。
我們要如何插入它？ 嗯，您知道 VK 使用 PHP。 我們將透過 HTTP 將每個 PHP 工作執行緒插入「ClickHouse」中的每筆記錄的 MergeTree 表中。 誰認為這個方案有問題？ 由於某些原因，並不是每個人都舉手了。 讓我告訴你。
首先，有很多伺服器 - 因此，會有很多連接（不好）。 那麼向 MergeTree 插入資料的頻率最好不要超過每秒一次。 誰知道為什麼？ 好吧好吧。 我會告訴你更多關於這一點的資訊。 另一個有趣的問題是，我們不做分析，我們不需要豐富數據，我們不需要中間伺服器，我們想要直接插入「ClickHouse」（最好 - 越直接越好）。
那麼，MergeTree 中的插入是如何完成的呢？ 為什麼插入頻率最好不要超過每秒一次或更少？ 事實上，「ClickHouse」是一個列式資料庫，按主鍵升序對資料進行排序，當您進行插入時，會建立至少等於資料排序的列數的檔案數量按主鍵的升序排列（建立一個單獨的目錄，每次插入都會在磁碟上建立一組檔案）。 然後下一個插入到來，並在後台將它們組合成更大的“分區”。 由於資料是排序的，因此可以「合併」兩個排序的檔案而不消耗太多記憶體。
但是，正如你可能猜到的，如果你每次插入都寫10個文件，那麼ClickHouse（或你的伺服器）很快就會結束，所以建議大批量插入。 因此，我們從未將第一個方案投入生產。 我們立即推出了一個，這裡的第二個有：
這裡想像一下，我們啟動了大約一千台伺服器，只有 PHP。 每台伺服器上都有我們的本地代理，我們稱之為“Kittenhouse”，它與“ClickHouse”保持一個連接，並每隔幾秒鐘插入資料。 不將資料插入 MergeTree 中，而是插入到緩衝表中，這正是為了避免立即直接插入 MergeTree 中。
使用緩衝表
這是什麼？ 緩衝表是一塊被分片的記憶體（即可以頻繁地插入其中）。 它們由多個片段組成，每個片段都作為一個獨立的緩衝區，並且它們被獨立地刷新（如果緩衝區中有很多片段，那麼每秒會有很多插入）。 可以從這些表中讀取 - 然後您讀取緩衝區和父表內容的並集，但此時寫入被阻止，因此最好不要從那裡讀取。 而且緩衝表顯示出非常好的QPS，也就是說，高達3QPS你在插入時根本不會有任何問題。 顯然，如果伺服器斷電，那麼資料可能會遺失，因為它僅儲存在記憶體中。
同時，具有緩衝區的方案使 ALTER 變得複雜，因為您首先需要使用舊方案刪除舊的緩衝表（資料不會在任何地方消失，因為在刪除表之前它會被刷新）。 然後你「改變」你需要的表並再次建立緩衝表。 因此，雖然沒有緩衝表，但您的資料不會流向任何地方，但您至少可以在本機將其保存在磁碟上。
Kittenhouse 是什麼以及它是如何運作的？
小貓屋是什麼？ 這是一個代理。 猜猜是什麼語言？ 我在報告中收集了最炒作的主題 - “Clickhouse”，走吧，也許我會記得別的東西。 是的，這是用 Go 寫的，因為我真的不知道如何用 C 寫，我不想。
因此，它與每個伺服器保持連接並可以寫入記憶體。 例如，如果我們將錯誤日誌寫入Clickhouse，那麼如果Clickhouse沒有時間插入資料（畢竟，如果寫入太多），那麼我們不會膨脹記憶體 - 我們只是扔掉其餘的。 因為如果我們每秒寫入幾千兆位元的錯誤，那麼我們可能會丟棄一些錯誤。 小貓屋可以做到這一點。 另外，它可以執行可靠的傳遞，即寫入本機上的磁碟，並且每次（每隔幾秒鐘一次）嘗試從該檔案傳遞資料。 起初我們使用常規的值格式 - 不是某種二進位格式，而是文字格式（如常規 SQL 中那樣）。
但後來發生了這樣的事。 我們使用可靠的交付，寫入日誌，然後決定（這是一個條件測試集群）...它被放置了幾個小時並重新啟動，並且從一千台伺服器開始插入 - 事實證明 Clickhouse 仍然有一個“連接上的線程” - 因此，在一千個連接中，主動插入會導致伺服器上的平均負載約為一千個。 令人驚訝的是，伺服器接受了請求，但過了一段時間資料仍然插入； 但是伺服器很難提供服務...
加入nginx
這種針對每個連接線程模型的解決方案是 nginx。 我們在Clickhouse前面安裝了nginx，同時設定了兩個副本的平衡（我們的插入速度提高了2倍，儘管事實並非如此），並限制了Clickhouse的連接數，限制了Clickhouse的連接數。上游，因此，超過50 個連接，似乎插入沒有意義。
然後我們意識到這個方案一般都有缺點，因為我們這裡只有一個nginx。 因此，如果這個 nginx 崩潰了，儘管存在副本，我們也會丟失數據，或者至少不會在任何地方寫入數據。 這就是我們自己進行負載平衡的原因。 我們也意識到「Clickhouse」仍然適合日誌，「惡魔」也開始在「Clickhouse」中寫他的日誌——說實話，非常方便。 我們仍然將它用於其他“惡魔”。
然後我們發現了這個有趣的問題：如果你使用非標準的 SQL 模式插入方法，它會強制使用成熟的基於 AST 的 SQL 解析器，這是相當緩慢的。 因此，我們添加了設定以確保這種情況永遠不會發生。 我們做了負載平衡、健康檢查，這樣如果有人死了，我們仍然會留下數據。 我們現在有相當多的表，我們需要有不同的 Clickhouse 群集。 我們也開始考慮其他用途 - 例如，我們想從 nginx 模組寫入日誌，但它們不知道如何使用我們的 RPC 進行通訊。 好吧，我想教他們如何至少以某種方式發送 - 例如，透過 UDP 在本地主機上接收事件，然後將它們轉發到 Clickhouse。
距離解決方案僅一步之遙
最終的方案開始看起來像這樣（該方案的第四個版本）：在Clickhouse前面的每台伺服器上都有nginx（在同一台伺服器上），它只是將請求代理到localhost，連接數限制為50件。 這個計劃已經很有效了，一切都很好。
我們就這樣生活了大約一個月。 大家都很高興，他們加表，他們加，他們加…總的來說，事實證明我們添加緩衝表的方式並不是很優化（就這麼說吧）。 我們在每張桌子上做了 16 件作品，閃光間隔為幾秒鐘； 我們有 20 個表，每個表每秒接收 8 次插入 - 此時「Clickhouse」開始......記錄開始變慢。 他們甚至沒有經過…預設情況下，Nginx 有一個非常有趣的事情，如果連線在上游終止，那麼它只會向所有新請求傳回「502」。
在這裡，我們（我剛剛查看了 Clickhouse 本身的日誌）大約有 XNUMX% 的請求失敗了。 因此，磁碟利用率很高，存在大量合併。 嗯，我做了什麼？ 當然，我沒有費心去弄清楚連結和上游到底為什麼結束。
用反向代理取代 nginx
我決定我們需要自己管理這個，我們不需要把它留給 nginx - nginx 不知道 Clickhouse 中有哪些表，我用反向代理替換了 nginx，這也是我自己寫的。
他在做什麼？ 它基於 fasthttp 庫“goshnoy”工作，即快，幾乎與 nginx 一樣快。 抱歉，Igor，如果您在場的話（註：Igor Sysoev 是一位俄羅斯程式設計師，創建了 nginx Web 伺服器）。 它可以理解這些是什麼類型的查詢 - INSERT 或 SELECT - 因此，它為不同類型的查詢持有不同的連接池。
因此，即使我們沒有時間完成插入請求，「選擇」也會通過，反之亦然。 它將數據分組到緩衝表中 - 帶有一個小緩衝區：如果有任何錯誤，語法錯誤等 - 這樣它們就不會極大地影響其餘數據，因為當我們簡單地插入到緩衝表中時，我們有小“八尺”，所有語法錯誤只影響這一小塊； 在這裡它們已經影響了一個大的緩衝區。 小就是1兆字節，也就是說，沒有那麼小。
插入同步並本質上替換 nginx，基本上與 nginx 之前所做的事情相同 - 您不需要為此更改本地“Kittenhouse”。 由於它使用 fasthttp，因此速度非常快 - 透過反向代理，您可以每秒發出超過 100 萬個請求來進行單次插入。 理論上，您可以一次向 kittenhouse 反向代理插入一行，但我們當然不會這樣做。
該方案開始看起來像這樣：“Kittenhouse”，反向代理將許多請求分組到表中，然後緩衝表將它們插入主表中。
Killer 是暫時的解決方案，Kitten 是永久的解決方案
這是一個有趣的問題...你們有人用過fasthttp嗎？ 誰將 fasthttp 與 POST 請求結合使用？ 也許，這確實不應該這樣做，因為它預設緩衝區請求正文，而我們的緩衝區大小設定為 16 MB。 插入在某個時刻停止了，16MB 的區塊開始從所有數萬台伺服器到達，它們在發送到 Clickhouse 之前都在記憶體中緩衝。 因此，記憶體耗盡，Out-Of-Memory Killer 來殺死反向代理（或“Clickhouse”，理論上可以“吃”比反向代理更多的東西）。 這個循環又重演了。 這不是一個令人愉快的問題。 儘管我們在運行幾個月後才偶然發現了這一點。
我做了什麼？ 再說一遍，我真的不太想了解到底發生了什麼事。 我認為很明顯你不應該緩衝到記憶體中。 儘管我嘗試過，但我無法修補 fasthttp。 但我找到了一種方法，這樣就不需要修補任何東西，並且我在 HTTP 中提出了自己的方法 - 我稱之為 KITTEN。 嗯，這是合乎邏輯的 - “VK”、“Kitten”...還有什麼？...
如果請求透過 Kitten 方法到達伺服器，那麼伺服器應該按邏輯回應「喵」。 如果他回應了這個，那麼就認為他理解這個協議，然後我攔截這個連接（fasthttp有這樣的方法），連接進入「raw」模式。 為什麼我需要它？ 我想控制從 TCP 連線讀取資料的方式。 TCP 有一個奇妙的功能：如果沒有人從另一端讀取數據，那麼寫入操作就會開始等待，並且記憶體不會特別消耗在這方面。
因此，我一次讀取大約50 個客戶的資訊（從20 個開始，因為XNUMX 個絕對應該足夠了，即使費率來自另一個DC）…透過這種方法，消耗量減少了至少XNUMX 倍，但說實話，我，我無法準確測量出什麼時間，因為它已經毫無意義了（已經達到了錯誤的程度）。 協定是二進制的，即包含表名和資料； 沒有 http 標頭，因此我沒有使用 Web 套接字（我不需要與瀏覽器通訊 - 我制定了一個適合我們需求的協定）。 他一切都變得很好。
緩衝表很悲傷
最近我們發現了緩衝表的另一個有趣的功能。 而且這個問題已經比其他問題痛苦得多了。 讓我們想像一下這種情況：您已經在積極使用Clickhouse，您有數十台Clickhouse伺服器，並且您有一些請求需要花費很長時間才能讀取（比方說，超過60秒）； 此時你來執行Alter...同時，在“Alter”之前開始的“selects”將不會包含在該表中，“Alter”將不會啟動 - 可能是“Clickhouse”如何工作的一些功能這個地方。 也許這可以解決？ 或者說這是不可能的？
一般來說，很明顯，實際上這並不是一個大問題，但對於緩衝表來說，它變得更加痛苦。 因為，如果，比方說，您的“Alter”超時（並且它可能在另一台主機上超時- 不是在您的主機上，而是在副本上，例如），那麼...您刪除了緩衝表，您的“Alter”（或其他主機）逾時。然後發生“Alter”錯誤） - 您仍然需要確保資料繼續寫入：您建立回緩衝表（根據與父表相同的方案），然後“Alter”經歷，最終結束，表的緩衝區開始在架構上與父表不同。 根據「改變」的內容，插入可能不再進入該緩衝表 - 這是非常可悲的。
還有這樣一個標誌（也許有人注意到了）－在新版的Clickhouse中叫做query_thread_log。 預設情況下，在某些版本中有一個。 我們在幾個月內累積了 840 億筆記錄（100 GB）。 這是因為“插入”被寫在那裡（也許現在，順便說一句，它們沒有被寫）。 正如我告訴你的，我們的“插入”很小 - 我們在緩衝表中有很多“插入”。 很明顯，此功能已停用 - 我只是告訴您我在我們的伺服器上看到的內容。 為什麼？ 這是反對使用緩衝表的另一個論點！ 斯波蒂非常難過。
誰知道這傢伙的名字叫斯波蒂？ VK員工舉起了手。 好的。
關於「KittenHouse」的計劃
計劃通常不會共享，對嗎？ 突然之間，你將無法實現這些目標，並且在別人眼中看起來也不太好。 但我會冒這個險！ 我們想要執行以下操作：在我看來，緩衝表仍然是一個拐杖，我們需要自己緩衝插入。 但我們仍然不想在磁碟上緩衝它，所以我們將在記憶體中緩衝插入。
因此，當進行“插入”時，它將不再是同步的- 它已經作為緩衝表工作，將插入到父表中（好吧，有一天）並通過單獨的通道報告插入已通過以及哪些插入已通過。沒有。
為什麼我不能保留同步插入？ 方便多了。 事實是，如果您從 10 個主機插入，那麼一切都很好 - 您將從每個主機獲得一點，您每秒插入一次，一切都很好。 但我希望這個方案能夠工作，例如，從兩台機器上運行，以便您可以高速下載 - 也許無法充分利用 Clickhouse，但透過反向代理從一台機器每秒至少寫入 100 兆位元組 -該方案必須擴展到大量和少量，因此我們不能為每次插入等待一秒鐘，因此它必須是異步的。 同樣，異步確認應該在插入完成後進行。 我們會知道它是否通過。
最重要的是，在這個方案中我們可以確定插入是否發生。 想像一下這種情況：您有一個緩衝表，您向其中寫入了一些內容，然後，假設該表進入唯讀模式並嘗試刷新緩衝區。 數據會去哪裡？ 它們將保留在緩衝區中。 但我們無法確定這一點 - 如果有其他錯誤，導致資料不會保留在緩衝區中怎麼辦...（地址 Alexey Milovidov，Yandex，ClickHouse 開發人員）還是會保留？ 總是？ 阿列克謝讓我們相信一切都會好起來的。 我們沒有理由不相信他。 但無論如何：如果我們不使用緩衝表，那麼它們就不會有任何問題。 創建兩倍的表也很不方便，儘管原則上沒有大問題。 這就是計劃。
我們來談談讀書
現在我們來談談閱讀。 我們也在這裡編寫了自己的工具。 看起來，好吧，為什麼要在這裡編寫自己的工具？...誰使用 Tabix？ 不知怎的，很少人舉手…誰對 Tabix 的表現感到滿意？ 嗯，我們對此並不滿意，而且查看數據不太方便。 它對於分析來說很好，但僅僅對於查看來說它顯然沒有優化。 所以我寫了自己的介面。
很簡單——它只能讀取資料。 他不知道如何顯示圖形，他不知道如何做任何事情。 但它可以顯示我們需要的東西：例如表格有多少行，佔用了多少空間（不拆成列），也就是說，一個非常基本的介面就是我們需要的。
而且它看起來與 Sequel Pro 非常相似，但僅在 Twitter 的 Bootstrap 上製作，並且是第二個版本。 你問：“尤里，為什麼是第二個版本？” 哪一年？ 2018？ 總的來說，我很久以前就為「Muscle」（MySQL）做了這個，只是改變了查詢中的幾行，它就開始為「Clickhouse」工作，為此特別感謝！ 因為解析器與“肌肉”解析器非常相似，並且查詢也非常相似 - 非常方便，尤其是一開始。
嗯，它可以過濾表格，可以顯示表格的結構和內容，允許您排序，按列過濾，顯示導致結果的查詢，受影響的行（結果有多少），即查看資料的基本內容。 相當快。
還有一個編輯器。 老實說，我試圖從 Tabix 竊取整個編輯器，但我做不到。 但不知何故它有效。 原則上就是這樣。
「Clickhouse」適合窩點
我想告訴您，儘管存在上述所有問題，Clickhouse 仍然非常適合日誌。 最重要的是，它解決了我們的問題 - 它非常快並且允許您按列過濾日誌。 原則上，緩衝表表現不佳，但通常沒有人知道為什麼......也許現在您更清楚哪裡會出現問題。
TCP？ 一般來說，在VK中習慣使用UDP。 當我使用 TCP 時…當然，沒有人告訴我：「尤里，你在說什麼！ 你不能，你需要 UDP。” 事實證明TCP並沒有那麼可怕。 唯一的問題是，如果你寫了數以萬計的活性化合物，你需要更仔細地準備它； 但這是可能的，而且很容易。
我承諾如果每個人都訂閱我們的公共“VK 後端”，我就會在HighLoad Siberia 上發布“Kittenhouse”和“Lighthouse”...而且你知道，不是每個人都訂閱...當然，我不會要求您訂閱我們的民眾。 你們人還是太多了，甚至可能有人會被冒犯，但還是請訂閱（這裡我得把眼睛畫得像貓一樣）。 那是 。 非常感謝！ Github 是我們的 。 使用 Clickhouse，您的頭髮將變得柔軟絲滑。
領導： - 朋友們，現在提問。 在我們向您頒發感謝狀和 VHS 報告後。
尤里·納斯雷迪諾夫（Yuri Nasretdinov，以下簡稱YN）： – 如果我的報告剛結束，你怎麼能在 VHS 上錄製我的報告？
領導： – 您也無法完全確定「Clickhouse」將如何運作！ 朋友們，5分鐘提問時間！
問題
觀眾提問（以下簡稱Q）： - 午安. 非常感謝您的報告。 我有兩個問題。 我將從一些無聊的事情開始：圖中「Kittenhouse」名稱中的字母 t 的數量（3、4、7...）是否會影響貓的滿意度？
陽： - 數量是多少？
Z: – 字母 t。 有 XNUMX 個 t，大約是 XNUMX 個 t。
陽： - 我沒修好嗎？ 嗯，當然可以！ 這些是不同的產品——我一直在欺騙你。 好吧，我開玩笑的——沒關係。 啊，就在這裡！ 不，是同一件事，我打錯了。
Z: - 謝謝。 第二個問題很嚴肅。 據我了解，在 Clickhouse 中，緩衝表僅存在於記憶體中，不會緩衝到磁碟，因此並不持久。
陽： - 是的。
Z: – 同時，您的用戶端緩衝到磁碟，這表示對這些相同日誌的傳送有一定的保證。 但 Clickhouse 並不能保證這一點。 解釋一下保證是如何進行的，由於什麼原因？..以下是該機制的更詳細信息
陽： – 是的，理論上這裡不存在矛盾，因為當 Clickhouse 倒塌時，你實際上可以透過一百萬種不同的方式來檢測它。 如果 Clickhouse 崩潰了（如果它錯誤地結束了），粗略地說，你可以倒回你寫下的一些日誌，並從一切都很好的那一刻開始。 假設你倒回一分鐘，也就是認為你在一分鐘內沖掉了所有內容。
Z: – 也就是說，「Kittenhouse」可以更長時間地保持窗戶，並且在跌倒時能夠識別並倒回窗戶？
陽： ——但這只是理論上的。 實際上，我們不這樣做，可靠的交付是從零到無限次。 但平均一個。 我們很滿意，如果 Clickhouse 由於某種原因崩潰或伺服器“重新啟動”，那麼我們會損失一點。 在所有其他情況下，什麼都不會發生。
Z: - 你好。 從一開始，我就認為您確實從報告的一開始就使用了 UDP。 你有http，所有這些......據我所知，你描述的大多數問題都是由這個特定的解決方案引起的...
陽： – 我們使用 TCP 做什麼？
Z: - 基本上是的。
陽： - 不。
Z: – 你在使用 fasthttp 時遇到了問題，在使用連線時遇到了問題。 如果您只使用 UDP，您將節省一些時間。 好吧，長消息或其他什麼都會有問題...
陽： - 什麼？
Z: – 對於長訊息，由於它可能不適合 MTU，還有其他東西......好吧，可能存在它們自己的問題。 問題是：為什麼不用UDP？
陽： – 我相信開發TCP/IP的作者比我聰明得多，比我更了解如何序列化資料包（以便它們走），同時調整發送窗口，不使網絡過載，反饋什麼沒有被讀取，不包括在另一邊...在我看來，所有這些問題都存在於UDP 中，只是我必須編寫比我已經編寫的程式碼更多的程式碼才能自己實現相同的事情，而且很可能不好。 我什至不太喜歡用 C 語言編寫，更不用說…
Z: - 就是方便！ 發送成功，無需等待任何事情 - 它是完全非同步的。 返回通知，表明一切正常 - 這意味著它已到達； 如果它不來，那就意味著情況不好。
陽： – 我兩者都需要 – 我需要能夠發送有送達保證和無送達保證的兩者。 這是兩種不同的場景。 我不需要丟失一些日誌或在合理範圍內不丟失它們。
Z: – 我不會浪費時間。 這需要更多地討論。 謝謝。
領導： – 誰有疑問 – 雙手舉向天空！
Z: - 你好，我是莎莎。 在報告中間的某個地方，出現了一種感覺，除了 TCP 之外，還可以使用現成的解決方案 - 某種 Kafka。
陽： – 嗯...我告訴過你我不想使用中間伺服器，因為...在Kafka中，事實證明我們有一萬台主機； 事實上，我們還有更多——數以萬計的主機。 在沒有任何代理的情況下使用 Kafka 也可能會很痛苦。 此外，最重要的是，它仍然會帶來“延遲”，它會提供您需要的額外主機。 但我不想擁有它們——我想要…
Z: “但最終結果還是那樣。”
陽： – 不，沒有主人！ 這一切都適用於 Clickhouse 主機。
Z: - 嗯，還有“Kittenhouse”，正好相反 - 他住在哪裡？
陽： – 在 Clickhouse 主機上，它不會寫入任何內容到磁碟。
Z: - 讓我們假設一下。
領導： - 你滿意嗎？ 我們可以給你工資嗎？
Z: - 是的你可以。 事實上，為了得到相同的東西，有很多拐杖，現在 - 之前關於 TCP 主題的答案在我看來與這種情況相矛盾。 感覺一切都可以在更短的時間內用我的膝蓋完成。
陽： – 還有為什麼我不想使用 Kafka，因為 Clickhouse Telegram 聊天中有很多抱怨，例如來自 Kafka 的消息丟失了。 不是來自Kafka本身，而是來自Kafka和Clickhaus的整合； 或有東西沒有連接到那裡。 粗略地說，那就需要為Kafka編寫一個客戶端了。 我認為沒有更簡單或更可靠的解決方案。
Z: – 告訴我，為什麼不嘗試排隊或搭乘某種公共巴士？ 既然您說透過非同步，您可以透過佇列發送日誌本身並透過佇列非同步接收回應？
陽： – 請建議可以使用哪些隊列？
Z: – 任何，即使不能保證它們是有序的。 某種 Redis、RMQ...
陽： – 我有一種感覺，即使在拉出 Clickhouse 的一台主機（在多台伺服器的意義上）上，Redis 很可能也無法拉出如此大的插入量。 我無法用任何證據來支持這一點（我還沒有對其進行基準測試），但在我看來，Redis 並不是最好的解決方案。 原則上，這個系統可以被認為是一個臨時的訊息隊列，但它是專門為「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