HighLoad++、Yuri Nasretdinov (VKontakte): VK が数万台のサーバーから ClickHouse にデータを挿入する方法

HighLoad++ モスクワ 2018、議会ホール。 9月15日 00:XNUMX

要約とプレゼンテーション: http://www.highload.ru/moscow/2018/abstracts/4066

ユーリ・ナスレディノフ (VKontakte): このレポートでは、当社で ClickHouse を導入した経験、つまり、なぜそれが必要なのか、どのくらいのデータを保存しているのか、どのように書いているのかなどについて説明します。

追加の資料 ELK、Big Query、TimescaleDB の代替として Clickhouse を使用する

ユーリ・ナスレディノフ： - こんにちは、みんな！ すでにご紹介しましたとおり、私の名前はユーリ・ナスレディノフです。 私はVKontakteで働いています。 私たちのサーバー群 (数万台) から ClickHouse にデータを挿入する方法について説明します。

ログとは何ですか?なぜ収集するのですか?

私たちがお伝えする内容: 私たちが何をしたのか、なぜ「ClickHouse」が必要なのか、なぜそれを選んだのか、特別に何も設定せずにおおよそどのようなパフォーマンスが得られるのか。 バッファ テーブル、バッファ テーブルに関して私たちが抱えていた問題、そしてオープン ソースから開発したソリューションである KittenHouse と Lighthouse についてさらに詳しく説明します。

そもそも、なぜ何もする必要があったのでしょうか (VKontakte では常にすべてがうまくいきますよね?)。 私たちはデバッグ ログを収集したいと考えていました (そして、そこには数百テラバイトのデータがありました)。統計を計算する方が便利かもしれません。 そして、私たちは何万ものサーバーからなるフリートを持っており、これらすべてをそこから実行する必要があります。

なぜそう決めたのでしょうか？ おそらくログを保存するためのソリューションがあったでしょう。 ここに、そのようなパブリックな「バックエンド VK」があります。 購読することを強くお勧めします。

ログとは何ですか? これは空の配列を返すエンジンです。 VK のエンジンは、他の人がマイクロサービスと呼ぶものです。 そしてこちらが笑顔のスタンプです（いいねがたくさん）。 どうして？ さて、さらに聞いてください！

ログの保存には何を使用できますか? Hadup について言及しないわけにはいきません。 次に、たとえば、Rsyslog (これらのログをファイルに保存します)。 LSD。 LSDが何なのか誰が知っていますか？ いいえ、このLSDではありません。 ファイルもそれぞれ保存します。 まあ、ClickHouse は奇妙なオプションです。

クリックハウスと競合他社: 要件と機会

私達は何が欲しいのか？ 操作についてあまり心配する必要がなく、できれば最小限の構成でそのまま動作するようにしたいと考えています。 たくさん書きたいし、早く書きたい。 そして私たちはそれを何か月、何年も、つまり長期間保存したいと考えています。 私たちは、彼らが私たちに来て「ここで何かがうまくいかない」と言った問題を理解したいと思うかもしれません。それは 3 か月前のことであり、3 か月前に何が起こったのかを確認できるようにしたいと考えています。」 データ圧縮 – なぜそれがプラスになるのかは明らかです – それは占有するスペースの量を減らすからです。

そして、非常に興味深い要件があります。コマンドの出力 (ログなど) を書き込むことがありますが、その出力は簡単に 4 キロバイトを超えることがあります。 そして、これが UDP 経由で機能する場合、費用はかかりません...接続に「オーバーヘッド」がかからず、多数のサーバーにとってこれはプラスになります。

オープンソースが私たちに何を提供してくれるのか見てみましょう。 まず、ログ エンジンがあります。これが私たちのエンジンです。 原則として、彼は何でもでき、長いセリフを書くことさえできます。 そうですね、透過的にデータを圧縮するわけではありません。必要に応じて大きな列を自分で圧縮することもできます...もちろん、(可能であれば) 圧縮したくありません。 唯一の問題は、彼が自分の記憶に適合するものしか提供できないことです。 残りを読み取るには、このエンジンの binlog を取得する必要があるため、かなりの時間がかかります。

他にどのようなオプションがありますか? たとえば、「ハダップ」。 操作のしやすさ... Hadup のセットアップが簡単だと思う人はいませんか? もちろん録音には問題ありません。 読んでいると時々疑問が湧いてきます。 原則として、特にログの場合はおそらくそうではないと思います。 長期保存 - もちろん、データ圧縮 - 長い文字列 - 記録できることは明らかです。 しかし、多数のサーバーから録画する場合は...やはり自分で何かをする必要があります。

