ClickHouseの有効活用。 アレクセイ・ミロヴィドフ (Yandex)

ClickHouse は特殊なシステムであるため、使用する場合はそのアーキテクチャの特徴を考慮することが重要です。 このレポートでは、Alexey が、非効率的な作業につながる可能性がある、ClickHouse を使用する際のよくある間違いの例について説明します。 実際の例では、XNUMX つまたは別のデータ処理スキームを選択することでパフォーマンスが桁違いに変化する可能性があることを示します。

こんにちは、みんな！ 私の名前は Alexey、ClickHouse を作っています。

まず、急いでいますが、今日は ClickHouse が何であるかについては説明しません。 正直に言うと、もう飽きました。 それが何なのかを毎回話します。 そしておそらく誰もがすでに知っています。

代わりに、どのような間違いが考えられるか、つまり ClickHouse をどのように誤って使用するかを説明します。 実際、私たちは ClickHouse をシンプルで便利で、すぐに使えるシステムとして開発しているので、心配する必要はありません。 インストールしましたが、問題ありません。

ただし、このシステムは特殊であり、このシステムを快適ゾーンから外してしまうような異常な使用例に簡単に遭遇する可能性があることを考慮する必要があります。

では、どんな熊手があるのでしょうか？ 主に当たり前のことを話します。 すべては誰にとっても明らかであり、誰もがすべてを理解しており、自分がとても賢いことを嬉しく思い、理解していない人は何か新しいことを学ぶでしょう。

最初の最も単純な例は、残念ながら頻繁に発生しますが、小さなバッチを伴う多数の挿入、つまり多数の小さな挿入です。

ClickHouse が挿入を実行する方法を考慮すると、XNUMX 回のリクエストで少なくとも XNUMX テラバイトのデータを送信できます。 問題じゃない。

そして、典型的なパフォーマンスがどのようなものになるかを見てみましょう。 たとえば、Yandex.Metrica データからのテーブルがあります。 ヒット。 105 いくつかのコラム。 非圧縮で 700 バイト。 そして、XNUMX 万行ずつバッチで適切に挿入していきます。

MergeTree をテーブルに挿入すると、400 秒あたり 000 万行が処理されることがわかります。 素晴らしい。 レプリケートされたテーブルでは少し小さくなり、XNUMX 秒あたり約 XNUMX 行になります。

また、クォーラムの挿入を有効にすると、パフォーマンスは少し低下しますが、250 秒あたり 000 タームという十分なパフォーマンスが得られます。 クォーラムの挿入は、ClickHouse* の文書化されていない機能です。

※2020年現在、 すでに文書化されている.

何か悪いことをしたらどうなりますか？ MergeTree テーブルに 59 行を挿入すると、10 秒あたり 000 行が取得されます。 それは6倍遅いです。 ReplicatedMergeTree では、2 秒あたり XNUMX 行。 クォーラムがオンになっている場合、XNUMX 秒あたり XNUMX 行の速度になります。 私の意見では、これはある種の絶対的なくだらないことです。 どうしたらそんなにゆっくりできるんですか？ 私のTシャツにも、ClickHouseの速度を落とさないようにと書いてあります。 しかし、それにもかかわらず、それは時々起こります。

実は、これが私たちの欠点なのです。 すべてをうまく機能させることも簡単だったのですが、そうはなりませんでした。 スクリプトではそれが必要ではなかったため、実行しませんでした。 私たちはすでに肉を持っていました。 入り口でバッチを受け取りましたが、問題はありません。 それを挿入すると、すべてが正常に動作します。 しかし、もちろん、あらゆる種類のシナリオが可能です。 たとえば、データが生成されるサーバーが多数ある場合です。 また、データの挿入頻度はそれほど高くありませんが、それでも頻繁に挿入が行われることになります。 そして、これを何とか回避する必要があります。

技術的な観点から見ると、重要なのは、ClickHouse で挿入を行うときに、データがどの memtable にも入らないということです。 ログも memTable も存在しないため、実際のログ構造 MergeTree はなく、単なる MergeTree です。 すでに列に配置されているデータをただちにファイル システムに書き込むだけです。 また、列が 100 個ある場合は、200 を超えるファイルを別のディレクトリに書き込む必要があります。 これはすべて非常に面倒です。

そして、何らかの方法で ClickHouse にデータを記録する必要がある状況の場合、「どうやって正しく行うのですか?」という疑問が生じます。

方法 1. これが最も簡単な方法です。 何らかの分散キューを使用します。 たとえば、カフカ。 Kafka からデータを抽出し、XNUMX 秒に XNUMX 回バッチ処理するだけです。 そして、すべてがうまくいき、録音すると、すべてがうまくいきます。

欠点は、Kafka がまたかさばる分散システムであることです。 あなたの会社にすでに Kafka が導入されている場合も理解できます。 いいですね、便利ですね。 しかし、それが存在しない場合は、さらに別の分散システムをプロジェクトにドラッグする前に、XNUMX 回考える必要があります。 したがって、代替案を検討する価値があります。

方法 2. これは昔ながらの代替手段であると同時に、非常に簡単です。 ログを生成する何らかのサーバーはありますか。 そして、ログをファイルに書き込むだけです。 たとえば、XNUMX 秒に XNUMX 回、このファイルの名前を変更し、新しいファイルを切り離します。 そして、cron または何らかのデーモンを介して別のスクリプトが最も古いファイルを取得し、ClickHouse に書き込みます。 ログを XNUMX 秒に XNUMX 回記録すれば、すべて問題ありません。

ただし、この方法の欠点は、ログが生成されているサーバーがどこかに消えてしまうと、データも消えてしまうということです。