Rsyslog。 実際、binlog をダンプせずに読み取ることができるようにバックアップ オプションとして使用しましたが、長い行を書き込むことはできず、原則として 4 キロバイトを超えることはできません。 同じ方法でデータ圧縮を自分で行う必要があります。 読み取りはファイルから行われます。

次に、LSDの「バドゥシュカ」の開発があります。 基本的に「Rsyslog」と同じです。長い文字列をサポートしていますが、UDP 経由では動作できません。実際、このため、残念ながらかなり多くの内容を書き直す必要があります。 数万台のサーバーから記録できるように LSD を再設計する必要があります。

そしてここ！ 面白いオプションは ElasticSearch です。 どのように言って？ 彼は読書は得意です、つまり速く読むことができますが、書くことはあまり得意ではありません。 まず、データを圧縮すると非常に弱いです。 おそらく、完全な検索には、元のボリュームよりも大きなデータ構造が必要になります。 操作が難しく、問題が発生することがよくあります。 そして、繰り返しになりますが、Elastic での録音はすべて自分たちで行う必要があります。

もちろん、ここでは ClickHouse が理想的な選択肢です。 唯一の問題は、数万のサーバーからの録画が問題であるということです。 しかし、少なくとも問題が XNUMX つあります。何らかの方法で解決することができます。 レポートの残りの部分はこの問題に関するものです。 ClickHouse にはどのようなパフォーマンスが期待できますか?

どうやって挿入するのでしょうか？ マージツリー

皆さんの中で「ClickHouse」について聞いたことがない、または知らない人はいるでしょうか? 言わなきゃいけないんですよね？ とても早い。 そこへの挿入 - 毎秒 1 ～ 2 ギガビット、毎秒最大 10 ギガビットのバーストは実際にこの構成に耐えることができます - 6 つの 256 コア Xeon (つまり、最も強力ではありません)、20 ギガバイトの RAM、6 テラバイトがありますRAID 内 (誰も構成されていない、デフォルト設定)。 ClickHouse 開発者の Alexey Milovidov は、私たちが何も設定していないために、おそらくそこに座って泣いているでしょう (私たちにとってはすべてがそのように機能しました)。 したがって、データが十分に圧縮されていれば、例えば毎秒約６０億ラインの走査速度が得られる。 テキスト文字列に対して % を実行すると、100 秒あたり XNUMX 億行、つまりかなり高速に見えます。

どうやって挿入するのでしょうか？ VK が PHP を使用していることはご存知でしょう。 各 PHP ワーカーから HTTP 経由で「ClickHouse」のレコードごとに MergeTree テーブルに挿入します。 この計画に問題があると誰が考えるでしょうか? なぜか全員が手を挙げなかった。 言っておくけど。

まず、サーバーがたくさんあります。したがって、接続も多くなります (悪い)。 その場合は、MergeTree へのデータの挿入頻度は XNUMX 秒に XNUMX 回以下にすることをお勧めします。 その理由は誰にも分かりません。 分かった、分かった。 これについてはもう少し詳しく説明します。 もう XNUMX つの興味深い質問は、分析を行っているのではなく、データを強化する必要がなく、中間サーバーも必要なく、「ClickHouse」に直接挿入したいということです (できれば、直接的なほど良いです)。

したがって、MergeTree では挿入はどのように行われるのでしょうか? XNUMX 秒に XNUMX 回以下の頻度で挿入する方が良いのはなぜですか? 実際、「ClickHouse」は列型データベースであり、主キーの昇順でデータをソートし、挿入を実行すると、少なくともデータがソートされた列の数と同じ数のファイルが作成されます。主キーの昇順で (挿入ごとに別のディレクトリがディスク上に作成され、一連のファイルが作成されます)。 その後、次の挿入が行われ、バックグラウンドでより大きな「パーティション」に結合されます。 データはソートされているため、多くのメモリを消費することなく、ソートされた XNUMX つのファイルを「マージ」することができます。

ただし、ご想像のとおり、挿入ごとに 10 個のファイルを書き込むと、ClickHouse (またはサーバー) がすぐに終了してしまうため、大きなバッチで挿入することをお勧めします。 したがって、私たちは最初のスキームを実際に運用することはありませんでした。 私たちはすぐに 2 つを立ち上げました。ここでの No.XNUMX は次のとおりです。

ここで、起動したサーバーが約 XNUMX 台あり、PHP だけがあると想像してください。 そして、各サーバーには「Kittenhouse」と呼ばれるローカル エージェントがあり、「ClickHouse」との接続を XNUMX つ維持し、数秒ごとにデータを挿入します。 データを MergeTree ではなくバッファ テーブルに挿入します。これは、MergeTree にすぐに直接挿入することを避けるために正確に機能します。