方法 3. もう XNUMX つの興味深い方法があります。これは一時ファイルをまったく必要としません。 たとえば、ある種の広告スピナーや、データを生成するその他の興味深いデーモンがあるとします。 また、大量のデータを RAM やバッファに直接蓄積できます。 そして、十分な時間が経過したら、このバッファを脇に置いて、新しいバッファを作成し、別のスレッドで、すでに蓄積されているものを ClickHouse に挿入します。

一方、kill -9ではデータも消えます。 サーバーがクラッシュすると、このデータが失われます。 もう XNUMX つの問題は、データベースに書き込むことができなかった場合、データが RAM に蓄積されることです。 そして、RAMが足りなくなるか、単にデータが失われるかのどちらかです。

方法 4. もう XNUMX つの興味深い方法です。 何らかのサーバープロセスがあるのでしょうか？ また、ClickHouse にデータをすぐに送信できますが、それは XNUMX 回の接続で実行されます。 たとえば、transfer-encoding: chunked with insert を使用して http リクエストを送信しました。 また、チャンクが生成されることはそれほどまれではないため、各行を送信できますが、このデータをフレーム化するためのオーバーヘッドは発生します。

ただし、この場合、データはすぐに ClickHouse に送信されます。 そして、ClickHouse 自体がそれらをバッファリングします。

しかし、問題も生じます。 これで、不完全な挿入となるため、プロセスが強制終了された場合や ClickHouse プロセスが強制終了された場合も含めて、データが失われます。 また、ClickHouse では、行のサイズが特定の指定されたしきい値までは挿入がアトミックになります。 原理的には、これは興味深い方法です。 も使用できます。

方法 5. もう XNUMX つの興味深い方法があります。 これは、コミュニティが開発したデータのバッチ処理用のサーバーの一種です。 自分で調べたわけではないので、何の保証もできません。 ただし、ClickHouse 自体については保証はありません。 これもオープンソースですが、一方で、私たちが提供しようとしている品質基準に慣れているかもしれません。 しかし、これについては、わかりません。GitHub にアクセスして、コードを見てください。 もしかしたら普通のことを書いたのかもしれない。

※2020年現在も検討に加えるべき 子猫ハウス.

方法 6. もう XNUMX つの方法は、バッファ テーブルを使用することです。 この方法の利点は、使用を開始するのが非常に簡単であることです。 バッファ テーブルを作成し、そこに挿入します。

欠点は、問題が完全に解決されていないことです。 MergeTree のようなレートで 10 秒あたり 000 バッチでデータをグループ化する必要がある場合、バッファ テーブルのレートでは、少なくとも XNUMX 秒あたり最大数千までグループ化する必要があります。 XNUMX 秒あたり XNUMX を超える場合は、まだ問題があります。 これをバッチで挿入すると、XNUMX 秒あたり XNUMX 万行になることがわかりました。 そして、これはすでにかなり重いデータに基づいています。

また、バッファテーブルにはログがありません。 また、サーバーに問題がある場合、データは失われます。

おまけに、最近 ClickHouse で Kafka からデータを取得する機会を得ました。 Kafka というテーブル エンジンがあります。 ただ作成するだけです。 そして、実体化された表現をそこに掛けることができます。 この場合、それ自体が Kafka からデータを抽出し、必要なテーブルに挿入します。

そして、この機会で特に嬉しいのは、それを行ったのが私たちではないということです。 これはコミュニティ機能です。 私が「コミュニティ機能」と言うときは、決して軽蔑するつもりはありません。 コードを読んでレビューしましたが、問題なく動作するはずです。

※2020年現在、同様のサポートが登場しています。 RabbitMQの.

データを挿入するときに他に不便または予期しないことが考えられるものは何ですか? 値の挿入リクエストを作成し、値にいくつかの計算式を記述する場合。 たとえば、now() も計算式です。 この場合、ClickHouse はこれらの式のインタープリタを各行で起動する必要があり、パフォーマンスが桁違いに低下します。 これは避けた方が良いでしょう。

* 現時点では、問題は完全に解決されており、VALUES で式を使用するときにパフォーマンスが低下することはなくなりました。

もう XNUMX つの例は、多数のパーティションに属する XNUMX つのバッチにデータがあるときに問題が発生する可能性がある場合です。 デフォルトでは、ClickHouse パーティションは月ごとです。 また、XNUMX 万行のバッチを挿入し、数年分のデータがある場合、そこには数十のパーティションが存在することになります。 これは、内部で常に最初にパーティションに分割されるため、サイズが数十倍小さいバッチが存在するという事実と同等です。

* 最近、ClickHouse は実験モードで、チャンクと先行書き込みログを備えた RAM 内のチャンクのコンパクト フォーマットのサポートを追加しました。これにより、問題はほぼ完全に解決されました。

次に、XNUMX 番目のタイプの問題であるデータ型を見てみましょう。

データ型指定は厳密または文字列にすることができます。 String は、それを取得して、すべてのフィールドが文字列型であると宣言したときのものです。 これは最低だ。 これを行う必要はありません。

フィールドや文字列があることを伝えたい場合に、それを正しく行う方法を考えてみましょう。ClickHouse にそれを自動的に理解させます。私は気にしません。 しかし、それでも努力する価値はあります。

たとえば、IP アドレスがあります。 あるケースでは、それを文字列として保存しました。 たとえば、192.168.1.1。 また、別のケースでは、UInt32* 型の数値になります。 IPv32 アドレスには 4 ビットで十分です。

まず、奇妙なことに、データはほぼ均等に圧縮されます。 もちろん違いはあるでしょうが、それほど大きな違いはありません。 したがって、ディスク I/O に特別な問題はありません。

ただし、プロセッサ時間とクエリ実行時間には大きな違いがあります。

一意の IP アドレスが数値として保存されている場合は、その数を数えてみましょう。 これは、137 秒あたり 37 億 4 万行に相当します。 同じものが文字列の形式の場合、XNUMX 秒あたり XNUMX 万行になります。 なぜこのような偶然が起こったのかはわかりません。 私はこれらの要求を自分で実行しました。 ただし、それでも約 XNUMX 倍遅くなります。

そして、ディスク容量の違いを計算すると、やはり違いがあります。 固有の IP アドレスが非常に多く存在するため、その差は約 XNUMX 分の XNUMX です。 そして、少数の異なる意味を持つ行がある場合、それらは辞書に従って簡単にほぼ同じボリュームに圧縮されます。

そして、XNUMX倍のタイム差は道路上にあるわけではありません。 もちろん気にしないかもしれませんが、これほどの違いを見ると悲しくなります。

さまざまなケースを見てみましょう。

1. 異なる一意の値がほとんどない場合の XNUMX つのケース。 この場合、おそらくご存知であり、どの DBMS にも使用できる簡単な方法を使用します。 これはすべて、ClickHouse だけでなく理にかなっています。 数値識別子をデータベースに書き込むだけです。 また、アプリケーション側で文字列に変換したり、元に戻すこともできます。

たとえば、地域があるとします。 そしてそれを文字列として保存しようとしています。 そしてそこには「モスクワとモスクワ地方」と書かれるでしょう。 そして、「モスクワ」と書かれているのを見ると、何でもないのですが、モスクワになると、なぜか完全に悲しくなります。 これはバイト数です。

代わりに、Ulnt32 と 250 という数字を書き留めるだけです。Yandex には 250 がありますが、実際の数字は異なる場合があります。 念のため言っておきますが、ClickHouse にはジオベースを操作する機能が組み込まれています。 階層的なものを含む領域を含むディレクトリを書き留めるだけです。つまり、モスクワ、モスクワ地域、および必要なものがすべて存在します。 リクエストレベルで変換することもできます。

4 番目のオプションはほぼ同じですが、ClickHouse 内でサポートされています。 これは Enum データ型です。 Enum 内に必要な値をすべて書き込むだけです。 たとえば、デバイスの種類とそこに書き込みます: デスクトップ、モバイル、タブレット、テレビ。 合計 XNUMX つのオプションがあります。

欠点は、定期的に変更する必要があることです。 オプションがXNUMXつ追加されただけです。 テーブルを変更してみましょう。 実際、ClickHouse のテーブルの変更は無料です。 Enum の場合はディスク上のデータが変更されないため、特に無料です。 ただし、alter はテーブルのロック* を取得するため、すべての選択が実行されるまで待機する必要があります。 そして、この変更が実行された後にのみ、つまり、まだいくつかの不都合が存在します。

* ClickHouse の最新バージョンでは、ALTER は完全にノンブロッキングになっています。

ClickHouse にとって非常にユニークなもう XNUMX つのオプションは、外部辞書の接続です。 ClickHouse に数字を書き込んで、都合の良いシステムにディレクトリを保存できます。 たとえば、MySQL、Mongo、Postgres を使用できます。 このデータを http 経由で送信する独自​​のマイクロサービスを作成することもできます。 そして、ClickHouse レベルで、このデータを数値から文字列に変換する関数を作成します。

これは、外部テーブルで結合を実行する特殊な方法ですが、非常に効率的です。 そして、選択肢は XNUMX つあります。 一実施形態では、このデータは完全にキャッシュされ、ＲＡＭ内に完全に存在し、ある頻度で更新される。 また、別のオプションでは、このデータが RAM に収まらない場合は、部分的にキャッシュすることができます。

ここに例を示します。 Yandex.Direct があります。 そして広告会社とバナーがあります。 広告会社はおそらく数千万社あると思われます。 そしてそれらはRAMにほぼ収まります。 そして、何十億ものバナーがありますが、それらは収まりません。 そして、MySQL のキャッシュされた辞書を使用します。

唯一の問題は、ヒット率が 100% に近い場合、キャッシュされた辞書が正常に動作することです。 それが小さい場合は、データのバッチごとにクエリを処理するときに、実際には不足しているキーを取得して MySQL からデータを取得する必要があります。 ClickHouse については、速度が低下することはないとまだ保証できます。他のシステムについては話しません。

さらに、辞書は、ClickHouse のデータを遡って更新する非常に簡単な方法です。 つまり、広告会社に関するレポートがあり、ユーザーが広告会社を変更しただけで、すべての古いデータ、すべてのレポートでこのデータも変更されました。 行をテーブルに直接書き込む場合、行を更新することはできません。

文字列の識別子をどこで取得すればよいかわからない場合の別の方法。 単純にハッシュ化することができます。 さらに、最も簡単なオプションは 64 ビット ハッシュを取得することです。

唯一の問題は、ハッシュが 64 ビットの場合、ほぼ確実に衝突が発生することです。 なぜなら、そこにXNUMX億の行があれば、その確率はすでに顕著になるからです。

このように広告会社の名前をハッシュ化するのはあまり良いことではありません。 異なる企業の広告キャンペーンが混ざってしまうと、訳の分からないものになってしまいます。

そして、簡単なトリックがあります。 確かに、これは深刻なデータにはあまり適していませんが、それほど深刻でない場合は、クライアント識別子を辞書キーに追加するだけです。 そして、衝突が発生しますが、それは XNUMX つのクライアント内でのみです。 そして、Yandex.Metrica のリンク マップにこのメソッドを使用します。 そこに URL があり、ハッシュを保存します。 そしてもちろん、衝突があることも承知しています。 しかし、ページが表示されるときに、XNUMX 人のユーザーの XNUMX ページにいくつかの URL がくっついていて、それに気づく確率は無視できます。

おまけに、多くの操作ではハッシュだけで十分であり、文字列自体をどこにも保存する必要はありません。