バッファテーブルの操作

それは何ですか？ バッファ テーブルは、シャード化されたメモリの一部です (つまり、頻繁に挿入できます)。 これらは複数の部分で構成され、各部分は独立したバッファーとして機能し、独立してフラッシュされます (バッファー内に多くの部分がある場合は、3 秒あたり多くの挿入が行われます)。 これらのテーブルから読み取ることは可能です。その後、バッファーの内容と親テーブルの結合を読み取りますが、現時点では書き込みがブロックされているため、そこから読み込まない方がよいでしょう。 また、バッファ テーブルは非常に優れた QPS を示します。つまり、最大 XNUMX QPS までは挿入時にまったく問題ありません。 データはメモリに保存されているだけなので、サーバーの電源が失われると、データが失われる可能性があることは明らかです。

同時に、バッファーを使用するスキームは ALTER を複雑にします。これは、古いスキームを使用して古いバッファー テーブルを最初に削除する必要があるためです (テーブルが削除される前にフラッシュされるため、データはどこにも消えません)。 次に、必要なテーブルを「変更」し、バッファ テーブルを再度作成します。 したがって、バッファ テーブルがない間はデータはどこにも流れませんが、少なくともローカルのディスク上にデータを置くことができます。

Kittenhouse とは何ですか?またその仕組みは何ですか?

キトゥンハウスとは何ですか？ これはプロキシです。 何語だと思いますか？ 私のレポートでは、最も誇大広告のトピックを集めました。「クリックハウス」、ゴー、もしかしたら何か他のことを思い出すかもしれません。 はい、これは Go で書かれています。私は C で書く方法がよくわかりませんし、書きたくないからです。

したがって、各サーバーとの接続を維持し、メモリに書き込むことができます。 たとえば、エラー ログを Clickhouse に書き込む場合、Clickhouse にデータを挿入する時間がない場合 (結局のところ、書き込まれる量が多すぎる場合)、メモリを拡張せず、残りを単に破棄します。 なぜなら、XNUMX 秒あたり数ギガビットのエラーを書き込むと、おそらく一部を廃棄できるからです。 キトゥンハウスならこんな事が出来ます。 さらに、信頼性の高い配信を実行できます。つまり、ローカル マシン上のディスクに書き込み、毎回 (数秒に XNUMX 回)、このファイルからデータの配信を試みます。 そして最初は、バイナリ形式やテキスト形式 (通常の SQL のような) ではなく、通常の値形式を使用しました。

しかし、その後、これが起こりました。 私たちは信頼性の高い配信を使用し、ログを書き込み、その後決定しました (条件付きテストクラスターでした)...数時間停止してから元に戻し、XNUMX 台のサーバーから挿入が開始されました - Clickhouse にはまだ「接続時のスレッド」 - したがって、XNUMX 回の接続では、アクティブな挿入により、サーバー上の負荷平均は約 XNUMX になります。 驚いたことに、サーバーはリクエストを受け入れましたが、しばらくしてからデータが挿入されたままでした。 しかし、サーバーがそれを提供するのは非常に困難でした...

nginxを追加する

接続ごとのスレッド モデルのこのようなソリューションは nginx です。 Clickhouse の前に nginx をインストールし、同時に 2 つのレプリカのバランスを設定し (これが実際に当てはまるわけではありませんが、挿入速度が 50 倍向上しました)、Clickhouse への接続数を制限しました。アップストリーム、およびそれに応じて XNUMX 接続を超えると、挿入する意味がないようです。

次に、ここには nginx が XNUMX つしかないため、このスキームには一般的に欠点があることに気付きました。 したがって、この nginx がクラッシュすると、レプリカが存在するにもかかわらず、データが失われるか、少なくともどこにも書き込めなくなります。 そのため、私たちは独自の負荷分散を作成しました。 また、「クリックハウス」が依然としてログに適していることもわかり、「悪魔」も「クリックハウス」にログを書き始めました。正直に言うと、非常に便利でした。 私たちは今でも他の「悪魔」に対してそれを使用しています。

次に、この興味深い問題を発見しました。SQL モードで挿入する非標準的な方法を使用すると、本格的な AST ベースの SQL パーサーが強制され、非常に時間がかかります。 したがって、このようなことが起こらないように設定を追加しました。 負荷分散とヘルスチェックを行ったので、XNUMX つが停止してもデータが残るようになりました。 さまざまな Clickhouse クラスターを使用するために必要なテーブルがかなり多くなりました。 そして、他の用途についても考え始めました。たとえば、nginx モジュールからログを書き込みたいのですが、RPC を使用して通信する方法がわかりません。 そうですね、少なくとも何らかの方法で送信する方法、たとえば UDP 経由でローカルホスト上のイベントを受信し、それを Clickhouse に転送する方法を教えたいと思います。