別の例としては、Web サイトのドメインなど、文字列が短い場合があります。 そのまま保管できます。 たとえば、ブラウザ言語の ru は 2 バイトです。 もちろんバイトは本当に残念ですが、2バイトは残念ではありませんのでご安心ください。 心配しないでそのままにしておいてください。

もう XNUMX つのケースは、逆に、多くの行があり、その中に多くの固有の行があり、セットですら潜在的に無制限である場合です。 典型的な例は、検索フレーズや URL です。 タイプミスを含む語句を検索します。 XNUMX 日あたりの一意の検索フレーズが何件あるか見てみましょう。 そして、それらがすべてのイベントのほぼ半分であることがわかりました。 この場合、データを正規化し、識別子を数えて、別のテーブルに入れる必要があると考えるかもしれません。 しかし、その必要はありません。 これらの行はそのままにしておいてください。

個別に保存すると結合が必要になるため、何も考え出さないほうが良いでしょう。 そして、この結合は、まだメモリに収まる場合には、せいぜいメモリへのランダム アクセスです。 適合しない場合は問題が発生します。

データが所定の場所に保存されている場合は、ファイル システムから必要な順序で読み取られるだけで、すべて問題ありません。

URL やその他の複雑な長い文字列がある場合は、事前に何らかの抽出を計算して別の列に書き込むことができることを検討する価値があります。

たとえば、URL の場合、ドメインを個別に保存できます。 本当にドメインが必要な場合は、この列を使用するだけで、URL はそこにあり、触れる必要もありません。

何が違うのか見てみましょう。 ClickHouse にはドメインを計算する特殊な機能があります。 非常に高速であり、最適化されています。 正直に言うと、RFC にも準拠していませんが、それでも必要なものはすべて考慮されています。

あるケースでは、単純に URL を取得してドメインを計算します。 これは 166 ミリ秒になります。 既製のドメインを使用すると、わずか 67 ミリ秒、つまりほぼ XNUMX 倍高速になることがわかります。 また、計算が必要になるためではなく、読み取るデータが少なくなるため、高速になります。

そのため、XNUMX つのリクエストは低速ですが、XNUMX 秒あたりのギガバイトの速度が高くなります。 より多くのギガバイトを読み取るためです。 全く不要なデータです。 リクエストの実行は速くなったように見えますが、完了までに時間がかかります。

ディスク上のデータ量を見ると、URL は 126 メガバイト、ドメインはわずか 5 メガバイトであることがわかります。 25倍少ないことがわかります。 ただし、それでも、リクエストの実行速度はわずか 4 倍です。 しかし、それはデータがホットだからです。 また、寒い場合は、ディスク I/O により、おそらく 25 倍高速になるでしょう。

ちなみに、ドメインが URL に比べてどのくらい小さいかを見積もると、約 4 倍小さいことがわかりますが、何らかの理由で、ディスク上に占めるデータの占有量は 25 分の XNUMX になります。 なぜ？ 圧縮のため。 URL もドメインも圧縮されます。 しかし、多くの場合、URL には大量のゴミが含まれています。

そしてもちろん、目的の値に合わせて特別に設計された、または適切なデータ型を使用することには価値があります。 IPv4 を使用している場合は、UInt32* を格納します。 IPv6 の場合、IPv16 アドレスは 6 ビットであるため、FixedString(128) になります。つまり、バイナリ形式で直接保存されます。

しかし、IPv4 アドレスを使用する場合と IPv6 を使用する場合がある場合はどうなるでしょうか? はい、両方保管できます。 4 つの列は IPv6 用で、もう 4 つの列は IPv6 用です。 もちろん、IPv4 を IPvXNUMX で表示するオプションもあります。 これでも機能しますが、リクエストで IPvXNUMX アドレスが頻繁に必要になる場合は、別の列に入れるとよいでしょう。

* ClickHouse には、数値と同じくらい効率的にデータを保存しながら、文字列と同じくらい簡単にデータを表現できる個別の IPv4、IPv6 データ型が追加されました。

事前にデータを前処理する価値があることに注意することも重要です。 たとえば、生のログをいくつか受け取ったとします。 そして、すぐに ClickHouse に入れるべきではないかもしれませんが、何もせずにすべてがうまくいくように誘惑されます。 しかし、それでも可能な計算を実行する価値はあります。

たとえば、ブラウザのバージョン。 指を指したくない近くの部門では、ブラウザのバージョンが次のように、つまり文字列として保存されています: 12.3. 次に、レポートを作成するために、この文字列を配列に分割し、さらに配列の最初の要素に分割します。 当然のことながら、すべてが遅くなります。 なぜそんなことをするのかと尋ねました。 彼らは時期尚早な最適化が好きではないと私に言いました。 そして私は時期尚早に悲観するのが好きではありません。

したがって、この場合は 4 つの列に分割する方が正確です。 ここは ClickHouse なので、心配しないでください。 ClickHouse は列型データベースです。 そして、小さな列がきちんとしていればいるほど良いのです。 5 つのブラウザバージョンがあり、5 つの列を作成します。 これで大丈夫です。

ここで、非常に長い文字列や非常に長い配列が多数ある場合にどうすればよいかを見てみましょう。 ClickHouse に保存する必要はまったくありません。 代わりに、ClickHouse には識別子のみを保存できます。 そして、これらの長い行を他のシステムに入れてください。

たとえば、当社の分析サービスの 512 つは、いくつかのイベント パラメーターを持っています。 イベントのパラメーターが多数ある場合は、最初に見つかった 512 を保存します。XNUMX は残念ではないからです。

データ タイプを決定できない場合は、ClickHouse にデータを記録することもできますが、一時データ専用のログ タイプの一時テーブルにデータを記録することもできます。 その後、そこにどのような値の分布があるのか​​、一般的に何が存在するのかを分析し、正しいタイプを作成できます。

*ClickHouse にデータ型が追加されました 低カーディナリティ これにより、少ない労力で効率的に文字列を保存できます。

次に、別の興味深い事例を見てみましょう。 時々物事が人々にとって奇妙に機能することがあります。 入ってきてこれを見ます。 そして、これは MySQL バージョン 3.23 のセットアップに豊富な経験を持つ、非常に経験豊富で聡明な管理者によって行われたものであることがすぐにわかりました。

ここには XNUMX のテーブルがあり、それぞれのテーブルには誰が何を知っているかを XNUMX で割った余りが記録されています。

私は原則として、他の人の経験を尊重します。これには、その経験を通じて得られる苦しみの理解も含まれます。

そしてその理由は多かれ少なかれ明らかです。 これらは、他のシステムを使用している間に蓄積された可能性のある古い固定観念です。 たとえば、MyISAM テーブルにはクラスター化された主キーがありません。 そして、このデータの分割方法は、同じ機能を実現するための必死の試みである可能性があります。

もう XNUMX つの理由は、大きなテーブルに対して変更操作を実行するのが難しいことです。 すべてがブロックされてしまいます。 ただし、最新バージョンの MySQL では、この問題はそれほど深刻ではなくなりました。

または、たとえばマイクロシャーディングですが、これについては後で詳しく説明します。

ClickHouse ではこれを行う必要はありません。まず、主キーがクラスター化され、データが主キーによって順序付けされるためです。

また、時々、「ClickHouse の範囲クエリのパフォーマンスは、テーブル サイズに応じてどのように変化しますか?」と尋ねられることがあります。 全く変わらないと言います。 たとえば、XNUMX 億行のテーブルがあり、XNUMX 万行の範囲を読み取るとします。 すべて順調。 テーブルに XNUMX 兆行あり、XNUMX 万行を読み取る場合、それはほぼ同じになります。

そして第 XNUMX に、手動パーティションなどのあらゆる作業が必要ありません。 ファイル システム上にあるものを調べてみると、テーブルが非常に重要であることがわかります。 そして中には仕切りのようなものがあります。 つまり、ClickHouse がすべてを行ってくれるので、苦しむ必要はありません。

ClickHouse での変更は、列の追加/ドロップを変更する場合は無料です。

また、テーブルに 10 行または 10 行がある場合は、まったく問題ないため、小さなテーブルを作成しないでください。 ClickHouse はレイテンシーではなくスループットを最適化するシステムであるため、000 行を処理するのは意味がありません。

大きなテーブルを XNUMX つ使用するのが正しいです。 古い固定観念を取り除きましょう。すべてがうまくいきます。

さらに、最新バージョンでは、個々のパーティションに対してあらゆる種類のメンテナンス操作を実行するために、任意のパーティション キーを作成できるようになりました。

たとえば、中間データを処理する必要がある場合、チャンクを受け取り、最終テーブルに書き込む前にそれらのチャンクに対して変換を実行する必要がある場合など、多数の小さなテーブルが必要です。 このケースには、StripeLog という素晴らしいテーブル エンジンがあります。 これは TinyLog に似ていますが、それより優れているだけです。

* 現在、ClickHouse にもあります テーブル関数の入力.

もう 5 つのアンチパターンはマイクロシャーディングです。 たとえば、データをシャーディングする必要があり、サーバーが 6 台あり、明日にはサーバーが 5 台になるとします。 そして、このデータをリバランスする方法を考えます。 その代わりに、1 つのシャードではなく 000 のシャードに分割します。 次に、これらの各マイクロシャードを別のサーバーにマッピングします。 たとえば、200 つのサーバー上で XNUMX の ClickHouse を取得できます。 個別のポートまたは個別のデータベース上の個別のインスタンス。

しかし、これはClickHouseではあまり良くありません。 56 つの ClickHouse インスタンスでも、56 つのリクエストを処理するために利用可能なすべてのサーバー リソースを使用しようとするためです。 つまり、ある種のサーバーがあり、たとえば 200 個のプロセッサ コアが搭載されているとします。 10 秒かかるクエリを実行すると、000 コアが使用されます。 そして、XNUMX つのサーバー上に XNUMX の ClickHouse を配置すると、XNUMX のスレッドが開始されることがわかります。 一般に、すべてが非常に悪くなります。

もう XNUMX つの理由は、これらのインスタンス間での作業の分散が不均一になることです。 早く終わる人もいれば、遅く終わる人もいます。 これらすべてが XNUMX つのインスタンスで発生した場合、ClickHouse 自体がスレッド間でデータを正しく分散する方法を見つけ出すでしょう。

もう XNUMX つの理由は、TCP 経由でプロセッサ間通信を行うことです。 データはシリアル化、逆シリアル化する必要があり、これは膨大な数のマイクロシャードになります。 それは単に効果的に機能しません。

これもアンチパターンとは言えませんが、アンチパターンです。 これは大量の事前集計です。

一般に、事前集計は適切です。 1 億行があり、それを集計すると 000 行になり、クエリが即座に実行されるようになりました。 すべてが素晴らしいです。 あなたはこれを行うことができます。 このため、ClickHouse にも AggregatingMergeTree という特別なテーブル タイプがあり、データが挿入されると増分集計を実行します。

しかし、「このようにデータを集計し、このようにデータを集計する」と考えることがあります。 また、隣の部門では、どことは言いませんが、SummingMergeTree テーブルを使用して主キーで集計しており、約 20 列が主キーとして使用されています。 念のため、機密保持のためにいくつかの列の名前を変更しましたが、ほぼそれだけです。