解決まであと一歩

最終的なスキームは次のようになります (このスキームの 50 番目のバージョン): Clickhouse の前の各サーバーには nginx があり (同じサーバー上にあります)、接続数の制限が XNUMX であるローカルホストにリクエストをプロキシするだけです。個。 そして、この計画はすでにかなりうまく機能しており、すべてがうまくいきました。

そんな生活を一ヶ月ほど続けました。 誰もが満足し、テーブルを追加し、追加し、追加しました... 一般的に、バッファー テーブルを追加する方法はあまり最適ではないことがわかりました (そのように言い換えましょう)。 各テーブルで 16 個のピース​​を実行し、フラッシュ間隔は数秒でした。 20 のテーブルがあり、各テーブルは 8 秒あたり 502 件の挿入を受け取りました。そしてこの時点で「クリックハウス」が始まりました...レコードが遅くなり始めました。 彼らは通過さえしませんでした... Nginx にはデフォルトで非常に興味深い機能があり、接続がアップストリームで終了した場合、すべての新しいリクエストに対して単純に「XNUMX」を返します。

そして、ここでは (クリックハウス自体のログを見たところですが)、リクエストの約 XNUMX パーセントが失敗しました。 したがって、ディスク使用率が高く、マージが頻繁に行われました。 さて、私は何をしましたか？ 当然のことながら、接続とアップストリームがなぜ終了したのかを正確に理解する気はありませんでした。

nginx をリバース プロキシに置き換える

これは自分たちで管理する必要があり、nginx に任せる必要はないと判断しました。nginx は Clickhouse にどのようなテーブルがあるのか​​知りません。そこで、nginx をリバース プロキシに置き換えました。これも自分で作成しました。

彼は何をしているの？ fasthttp ライブラリ「goshnoy」に基づいて動作します。つまり、nginx とほぼ同じくらい高速です。 ごめんなさい、Igor、もしここにいるなら (注: Igor Sysoev は nginx Web サーバーを作成したロシアのプログラマーです)。 これらがどのような種類のクエリ (INSERT または SELECT) であるかを理解でき、それに応じて、クエリの種類ごとに異なる接続プールを保持します。

したがって、挿入リクエストを完了する時間がない場合でも、「選択」は通過しますし、その逆も同様です。 そして、エラーや構文エラーなどがあった場合に、データをバッファ テーブルにグループ化します。バッファ テーブルに単純に挿入した場合、残りのデータに大きな影響を与えないようにします。小さな「bachi」があり、すべての構文エラーはこの小さな部分にのみ影響しました。 そしてここではすでに大きなバッファに影響を与えています。 小とは 1 メガバイト、つまりそれほど小さくありません。

同期を挿入して基本的に nginx を置き換えると、基本的に nginx が以前に行っていたことと同じことが行われます。このためにローカルの「Kittenhouse」を変更する必要はありません。 また、fasthttp を使用するため、非常に高速です。リバース プロキシ経由で 100 つの挿入に対して XNUMX 秒あたり XNUMX 万件を超えるリクエストを行うことができます。 理論的には、一度に XNUMX 行を kittenhouse リバース プロキシに挿入できますが、もちろん、そんなことはしません。

スキームは次のようになります。「Kittenhouse」、リバース プロキシが多くのリクエストをテーブルにグループ化し、次にバッファ テーブルがリクエストをメインのリクエストに挿入します。

Killer は一時的な解決策であり、Kitten は永続的な解決策です

これは興味深い問題です...fasthttp を使用したことがありますか? POST リクエストで fasthttp を使用したのは誰ですか? おそらく、デフォルトでリクエスト本文をバッファリングし、バッファ サイズが 16 メガバイトに設定されているため、これは実際に行うべきではありませんでした。 ある時点で挿入が追いつかなくなり、数万のサーバーすべてから 16 メガバイトのチャンクが到着し始め、それらはすべてクリックハウスに送信される前にメモリにバッファリングされました。 したがって、メモリが不足し、Out-Of-Memory Killer がやって来て、リバース プロキシ (または「クリックハウス」。理論的にはリバース プロキシよりも多くのものを「食べる」可能性があります) を殺しました。 このサイクルが繰り返されました。 あまり楽しい問題ではありません。 しかし、私たちは数か月の運用後に初めてこれに気づきました。