そして、このような問題が生じます。 まず、データ量があまり減りません。 例えばXNUMX倍に減ります。 データが集約されていない場合に生じる無制限の分析機能を利用するには、XNUMX 倍が妥当な価格です。 データが集約されている場合、分析の代わりに得られるのは悲惨な統計だけです。

そして、それの何がそんなに特別なのでしょうか？ 実際、隣の部門の担当者が、主キーに別の列を追加するように依頼しに行くことがあります。 つまり、このようにデータを集計しましたが、もう少し多くのデータが必要になります。 ただし、ClickHouse には変更主キーがありません。 したがって、いくつかのスクリプトを C++ で記述する必要があります。 そして、たとえそれが C++ であっても、私はスクリプトが好きではありません。

ClickHouse が何のために作られたのかを見ると、非集計データはまさにそれが生まれたシナリオです。 非集計データに ClickHouse を使用している場合、それは正しく行われています。 集計すれば、これは許容できる場合もあります。

もう XNUMX つの興味深いケースは、無限ループ内のクエリです。 時々、私は実稼働サーバーに行き、そこで show processlist を確認します。 そしてそのたびに、何か恐ろしいことが起こっていることに気づきます。

たとえば、このように。 XNUMX 回のリクエストですべてを実行できることがすぐにわかります。 URLとリストをそこに書き込むだけです。

無限ループにあるこのようなクエリの多くが問題となるのはなぜでしょうか? インデックスが使用されていない場合は、同じデータに対して何度もパスすることになります。 しかし、インデックスが使用されている場合、たとえば ru の主キーがあり、そこに url = 何かを書き込みます。 そして、テーブルから URL が XNUMX つだけ読み取られれば、すべて問題ないと考えます。 しかし、実際には違います。 ClickHouse はすべてをバッチで実行するためです。

ClickHouse のインデックスがまばらであるため、特定の範囲のデータを読み取る必要がある場合は、もう少し多く読み取ります。 このインデックスを使用すると、テーブル内の XNUMX つの個別の行を検索することはできず、ある種の範囲のみを検索できます。 そして、データはブロック単位で圧縮されます。 XNUMX 行を読み取るには、ブロック全体を取り出し、ブロックを解く必要があります。 また、大量のクエリを実行している場合は、重複する部分が多くなり、何度も繰り返し実行する必要がある作業が多くなります。

おまけに、ClickHouse では、たとえメガバイトや数百メガバイトであっても、IN セクションに転送することを恐れる必要はないことに注意してください。 私たちの実践から思い出したのですが、MySQL で大量の値を IN セクションに転送すると、たとえばそこに 100 メガバイトの数値を転送すると、MySQL は 10 ギガバイトのメモリを消費し、他には何も起こりません。動作が悪い。

XNUMX つ目は、ClickHouse では、クエリでインデックスが使用されている場合、常にフル スキャンよりも遅くないことです。つまり、テーブルのほぼ全体を読み取る必要がある場合、シーケンシャルに実行してテーブル全体を読み取ります。 一般的に、彼は自分でそれを理解します。

しかし、それでもいくつかの困難があります。 たとえば、サブクエリを使用した IN はインデックスを使用しないことです。 しかし、これは私たちの問題であり、解決する必要があります。 ここには基本的なものは何もありません。 修正させていただきます*。

もう 100 つの興味深い点は、非常に長いリクエストがあり、分散リクエスト処理が進行中の場合、この非常に長いリクエストは圧縮されずに各サーバーに送信されることです。 たとえば、500 メガバイトと 50 サーバーなどです。 したがって、ネットワーク上で XNUMX ギガバイトが転送されることになります。 それが送信され、すべてが正常に完了します。

* すでに使用しています; すべてが約束どおりに修正されました。

そして、かなり一般的なケースは、リクエストが API から送信される場合です。 たとえば、独自のサービスを作成したとします。 そして、誰かがあなたのサービスを必要としている場合、API を開くと、文字通り XNUMX 日後に理解できないことが起こっていることに気づきます。 すべてが過負荷になり、決して起こるべきではなかったひどいリクエストがいくつか入ってきます。

そして、解決策は XNUMX つだけです。 API を公開している場合は、それを切断する必要があります。 たとえば、ある種のノルマを導入します。 他に通常のオプションはありません。 そうしないと、すぐにスクリプトが作成され、問題が発生します。

そして、ClickHouse にはクォータ計算という特別な機能があります。 さらに、クォータ キーを転送することもできます。 これは、たとえば内部ユーザー ID です。 そして、クォータはそれぞれに対して個別に計算されます。

さて、もう一つ興味深いことがあります。 これは手動レプリケーションです。

ClickHouse にはレプリケーション サポートが組み込まれているにもかかわらず、ClickHouse を手動でレプリケートしているケースを私は多く知っています。

原理は何ですか? データ処理パイプラインがあります。 また、たとえば、異なるデータセンターでも独立して動作します。 ClickHouse では同じデータを同じ方法で書き込みます。 確かに、実際にやってみると、コード内のいくつかの機能によってデータが依然として分岐することがわかります。 それがあなたの中にあることを願っています。

また、場合によっては手動で同期する必要があります。 たとえば、管理者は月に XNUMX 回 rsync を実行します。

実際、ClickHouse に組み込まれているレプリケーションを使用する方がはるかに簡単です。 ただし、ZooKeeper を使用する必要があるため、いくつかの禁忌がある可能性があります。 ZooKeeper について悪いことは言いません。原則として、システムは機能しますが、Java 恐怖症のせいで ZooKeeper を使用しない人もいます。ClickHouse は C++ で書かれた非常に優れたシステムであり、自由に使用できます。すべてうまくいきます。 ZooKeeper は Java にあります。 どういうわけか、見たくない場合でも、手動レプリケーションを使用できます。

ClickHouse は実用的なシステムです。 彼女はあなたのニーズを考慮に入れてくれます。 手動レプリケーションがある場合は、手動レプリカを参照してそれらの間でフェイルオーバーを実行する分散テーブルを作成できます。 また、ラインが系統的に分岐している場合でもフロップを回避できる特別なオプションもあります。

プリミティブ テーブル エンジンを使用すると、さらに問題が発生する可能性があります。 ClickHouse は、さまざまなテーブル エンジンを多数備えたコンストラクターです。 ドキュメントに記載されているように、すべての深刻な場合には、MergeTree ファミリのテーブルを使用してください。 そして残りのすべて - これは、個々のケースまたはテストの場合に当てはまります。

MergeTree テーブルでは、日付と時刻は必要ありません。 まだお使いいただけます。 日付と時刻がない場合は、デフォルトが 2000 であることを書き込みます。 これは機能し、リソースは必要ありません。

また、サーバーの新しいバージョンでは、パーティション キーを使用せずにカスタム パーティション化を指定することもできます。 それも同じだろう。

一方、プリミティブなテーブル エンジンを使用することもできます。 たとえば、データを一度入力して、見て、ひねり、削除します。 ログを使用できます。

あるいは、中間処理用に少量を保存するには、StripeLog または TinyLog を使用します。

データ量が少なく、RAM 内で何かをいじるだけで済む場合は、メモリを使用できます。

ClickHouse は再正規化されたデータをあまり好みません。

典型的な例を次に示します。 これは膨大な数の URL です。 それらを次のテーブルに置きます。 そして、JOIN を実行することにしましたが、ClickHouse は Hash JOIN のみをサポートしているため、これは原則として機能しません。 接続する必要がある大量のデータを処理できる十分な RAM がない場合、JOIN は機能しません*。

データのカーディナリティが高い場合は、心配する必要はありません。非正規化形式で保存してください。URL はメイン テーブルに直接配置されます。

* そして現在、ClickHouse にはマージ結合もあり、中間データが RAM に収まらない状況でも機能します。 しかし、これは効果がなく、勧告は引き続き有効です。

他にもいくつか例がありますが、それらがアンチパターンであるかどうかはすでに疑問です。

ClickHouse には既知の欠陥が XNUMX つあります。 アップデート方法がわかりません*。 ある意味では、これは良いことです。 会計などの重要なデータがある場合、更新がないため、誰もそれを送信できません。

* バッチ モードでの更新と削除のサポートはかなり前に追加されました。

ただし、バックグラウンドであるかのように更新できる特別な方法がいくつかあります。 たとえば、ReplaceMergeTree のようなテーブルです。 バックグラウンドのマージ中に更新が行われます。 テーブルの最適化を使用してこれを強制できます。 ただし、パーティションを完全に上書きしてしまうため、これを頻繁に実行しないでください。

ClickHouse の分散 JOIN も、クエリ プランナーでは適切に処理されません。

悪いけど、たまにはOK。

select* を使用してデータを読み取る場合にのみ ClickHouse を使用します。

面倒な計算に ClickHouse を使用することはお勧めしません。 しかし、私たちはすでにこの推奨事項から離れつつあるため、これは完全に真実ではありません。 そして最近、ClickHouse - Catboost に機械学習モデルを適用する機能を追加しました。 そして、「何という恐ろしいことだろう」と思うので、それは私を悩ませます。 これは、XNUMX バイトあたりのサイクル数です。 私はバイトにクロックを無駄にするのが本当に嫌いです。

でも、心配しないで、ClickHouse をインストールすれば、すべてうまくいきます。 どちらかというと、私たちにはコミュニティがあります。 ちなみに、コミュニティとはあなた自身のことです。 何か問題がある場合は、少なくとも私たちのチャットにアクセスしてください。助けてくれることを願っています。

質問

ご報告ありがとうございます！ ClickHouse のクラッシュについてどこに苦情を申し立てればよいですか?

今すぐ私に個人的に苦情を言ってもいいでしょう。

最近クリックハウスを使い始めました。 私はすぐに cli インターフェースを削除しました。

あなたはラッキーです。

少し後、小さな選択でサーバーをクラッシュさせました。

あなたには才能があります。

GitHub のバグをオープンしましたが、無視されました。

見るでしょう。

アレクセイは私をだまして報告書に参加させ、内部のデータにどのようにアクセスするかを教えると約束しました。

非常にシンプル。

昨日そのことに気づきました。 さらに詳しく。

そこには恐ろしいトリックはありません。 あるのはブロックごとの圧縮だけです。 デフォルトは LZ4 ですが、ZSTD* を有効にすることができます。 64 キロバイトから 1 メガバイトまでのブロック。

* 他のアルゴリズムとチェーンで使用できる特殊な圧縮コーデックのサポートもあります。

ブロックは単なる生データですか?

完全に生ではありません。 配列があります。 数値列がある場合、行内の数値が配列に配置されます。

明らかです。

Alexey、IP 経由の uniqExact の例、つまり、uniqExact は数値よりも行で計算する方が時間がかかるという事実など。 校正時に耳でフェイントをかけてキャストしてみたらどうでしょうか？ つまり、私たちのディスクではそれほど違いはないとおっしゃったようですね。 ディスクから行を読み取ってキャストすると、集計は速くなりますか? それとも、ここでもまだわずかに利益を得るでしょうか？ これをテストしたようですが、何らかの理由でベンチマークに示されませんでした。

キャストしないよりも遅くなると思います。 この場合、IP アドレスを文字列から解析する必要があります。 もちろん、ClickHouse では、IP アドレス解析も最適化されています。 私たちは一生懸命努力しましたが、そこには一万分の１の形式で数字が書かれています。 とても不快です。 一方、uniqExact 関数は文字列に対しては動作が遅くなります。これは、文字列であるだけでなく、アルゴリズムの異なる特殊化が選択されているためです。 文字列は単純に異なる方法で処理されます。