私が何をしてしまったのか？ 繰り返しますが、正確に何が起こったのかを理解するのはあまり好きではありません。 メモリにバッファリングすべきではないことは明らかだと思います。 fasthttp にパッチを当ててみましたが、できませんでした。 しかし、私は何もパッチを適用する必要がないようにする方法を見つけ、HTTP で独自のメソッドを思いつきました。それを KITTEN と名付けました。 まあ、それは論理的です - 「VK」、「Kitten」... 他には何がありますか?...

Kitten メソッドを使用してリクエストがサーバーに届いた場合、サーバーは論理的に「ニャー」と応答する必要があります。 彼がこれに応答した場合、彼はこのプロトコルを理解していると見なされ、接続が傍受され (fasthttp にはそのようなメソッドがあります)、接続は「raw」モードになります。 なぜそれが必要なのでしょうか? TCP 接続からの読み取りがどのように行われるかを制御したいと考えています。 TCP には素晴らしい特性があります。相手側から誰も読み取っていない場合、書き込みは待機し始め、特にメモリはこのために消費されません。

それで、私は一度に約50のクライアントから読み取りました（レートが別のDCから来ているとしても、20で間違いなく十分であるため、XNUMXから）...このアプローチでは消費量は少なくともXNUMX倍減少しましたが、正直に言うと、私は, もう意味がないので正確に何時を測ることはできませんでした（すでに誤差のレベルに達しています）。 プロトコルはバイナリです。つまり、テーブル名とデータが含まれます。 http ヘッダーがないので、Web ソケットは使用しませんでした (ブラウザーと通信する必要はありません。ニーズに合ったプロトコルを作成しました)。 そして彼にとってすべてがうまくいきました。

バッファテーブルは悲しい

最近、バッファ テーブルの別の興味深い機能を発見しました。 そして、この問題はすでに他の問題よりもはるかに苦痛です。 この状況を想像してみましょう。あなたはすでに Clickhouse を積極的に使用しており、数十の Clickhouse サーバーを持っており、読み取りに非常に長い時間 (たとえば 60 秒以上) かかるリクエストがいくつかあるとします。 そして、あなたはこの瞬間に Alter を実行しに来ます... その間、「Alter」の前に開始された「select」はこの表には含まれません。「Alter」は開始されません。おそらく、「Clickhouse」がどのように機能するかの一部の機能です。この場所。 おそらくこれは修正できるでしょうか？ それとも不可能なのでしょうか？

一般に、実際にはこれがそれほど大きな問題ではないことは明らかですが、バッファ テーブルではさらに問題が大きくなります。 なぜなら、たとえば、「Alter」がタイムアウトになった場合 (そして、別のホストでタイムアウトになる可能性があります。たとえば、自分のホストではなく、レプリカでタイムアウトになる可能性があります)、そのときは... バッファ テーブル、つまり「Alter」( (または他のホスト) がタイムアウトした場合、「Alter」エラーが発生しました) - データの書き込みが継続していることを確認する必要があります: (親テーブルと同じスキームに従って) バッファー テーブルを作成し直してから、 「Alter」は通過し、結局終了し、テーブルのスキーマが親と異なるバッファーになり始めます。 「Alter」の内容によっては、このバッファー テーブルに挿入が行われなくなる可能性があります。これは非常に悲しいことです。

そのような兆候もあります (おそらく誰かがそれに気づいたでしょう) - Clickhouse の新しいバージョンでは query_thread_log と呼ばれます。 デフォルトでは、一部のバージョンにはこれがありました。 ここでは、数か月で 840 億 100 万件のレコード (XNUMX ギガバイト) が蓄積されました。 これは、そこに「挿入」が書かれていたという事実によるものです（ちなみに、今は書かれていないかもしれません）。 先ほども述べたように、私たちの「挿入」は小さいです - バッファーテーブルへの「挿入」がたくさんありました。 これが無効になっていることは明らかです。私はサーバー上で見たことを話しているだけです。 なぜ？ これは、バッファ テーブルの使用に対するもう XNUMX つの議論です。 スポッティはとても悲しいです。

この男の名前がスポッティだなんて誰が知った？ VK社員が手を挙げた。 わかりました。

「KitttenHouse」の企画について

計画は通常共有されませんよね？ 突然、それらを満たせなくなり、他の人の目にはあまり良く見えなくなります。 しかし、私はリスクを負います！ 私たちは次のことを行いたいと考えています。バッファ テーブルは依然として重要な要素であり、挿入を自分たちでバッファする必要があるように思えます。 ただし、ディスク上にバッファリングしたくないため、挿入をメモリにバッファリングします。