もっと原始的なデータ型を採用したらどうなるでしょうか? たとえば、ユーザーIDをメモして、それを一行書いてスクランブルしたほうが楽しいでしょうか、そうでないでしょうか。

私は疑う。 結局のところ、数字の解析は深刻な問題なので、さらに悲しいことになると思います。 この同僚は、XNUMX万分のXNUMXの形式で数値を解析することがいかに難しいかについて報告さえしたように思えますが、おそらくそうではありません。

アレクセイさん、ご報告ありがとうございます！ そしてClickHouseを本当にありがとう！ 計画について質問があります。 辞書を不完全に更新する機能の計画はありますか?

つまり、部分的な再起動ですか?

はいはい。 そこに MySQL フィールドを設定する機能と同様です。つまり、ディクショナリが非常に大きい場合は、このデータのみがロードされるように後で更新します。

非常に興味深い機能です。 そして、チャットで誰かがそれを提案したと思います。 もしかしたらあなたもそうだったかもしれません。

私はそうは思わない。

なるほど、リクエストが XNUMX つあることがわかりました。 そして、ゆっくりとそれを始めることができます。 ただし、この機能の実装は非常に簡単であることをすぐに警告したいと思います。 つまり、理論的には、テーブルにバージョン番号を書き込んでから、「バージョン未満のバージョン」と記述するだけです。 これは、おそらくこれを愛好家に提供することを意味します。 あなたは愛好家ですか？

はい、しかし残念ながら C++ ではできません。

あなたの同僚は C++ での書き方を知っていますか?

誰か見つけます。

素晴らしい*。

* この機能はレポートの XNUMX か月後に追加されました。質問の作成者がそれを開発し、送信しました。 プル要求.

ありがとうございます！

こんにちは！ ご報告ありがとうございます！ ClickHouse は利用可能なリソースをすべて消費するのが非常に上手だとおっしゃいました。 そして、Luxoft の隣の講演者は、Russian Post に対するソリューションについて話しました。 彼は、彼らは ClickHouse を非常に気に入っていたが、CPU をすべて使い果たしていたため、主な競合他社の代わりにそれを使用しなかったと述べました。 そして、それを自分たちのアーキテクチャや Docker を使った ZooKeeper に組み込むこともできませんでした。 ClickHouse が利用できるものをすべて消費しないように、何らかの方法で ClickHouse を制限することはできますか?

はい、それは可能であり、非常に簡単です。 消費するコアを減らしたい場合は、次のように記述します。 set max_threads = 1。 これで、リクエストが XNUMX つのコアで実行されます。 さらに、ユーザーごとに異なる設定を指定できます。 それで問題ありません。 そして、Luxoft の同僚に、ドキュメントにこの設定が見つからなかったのは良くないと伝えてください。

アレクセイ、こんにちは！ この点についてお聞きしたいと思います。 多くの人が ClickHouse をログのストレージとして使い始めていると聞いたのはこれが初めてではありません。 レポートでは、これを行わない、つまり長い文字列を保存する必要がないと言っていました。 あなたはそれについてどう思いますか？

まず、ログは原則として長い文字列ではありません。 もちろん例外もあります。 たとえば、Java で書かれたサービスによっては例外がスローされ、ログに記録されます。 などという無限ループが繰り返され、ハードドライブの容量が不足してしまいます。 解決策はとても簡単です。 線が非常に長い場合は、カットしてください。 長いとはどういう意味ですか？ 数十キロバイトはダメです*。

* ClickHouse の最新バージョンでは、「適応インデックス粒度」が有効になっており、長い行を保存する問題はほとんど解決されています。

キロバイトって普通ですか？

それは正常です。

こんにちは！ ご報告ありがとうございます！ この件についてはチャットですでに質問しましたが、回答があったかどうか覚えていません。 CTE のように WITH セクションを何らかの方法で拡張する予定はありますか?

まだ。 WITH セクションはやや軽薄です。 私たちにとってはちょっとした機能のようなものです。

わかりました。 ありがとう！

ご報告ありがとうございます！ とても興味深い！ グローバルな質問。 おそらく何らかのスタブの形で、データの削除を変更する計画はありますか?

必然的に。 これはキュー内の最初のタスクです。 私たちは現在、すべてを正しく行う方法について積極的に考えています。 そしてキーボード*を押し始める必要があります。

* キーボードのボタンを押してすべてを実行しました。

これはシステムのパフォーマンスに何らかの影響を与えるのでしょうか? 挿入は今と同じくらい早くなりますか？

おそらく削除自体と更新自体は非常に重いものになるでしょうが、これは選択のパフォーマンスや挿入のパフォーマンスには影響しません。

そして、もう一つ小さな質問。 プレゼンテーションでは主キーについて話しました。 したがって、デフォルトでは月単位のパーティション分割が行われていますね。 そして、月に収まる日付範囲を設定すると、このパーティションのみが読み取られます。

はい。

質問。 主キーを選択できない場合、バックグラウンドでのこのデータの再配置が少なくなり、より順序よく収まるように、特に「日付」フィールドに従って選択するのは正しいでしょうか? 範囲クエリがなく、主キーを選択することさえできない場合、主キーに日付を入れる価値はありますか?

はい。

おそらく、このフィールドで並べ替える場合にデータをより適切に圧縮するフィールドを主キーに配置することが合理的である可能性があります。 たとえば、ユーザーID。 たとえば、ユーザーは同じサイトにアクセスします。 この場合、ユーザー ID と時刻を入力します。 そうすれば、データはより適切に圧縮されます。 日付に関しては、日付に対する範囲クエリが実際に存在せず、今後も実行しない場合は、主キーに日付を入れる必要はありません。

はい、ありがとうございます！

出所： habr.com