したがって、「挿入」が行われると、それは同期的ではなくなります。すでにバッファー テーブルとして機能し、親テーブルに挿入され (まあ、いつかは後になりますが)、どの挿入が渡されたか、またどの挿入が渡されたかを別のチャネル経由で報告します。してない。

同期挿入を終了できないのはなぜですか? はるかに便利です。 実際のところ、10 のホストから挿入した場合はすべて問題ありません。各ホストから少しずつ取得し、そこに 100 秒に XNUMX 回挿入すれば、すべて問題ありません。 しかし、このスキームを、たとえば XNUMX 台のマシンから動作させて、高速でダウンロードできるようにしたいと考えています。おそらく Clickhouse から最大値を引き出すことはできませんが、リバース プロキシを介して XNUMX 台のマシンから XNUMX 秒あたり少なくとも XNUMX メガバイトを書き込むことができるようにしたいと考えています。このスキームは大量と少量の両方に対応する必要があるため、挿入ごとに XNUMX 秒も待つことができないため、非同期にする必要があります。 また、同様に、挿入が完了した後に非同期確認が行われる必要があります。 合格したか否かはわかります。

最も重要なことは、このスキームでは挿入が行われたかどうかを確実に知ることができるということです。 この状況を想像してください。バッファ テーブルがあり、そこに何かを書き込んだ後、テーブルが読み取り専用モードになり、バッファをフラッシュしようとしたとします。 データはどこに行くのでしょうか? それらはバッファ内に残ります。 しかし、これを確信することはできません - データがバッファに残らない他のエラーが発生した場合はどうなるでしょうか... (Alexey Milovidov、Yandex、ClickHouse 開発者に宛てて) それともデータは残りますか? いつも？ アレクセイはすべてがうまくいくと私たちに説得します。 彼を信じない理由はありません。 ただし、バッファ テーブルを使用しない場合は、問題は発生しません。 原則として大きな問題はありませんが、XNUMX 倍のテーブルを作成することも不便です。 これが計画です。

読書について話しましょう

さて、読書について話しましょう。 ここでは独自のツールも作成しました。 なぜここに独自の楽器を書く必要があるのでしょう?. そして Tabix を使用したのは誰ですか? なぜか手を挙げた人が少なかったです...そして、Tabix のパフォーマンスに満足している人は誰ですか? まあ、これには満足していませんし、データを見るのにもあまり便利ではありません。 分析には問題ありませんが、表示するだけでは明らかに最適化されていません。 そこで私は独自のインターフェイスを作成しました。

それは非常に単純です - データを読み取るだけです。 彼はグラフィックの表示方法を知りませんし、何をするかも知りません。 しかし、必要なものは表示できます。たとえば、テーブルに行が何行あるか、(列に分割せずに) テーブルが占めるスペースはどれくらいか、つまり、非常に基本的なインターフェイスが必要です。

これは Sequel Pro に非常によく似ていますが、Twitter の Bootstrap と 2018 番目のバージョンでのみ作成されています。 「ユーリ、なぜ XNUMX 番目のバージョンを使うのですか?」と尋ねます。 何年？ XNUMX年？ 一般に、私はかなり前に「Muscle」（MySQL）に対してこれを実行し、そこでクエリの数行を変更しただけで、「Clickhouse」でも機能するようになりました。特に感謝します。 なぜなら、パーサーは「筋肉」のパーサーに非常に似ており、クエリも非常に似ているため、特に最初は非常に便利です。

テーブルをフィルタリングし、テーブルの構造と内容を表示し、並べ替えや列によるフィルタリングを可能にし、結果となったクエリ、影響を受ける行 (結果としていくつ) を表示します。データを表示するための基本的な事項。 かなり速いです。

編集者もいます。 正直に言って、Tabix からエディタ全体を盗もうとしましたが、できませんでした。 しかし、どういうわけか機能します。 原則的にはそれだけです。

巣穴に最適な「クリックハウス」

ここで述べたすべての問題にもかかわらず、Clickhouse はログに非常に適していることをお伝えしたいと思います。 最も重要なことは、これにより問題が解決されることです。非常に高速で、列ごとにログをフィルタリングできるようになります。 原則として、バッファ テーブルのパフォーマンスは良好ではありませんが、その理由は通常誰にもわかりません...おそらく、どこに問題があるかがよくわかったかもしれません。

TCP? 一般に、VK では UDP を使用するのが通例です。 そして、私が TCP を使用したとき... もちろん、誰も私にこうは言いませんでした。 それはできません。UDP が必要です。」 TCP はそれほど怖くないことがわかりました。 唯一のことは、作成する活性化合物が数万ある場合は、もう少し慎重に準備する必要があるということです。 しかし、それは可能であり、非常に簡単です。

誰もが私たちの公開「VK バックエンド」を購読したら、「Kittenhouse」と「Lighthouse」を HighLoad Siberia に投稿すると約束しました...そしてご存知のとおり、誰もが購読したわけではありません... もちろん、私はあなたに私たちの公開の「VK バックエンド」を購読するように要求するつもりはありません公共。 まだまだ人数が多すぎて、気分を害する人もいるかもしれませんが、それでも購読してください（そしてここでは猫のような目をしなければなりません）。 それは ちなみにリンクします。 どうもありがとうございます！ Github は私たちのものです ここで。 クリックハウスを使用すると、髪は柔らかく滑らかになります。

モデレーター： - 皆さん、それでは質問をどうぞ。 感謝状とVHSレポートを贈呈した直後です。

ユーリ・ナスレディノフ（以下、YN）： – 私のレポートが終了したばかりだったら、どうやって VHS に録画できたのですか?

モデレーター： – また、「クリックハウス」がどのように機能するかどうかを完全に判断することはできません。 皆さん、質問は 5 分間です。

質問

会場からの質問（以下、Q）： - こんにちは。 ご報告ありがとうございます。 質問が3つあります。 軽薄なことから始めます。図の「Kittenhouse」という名前の t の文字数 (4、7、XNUMX...) は猫の満足度に影響しますか?

YN: - どれくらいの量ですか？

З: – 手紙 t。 t が XNUMX つあります。t が XNUMX つほどあります。

YN: - 直さなかったんですか？ まあ、もちろんそうですよ！ これらは別の製品です - 私は今まであなたを騙していただけでした。 わかりました、冗談です - それは問題ではありません。 ああ、ここですね！ いいえ、同じです、タイプミスをしました。

З: - ありがとう。 XNUMX番目の質問は深刻です。 私が理解している限り、Clickhouse では、バッファー テーブルはメモリ内にのみ存在し、ディスクにバッファリングされず、したがって永続的ではありません。

YN: - はい。

З: – 同時に、クライアントはディスクにバッファリングします。これは、これらの同じログの配信がある程度保証されることを意味します。 ただし、クリックハウスではこれが保証されるわけではありません。 保証がどのように行われるのか、何のために行われるのか説明してください。この仕組みについて詳しく説明します。

YN: – はい、理論的にはここに矛盾はありません。クリックハウスが崩壊したとき、実際には何百万もの異なる方法でそれを検出できるからです。 Clickhouse がクラッシュした場合 (正しく終了しなかった場合)、大まかに言えば、書き留めたログを少し巻き戻して、すべてがまったく問題なかった瞬間から開始することができます。 XNUMX 分巻き戻すとします。つまり、XNUMX 分以内にすべてをフラッシュしたと見なされます。

З: – つまり、「Kittenhouse」は窓をより長く保持し、落下した場合にはそれを認識して巻き戻すことができるということですか？

YN: – しかし、これは理論上の話です。 実際にはこれは行わず、信頼性の高い配信はゼロ回から無限回まで行われます。 しかし、平均してXNUMXつです。 Clickhouse が何らかの理由でクラッシュしたり、サーバーが「再起動」したりした場合には、多少の損失が発生することに満足しています。 それ以外の場合は何も起こりません。

З: - こんにちは。 レポートの最初から、本当に UDP を使用しているように思えました。 あなたは http を持っています...そして、私が理解しているように、あなたが説明した問題のほとんどは、この特定の解決策によって引き起こされました...

YN: – TCP は何を使用するのでしょうか?

З: - 基本的にはそうです。

YN: いいえ。

З: – fasthttp に問題があり、接続にも問題がありました。 UDP を使用していれば、時間を節約できたはずです。 まぁ、長文とかは問題あるだろうけど…。

YN: - ものによって？

З: – 長いメッセージの場合は、MTU に収まらない可能性があるため、別の何か...まあ、それ自体の問題があるかもしれません。 問題は、なぜ UDP ではないのかということです。

YN: – TCP/IP を開発した作成者は私よりもはるかに賢くて、パケットをシリアル化する方法 (送信するための)、同時に送信ウィンドウを調整する方法、ネットワークに過負荷をかけない方法、フィードバックを提供する方法をよく知っていると信じています。は読み取られず、反対側ではカウントされません...私の意見では、これらすべての問題はUDPに存在しますが、同じことを自分で実装するには、これまでに書いたコードよりもさらに多くのコードを書かなければなりません。不完全に。 私は C で書くことさえあまり好きではありません、ましてや C で書くことさえ好きではありません...

З: - とにかく便利！ 送信は完了し、何も待つ必要はありません。完全に非同期です。 すべて順調だという通知が戻ってきました。つまり、到着したということです。 それが来なかったら、それは悪いということです。

YN: – 両方必要です – 配達保証付きと配達保証なしの両方を送信できる必要があります。 これらは XNUMX つの異なるシナリオです。 一部のログを失わないようにする必要があります。または、合理的な範囲内でログを失わないようにする必要があります。

З: – 時間を無駄にはしません。 これについてはさらに議論する必要がある。 ありがとう。

モデレーター： – 質問がある人は – 空に手を上げてください!

З: - こんにちは、私はサーシャです。 レポートの途中で、TCP に加えて、既製のソリューション、つまりある種の Kafka を使用できるのではないかという感覚が現れました。

YN: – そうですね...中間サーバーは使いたくないと言ったはずです。なぜなら...Kafka には XNUMX 万のホストがあることが判明したからです。 実際には、さらに多くの、数万のホストが存在します。 また、プロキシを使用せずに Kafka を使用するのは面倒な場合もあります。 さらに、最も重要なことは、依然として「遅延」が発生し、必要な追加のホストが発生することです。 でも、私はそれらを持ちたくない、私は欲しい...

З: 「でも、結局はそういうことになったんですよ。」

YN: – いいえ、ホストはいません! これはすべて Clickhouse ホスト上で動作します。

З: - そうですね、そして「子猫ハウス」はその逆です - 彼はどこに住んでいますか？

YN: – Clickhouse ホストでは、ディスクには何も書き込まれません。

З: - 仮定してみましょう。

モデレーター： - あなたは満足していますか？ 給料をあげてもいいですか？

З: - はい、できます。 実際、同じことを得るには多くの松葉杖が必要ですが、私の意見では、TCP に関する以前の回答はこの状況と矛盾しています。 すべてを膝の上でもっと短時間で行うことができたような気がします。

YN: – また、なぜ Kafka を使用したくなかったのかというと、Clickhouse Telegram チャットで、たとえば、Kafka からのメッセージが失われたという苦情が非常に多くあったからです。 Kafka 自体からではなく、Kafka と Clickhaus の統合においてです。 または何かがそこで接続されませんでした。 大まかに言うと、Kafka 用のクライアントを作成する必要があります。 これより簡単で信頼性の高い解決策はないと思います。

З: – 教えてください、なぜ行列や共通バスのようなものを試しなかったのですか？ 非同期を使用すると、キューを介してログ自体を送信し、キューを介して非同期的に応答を受信できると言っているのでしょうか？

YN: – どのようなキューが使用できるかを提案してください。

З: – たとえそれらが正常であるという保証がなくても。 ある種の Redis、RMQ...

YN: – Redis は、Clickhouse を引き出す XNUMX 台のホスト (複数のサーバーという意味) 上でも、そのような大量の挿入を引き出すことはおそらくできないのではないかと感じています。 これを証拠で裏付けることはできませんが (ベンチマークを行っていません)、ここでは Redis が最適なソリューションではないようです。 原則として、このシステムは即席のメッセージ キューと考えることができますが、「クリックハウス」専用に調整されています。

モデレーター： – ユリ、ありがとう。 ここで質疑応答を終了し、質問者のうち誰にこの本を渡すかを申し上げたいと思います。

YN: – 最初に質問した人に本をプレゼントしたいと思います。

モデレーター： - 素晴らしい！ 素晴らしい！ 素晴らしい！ どうもありがとう！

いくつかの広告 🙂

いつもご宿泊いただきありがとうございます。 私たちの記事が気に入っていますか? もっと興味深いコンテンツを見たいですか? 注文したり、友人に勧めたりして私たちをサポートしてください。 開発者向けのクラウド VPS は 4.99 ドルから, 当社があなたのために発明した、エントリーレベルのサーバーのユニークな類似物です。 VPS (KVM) E5-2697 v3 (6 コア) 10GB DDR4 480GB SSD 1Gbps 19 ドルからの真実、またはサーバーを共有する方法? (RAID1 および RAID10、最大 24 コア、最大 40GB DDR4 で利用可能)。

アムステルダムのエクイニクス Tier IV データセンターでは Dell R730xd が 2 倍安い? ここだけ 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV 199 ドルから オランダで！ Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 ドルから! について読む インフラストラクチャー企業を構築する方法730 ペニーで 5 ユーロの価値がある Dell R2650xd E4-9000 vXNUMX サーバーを使用したクラスですか?

出所： habr.com