ClickHouse への移行: 3 年後

XNUMX年前、Yandexのヴィクトル・タルナフスキーとアレクセイ・ミロヴィドフがステージに登場 HighLoad ++ 言った、ClickHouseがどれほど優れているか、そしてそれがどれほど遅くならないか。 そして次のステージには、 アレクサンダー・ツァイトセフ с 報告 への引っ越しについて クリックハウス 別の分析 DBMS から得られた結論は、 クリックハウス、もちろん良いですが、あまり便利ではありません。 2016 年の時点で、同社は LifeStreetアレクサンダーが当時働いていた場所では、マルチペタバイトの分析システムを クリックハウスそれは、未知の危険に満ちた魅惑の“黄色いレンガ道”だった――。 クリックハウス 当時は地雷原のように見えました。

XNUMX年後 クリックハウス はるかに良くなりました - この間にアレクサンダーは、人々の移動を支援するだけでなく、Altinity という会社を設立しました。 クリックハウス 数十のプロジェクトに取り組んでいますが、Yandex の同僚と協力して製品自体も改善しています。 今 クリックハウス まだ気ままな散歩ではありませんが、もはや地雷原ではありません。

Alexander は 2003 年から分散システムに取り組んでおり、次のような大規模なプロジェクトを開発しています。 MySQL、Oracle и Vertica。 最後に HighLoad ++ 2019 アレクサンダー、使用の先駆者の XNUMX 人 クリックハウス、この DBMS が現在どのようなものであるかを説明しました。 主な機能について学びます クリックハウス: 他のシステムとどう違うのか、どのような場合に使用するとより効果的になるのか。 例を使用して、以下に基づいてシステムを構築するための、プロジェクトでテストされた最近の実践方法を見ていきます。 クリックハウス.

振り返り：3年前に何が起こったのか

XNUMX年前に会社を譲渡しました LifeStreet на クリックハウス 別の分析データベースからの広告ネットワーク分析の移行は次のようになります。

• 2016 年 XNUMX 月。 オープンソース 登場 クリックハウス そして私たちのプロジェクトが始まりました。
• 8月。 コンセプトの証明: 大規模な広告ネットワーク、インフラストラクチャ、および 200 ～ 300 テラバイトのデータ。
• XNUMX月。 最初の本番データ。
• 10月。 製品の全負荷は 50 日あたり XNUMX ～ XNUMX 億のイベントです。
• 2017 年 XNUMX 月。ユーザーの移行に成功。 クリックハウス, 2,5 台のサーバーからなるクラスター上の 60 ペタバイトのデータ。

移行プロセス中に、次のような理解が深まりました。 クリックハウス は快適に作業できる優れたシステムですが、これは Yandex の内部プロジェクトです。 したがって、微妙な違いがあります。Yandex は最初に自社の内部顧客に対応し、その後でコミュニティと外部ユーザーのニーズに対応しますが、ClickHouse は多くの機能分野でエンタープライズ レベルに達していませんでした。 だからこそ、私たちは 2017 年 XNUMX 月に Altinity を設立しました。 クリックハウス Yandex だけでなく、他のユーザーにとってもさらに高速かつ便利になります。 そして今、私たちは:

• 私たちはトレーニングを行い、以下に基づいたソリューションの構築を支援します。 クリックハウス 顧客がトラブルに巻き込まれないように、そしてソリューションが最終的に機能するように。
• 24時間7日サポートを提供します クリックハウス- 設置;
• 私たちは独自のエコシステム プロジェクトを開発しています。
• 私たちは自分自身に積極的にコミットします クリックハウス、特定の機能を確認したいユーザーからのリクエストに応えます。

もちろん引っ越しもお手伝いします クリックハウス с MySQL, Vertica, オラクル, グリーンプラム, レッドシフト およびその他のシステム。 私たちはさまざまな取り組みに参加しており、それらはすべて成功しています。

に移動する理由 クリックハウス

速度が落ちない！ これが主な理由です。 クリックハウス - さまざまなシナリオに対応する非常に高速なデータベース:

長い間人々と協力してきた人々からのランダムな引用 クリックハウス.

スケーラビリティ。 他のデータベースでは、XNUMX つのハードウェアで良好なパフォーマンスを達成できますが、 クリックハウス サーバーを追加するだけで、垂直方向だけでなく水平方向にも拡張できます。 すべてが期待どおりにスムーズに機能するわけではありませんが、うまくいきます。 ビジネスの成長に合わせてシステムを拡張できます。 重要なのは、現在のソリューションに制限されず、常に開発の可能性があることです。

携帯性。 一つのものに対する執着はありません。 たとえば、 Amazonレッドシフト どこかに移動するのは難しいです。 あ クリックハウス ラップトップやサーバーにインストールしたり、クラウドに展開したりできます。 Kubernetes — インフラストラクチャの運用に制限はありません。 これは誰にとっても便利であり、他の多くの同様のデータベースにはない大きな利点です。

柔軟性. クリックハウス Yandex.Metrica など、XNUMX つのものにとどまらず、ますます多くの異なるプロジェクトや業界で開発され、使用されています。 新しい問題を解決するために新しい機能を追加することで拡張できます。 たとえば、ログをデータベースに保存することはマナー違反であると考えられているため、次のようなことが考えられました。 Elasticsearch。 でも柔軟性のおかげで クリックハウス、ログを保存することもでき、多くの場合、これは よりもさらに優れています。 Elasticsearch - で クリックハウス これには必要な鉄の量が10分のXNUMXになります。

フリー オープンソース。 何も支払う必要はありません。 ラップトップまたはサーバーにシステムをインストールするための許可を交渉する必要はありません。 隠れた手数料はありません。 同時に、他のオープンソース データベース テクノロジは速度において競合できません。 クリックハウス. MySQL、MariaDB、Greenplum - それらはすべてはるかに遅いです。

コミュニティ、ドライブ、 楽しいです。 で クリックハウス 素晴らしいコミュニティ：交流会、チャット、そしてエネルギーと楽観主義で私たち全員を充電してくれるアレクセイ・ミロヴィドフ。

クリックハウスへの移行

に行くには クリックハウス 何らかの理由で、必要なのは次の XNUMX つだけです。

• 限界を理解する クリックハウス そしてそれが適さないもの。
• 利用する テクノロジーとその最大の強み。
• 実験。 仕組みを理解していても クリックハウス、いつ早くなるか、いつ遅くなるか、いつ良くなるか、いつ悪くなるかを常に予測できるわけではありません。 それで試してみてください。

引っ越し問題

「でも」は XNUMX つだけです。 クリックハウス 他の何かが原因で、通常は何か問題が発生します。 私たちは、お気に入りのデータベースで機能するいくつかのプラクティスや物事に慣れています。 たとえば、一緒に働いている人は誰でも、 SQL データベースでは、次の一連の関数が必須であると見なされます。

• 取引;
• 制約。
• 一貫性;
• インデックス
• 更新/削除;
• NULL;
• ミリ秒。
• 自動型キャスト。
• 複数の結合。
• 任意のパーティション。
• クラスター管理ツール。

募集は必須ですが、XNUMX年前に クリックハウス これらの機能はどれも利用できませんでした。 現在、トランザクション、制約、一貫性、ミリ秒、型キャストなど、実装されていないものは半分未満が残っています。

そして重要なことは、 クリックハウス 一部の標準的なプラクティスやアプローチは機能しなかったり、これまでと異なる方法で機能したりします。 に登場するものすべて クリックハウス、 に対応 "クリックハウスのやり方"、つまり他のデータベースとは機能が異なります。 例えば：

• インデックスは選択されませんが、スキップされます。
• 更新/削除 同期ではなく、非同期です。
• 複数の結合がありますが、クエリ プランナーはありません。 一般に、それらがどのように実行されるかは、データベースの世界の人々にとってはあまり明確ではありません。

クリックハウススクリプト

1960年、ハンガリー出身のアメリカの数学者 ウィグナー EP 記事を書きました」自然科学における数学の不合理な有効性」（「自然科学における数学の理解できない有効性」）、私たちの周りの世界は何らかの理由で数学的法則によってよく説明されているということです。 数学は抽象的な科学であり、数学的な形式で表現された物理法則は自明ではありません。 ウィグナー EP これは非常に奇妙であると強調した。

私の視点から、 クリックハウス -同じ奇妙さ。 ウィグナーの言葉を言い換えると、次のように言えます。「考えられないほどの効率は驚くべきものです」 クリックハウス さまざまな分析用途に使用できます。

たとえば、 リアルタイム データ ウェアハウス、データはほぼ継続的にロードされます。 XNUMX 秒遅れでリクエストを受け取りたいと考えています。 お願いします - 使ってください クリックハウス、これが設計されたシナリオだからです。 クリックハウス これはまさに、Web だけでなく、マーケティングや財務分析でも使用される方法です。 アドテックh、同様に 不正行為の検出n. で リアルタイム データ ウェアハウス 「スター」や「スノーフレーク」のような複雑な構造のスキームが使用され、多くのテーブルが 登録 (場合によっては複数)、データは通常、一部のシステムに保存され、変更されます。

別のシナリオを考えてみましょう - 時系列: デバイス、ネットワーク、使用統計、モノ​​のインターネットの監視。 ここでは、時間に従って順序付けられた非常に単純なイベントに遭遇します。 クリックハウス はもともとこのために開発されたものではありませんでしたが、うまく機能することがわかったので、大企業は クリックハウス 監視情報のリポジトリとして。 適切かどうかを検討するため クリックハウス 時系列については、アプローチと結果に基づいてベンチマークを作成しました 流入DB и タイムスケールDB - 専門化された 時系列 データベース。 それは判明したその クリックハウスは、そのようなタスクを最適化しなくても、外部フィールドで勝利します。

В 時系列 通常は、狭いテーブル (いくつかの小さな列) が使用されます。 モニタリングからは大量のデータ (XNUMX 秒あたり数百万レコード) が取得される可能性があり、それらは通常、小さなバーストで取得されます (への ストリーミング）。 したがって、別の挿入スクリプトが必要であり、クエリ自体にも独自の詳細があります。

ログ管理。 ログをデータベースに収集するのは通常は好ましくありませんが、 クリックハウス これは、上で説明したようにいくつかのコメントを使用して行うことができます。 多くの企業が利用している クリックハウス まさにこの目的のために。 この場合、ログ全体を保存するフラットワイドテーブルを使用します（たとえば、次の形式） JSONの）、または細かく切ります。 通常、データは大きなバッチ (ファイル) でロードされ、何らかのフィールドで検索します。

通常、これらの機能ごとに専用のデータベースが使用されます。 クリックハウス 人はそれをすべてこなすことができ、それが彼らを上回るほど優れています。 では、詳しく見てみましょう 時系列 シナリオと正しく「料理」する方法 クリックハウス このシナリオの場合。

時系列

現在、これがメインシナリオです。 クリックハウス 標準的な解決策と考えられます。 時系列 時間の経過に伴う一連のイベントであり、時間の経過に伴う何らかのプロセスの変化を表します。 たとえば、これは XNUMX 日あたりの心拍数やシステム内のプロセス数などです。 何らかの次元で時間を刻むものはすべて 時系列:

この種のイベントのほとんどは監視によって発生します。 これは、Web を監視するだけでなく、実際のデバイス (自動車、産業システム、 IoT、工場や無人タクシー、Yandex がすでにトランクに積んでいる クリックハウス-サーバ。

たとえば、船舶からデータを収集する会社があります。 コンテナ船のセンサーは数秒ごとに、数百もの異なる測定値を送信します。 コンテナ船は一秒たりともアイドル状態であってはいけないため、エンジニアはそれらを研究し、モデルを構築し、船がいかに効率的に使用されているかを理解しようとします。 ダウンタイムは金銭の損失につながるため、停止が最小限に抑えられるようにルートを予測することが重要です。

現在では、 時系列。 現場で DBエンジン さまざまなデータベースは何らかの形でランク付けされており、タイプ別に表示できます。

一番成長が早いタイプは、 時系列s. グラフデータベースも成長していますが、 時系列ここ数年で急速に成長しています。 このファミリーのデータベースの代表的なものは次のとおりです。 流入DB, プロメテウス, KDB, タイムスケールDB (上に構築された PostgreSQL)、からの解決策 Amazon. クリックハウス ここでも使用でき、使用されています。 いくつかの公的な例を紹介しましょう。

先駆者のひとつが同社です CloudFlareの (CDN-プロバイダー）。 彼らは彼らを監視しています CDN スルー クリックハウス (DNS-リクエスト、 HTTP-クエリ）、膨大な負荷 - 6 秒あたり XNUMX 万イベント。 すべてが通過します カフカ、 に行く クリックハウス、システム内のイベントのダッシュボードをリアルタイムで表示する機会を提供します。

コムキャスト - 米国の電気通信分野のリーダーの XNUMX つ: インターネット、デジタル テレビ、電話。 彼らは同様の制御システムを作成しました CDN 内に オープンソース プロジェクト Apache トラフィック制御 膨大なデータを扱うために。 クリックハウス 分析のバックエンドとして使用されます。

ペルコナ 組み込まれている クリックハウス あなたの中に PMMさまざまなモニタリングを保存する MySQL.

特定の要件

時系列データベースには独自の固有の要件があります。

• 多くのエージェントからの迅速な挿入。 多くのストリームからのデータを非常に迅速に挿入する必要があります。 クリックハウス すべての挿入がノンブロッキングであるため、これがうまく機能します。 どれでも insert はディスク上の新しいファイルであり、小さな挿入は何らかの方法でバッファリングできます。 で クリックハウス データを一度に XNUMX 行ずつ挿入するよりも、大きなバッチに分けて挿入することをお勧めします。
• 柔軟なスキーム。 で 時系列 通常、私たちはデータ構造を完全には知りません。 特定のアプリケーション向けに監視システムを構築することは可能ですが、それを別のアプリケーションに使用するのは困難です。 これには、より柔軟なスキームが必要です。 クリックハウスは、強く型付けされたベースであっても、これを行うことができます。
• データの効率的な保管と忘れ。 通常は 時系列 膨大な量のデータがあるため、できるだけ効率的に保存する必要があります。 たとえば、 流入DB 優れた圧縮が主な特徴です。 ただし、保存するだけでなく、古いデータを「忘れて」、何らかの処理を実行できる必要もあります。 ダウンサンプリング — 凝集体の自動カウント。
• 集約データに対する高速クエリ。 過去 5 分間をミリ秒単位の精度で見ると興味深い場合もありますが、月次データでは分や秒の粒度は必要ない場合があります。一般的な統計で十分です。 この種のサポートは必要です。そうでないと、3 か月のリクエストは完了するまでに非常に長い時間がかかります。 クリックハウス.
• 「」のようなリクエスト最後のポイント、現在»。 これらは典型的なものです 時系列 クエリ: ある時点でのシステムの最後の測定値または状態を確認します。 t。 これらはデータベースにとってあまり快適なクエリではありませんが、実行できる必要もあります。
• 「接着」時系列. 時系列 時系列です。 XNUMX つの時系列がある場合、多くの場合、それらを接続して相関させる必要があります。 すべてのデータベース、特に位置合わせされていない時系列でこれを行うのは便利ではありません。以下にいくつかの時点を示しますが、他の時点もあります。 平均的と考えることもできますが、突然穴が開く可能性があるため、明確ではありません。

これらの要件がどのように満たされるかを見てみましょう クリックハウス.

スキーム

В クリックハウス のためのスキーム 時系列 データの規則性の程度に応じて、さまざまな方法で実行できます。 すべての指標が事前にわかっていれば、通常のデータに基づいてシステムを構築することが可能です。 たとえば、私はこれをしました CloudFlareの モニタリング付き CDN 十分に最適化されたシステムです。 インフラ全体やさまざまなサービスを監視する、より汎用的なシステムを構築できます。 不規則なデータの場合、何を監視しているのかが事前にわかりません。これがおそらく最も一般的なケースです。

通常のデータ。 コラム。 スキームはシンプルで、必要なタイプの列が含まれています。

CREATE TABLE cpu (
  created_date Date DEFAULT today(),  
  created_at DateTime DEFAULT now(),  
  time String,  
  tags_id UInt32,  /* join to dim_tag */
  usage_user Float64,  
  usage_system Float64,  
  usage_idle Float64,  
  usage_nice Float64,  
  usage_iowait Float64,  
  usage_irq Float64,  
  usage_softirq Float64,  
  usage_steal Float64,  
  usage_guest Float64,  
  usage_guest_nice Float64
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

これは、ある種のシステム読み込みアクティビティを監視する通常のテーブルです (user, 　, アイドル, nice）。 シンプルで便利ですが、柔軟性はありません。 より柔軟なスキームが必要な場合は、配列を使用できます。

不規則なデータ。 配列:

CREATE TABLE cpu_alc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metrics Nested(
    name LowCardinality(String),  
    value Float64
  )
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

SELECT max(metrics.value[indexOf(metrics.name,'usage_user')]) FROM ...

構造 入れ子になった は XNUMX つの配列です: metrics.name и メトリクス.値。 ここでは、このような任意の監視データを、イベントごとの名前の配列および測定値の配列として保存できます。 さらに最適化するには、そのような構造を XNUMX つではなく、複数作成できます。 たとえば、XNUMX つは フロート-値、別の - の int型-つまり、なぜなら int型 もっと効率的に収納したい。

しかし、そのような構造にアクセスするのはさらに困難です。 最初にインデックス、次に配列の値を引き出すには、特別な関数を使用して特別な構造を使用する必要があります。

SELECT max(metrics.value[indexOf(metrics.name,'usage_user')]) FROM ...

しかし、それでも非常に速く動作します。 不規則なデータを格納するもう XNUMX つの方法は、行ごとです。

不規則なデータ。 文字列。 この従来の方法では、配列を使用せず、名前と値が同時に保存されます。 5 つのデバイスから一度に 000 の測定値が取得された場合、データベースには 5 行が生成されます。

CREATE TABLE cpu_rlc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metric_name LowCardinality(String),  
  metric_value Float64
) ENGINE = MergeTree(created_date, (metric_name, tags_id, created_at), 8192);


SELECT 
    maxIf(metric_value, metric_name = 'usage_user'),
    ... 
FROM cpu_r
WHERE metric_name IN ('usage_user', ...)

クリックハウス これに対処します - 特別な拡張機能があります クリックハウス SQL。 例えば、 maxIf — 何らかの条件が満たされた場合にメトリクスによって最大値を計算する特別な関数。 XNUMX つのリクエストでこのような式を複数記述し、複数のメトリクスの値を即座に計算できます。

XNUMX つのアプローチを比較してみましょう。

細部

ここでは、いくつかのテスト データ セットに「ディスク データ サイズ」を追加しました。 列の場合、データ サイズは最小、つまり最大の圧縮と最大のクエリ速度を実現できますが、すべてを一度に記録する必要があるため、代償が伴います。

配列の場合は、すべてが少し悪くなります。 データは依然として十分に圧縮されており、不規則なパターンを保存できます。 しかし クリックハウス - 列型データベース。すべてを配列に保存し始めると、それが XNUMX 行目に変わり、効率性と柔軟性を対価とします。 どのような操作でも、配列全体をメモリに読み込んでから、その中で目的の要素を見つける必要があります。配列が大きくなると、速度が低下します。

このアプローチを採用している企業の XNUMX つ (たとえば、 ユーバー)、配列は 128 個の要素に分割されます。 200 日あたり 10 TB のデータ量を持つ数千のメトリックからのデータは、30 つのアレイではなく、特別なストレージ ロジックを備えた XNUMX または XNUMX のアレイに保存されます。

最も簡単なアプローチは文字列を使用することです。 しかし、データの圧縮が不十分でテーブル サイズが大きく、クエリが複数のメトリクスに基づいている場合でも、ClickHouse は最適に動作しません。

ハイブリッド方式

アレイ回路を選択したと仮定しましょう。 ただし、ほとんどのダッシュボードにはユーザーとシステムのメトリクスのみが表示されることがわかっている場合は、次の方法でこれらのメトリクスをテーブル レベルで配列から列に具体化することもできます。

CREATE TABLE cpu_alc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metrics Nested(
    name LowCardinality(String),  
    value Float64
  ),
  usage_user Float64 
             MATERIALIZED metrics.value[indexOf(metrics.name,'usage_user')],
  usage_system Float64 
             MATERIALIZED metrics.value[indexOf(metrics.name,'usage_system')]
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

挿入時 クリックハウス 自動的にカウントされます。 このようにして、ビジネスと喜びを組み合わせることができます。スキームは柔軟で一般的ですが、最も頻繁に使用される列を抜粋しました。 これにはインサートを変更する必要がないことに注意してください。 ETLこれにより、テーブルへの配列の挿入が続行されます。 やったばかりです 他の机、いくつかのスピーカーを追加し、すぐに使い始めることができるハイブリッドで高速なスキームを入手しました。

コーデックと圧縮

のために 時系列 情報量は非常に大きくなる可能性があるため、データをどのように圧縮するかが重要です。 で クリックハウス 1:10、1:20、場合によってはそれ以上の圧縮効果を実現するツールのセットがあります。 これは、ディスク上の 1 TB の解凍されたデータが 50 ～ 100 GB を占有することを意味します。 サイズが小さいほど、データの読み取りと処理が高速になります。

高レベルの圧縮を実現するには、 クリックハウス は次のコーデックをサポートしています。

テーブルの例:

CREATE TABLE benchmark.cpu_codecs_lz4 (
    created_date Date DEFAULT today(), 
    created_at DateTime DEFAULT now() Codec(DoubleDelta, LZ4), 
    tags_id UInt32, 
    usage_user Float64 Codec(Gorilla, LZ4), 
    usage_system Float64 Codec(Gorilla, LZ4), 
    usage_idle Float64 Codec(Gorilla, LZ4), 
    usage_nice Float64 Codec(Gorilla, LZ4), 
    usage_iowait Float64 Codec(Gorilla, LZ4), 
    usage_irq Float64 Codec(Gorilla, LZ4), 
    usage_softirq Float64 Codec(Gorilla, LZ4), 
    usage_steal Float64 Codec(Gorilla, LZ4), 
    usage_guest Float64 Codec(Gorilla, LZ4), 
    usage_guest_nice Float64 Codec(Gorilla, LZ4), 
    additional_tags String DEFAULT ''
)
ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

ここでコーデックを定義します ダブルデルタ ある場合には、もう一つの場合には - ゴリラ、そして私たちは間違いなくさらに追加します LZ4 圧縮。 その結果、ディスク上のデータのサイズが大幅に減少します。

これは、異なるコーデックと圧縮を使用した場合に、同じデータがどれだけのスペースを占めるかを示しています。

• ディスク上の GZIP ファイル内。
• ClickHouse ではコーデックは使用せず、ZSTD 圧縮を使用します。
• ClickHouse ではコーデックと圧縮 LZ4 および ZSTD を使用します。

コーデックを含むテーブルの方が占有するスペースがはるかに少ないことがわかります。

サイズの問題

それほど重要ではない 選択する 正しいデータ型:

上記のすべての例で使用したのは、 フロート64。 でももし私たちが選んだなら フロート32、それならさらに良いでしょう。 これは、上記のリンク先の記事で、Perkona のスタッフによってよく実証されています。 タスクに適した最もコンパクトなタイプを使用することが重要です。クエリ速度よりもディスク サイズが小さい場合でも同様です。 クリックハウス これには非常に敏感です。

ご利用いただければ intxnumx 代わりに intxnumxそうすると、ほぼ XNUMX 倍のパフォーマンスの向上が期待できます。 データが占有するメモリが少なくなり、すべての「演算」がより高速に実行されます。 クリックハウス 内部的には非常に厳密に型指定されたシステムであり、最新のシステムが提供するすべての可能性を最大限に活用します。

集計と マテリアライズドビュー

集計ビューとマテリアライズド ビューを使用すると、さまざまな場合に集計を作成できます。

たとえば、非集計のソース データがある場合、特別なエンジンによる自動集計を使用して、さまざまなマテリアライズド ビューをそれらのデータにアタッチできます。 サミングマージツリー (SMT). SMT 集計を自動的に計算する特別な集計データ構造です。 生データがデータベースに挿入され、自動的に集約され、その上でダッシュボードをすぐに使用できるようになります。

TTL - 古いデータを「忘れる」

不要になったデータを「忘れる」にはどうすればよいでしょうか? クリックハウス これを行う方法を知っています。 テーブルを作成するときに指定できるのは、 TTL 式: たとえば、分単位のデータは 30 日分、日単位のデータは XNUMX 日間保存し、週単位または月単位のデータには一切触れないようにします。

CREATE TABLE aggr_by_minute
…
TTL time + interval 1 day

CREATE TABLE aggr_by_day
…
TTL time + interval 30 day

CREATE TABLE aggr_by_week
…
/* no TTL */

多層 - データをディスク間で分割する

この考え方をさらに進めると、データは次のように保存できます。 クリックハウス さまざまな場所で。 先週のホット データを非常に高速なローカル サーバーに保存したいとします。 SSD、さらに過去のデータを別の場所に置きます。 で クリックハウス これが可能になりました:

ストレージ ポリシーを構成できます (ストレージポリシー） それで クリックハウス 特定の条件に達すると、データを別のストレージに自動的に転送します。

しかし、それだけではありません。 特定のテーブルのレベルで、データがいつコールド ストレージに保存されるかを正確に定義できます。 たとえば、データは非常に高速なディスクに 7 日間保存され、古いものはすべて低速なディスクに転送されます。 これは、コストを管理し、コールド データにお金を無駄に費やさずに、システムを最大のパフォーマンスに維持できるため、優れています。

CREATE TABLE 
... 
TTL date + INTERVAL 7 DAY TO VOLUME 'cold_volume', 
    date + INTERVAL 180 DAY DELETE

ユニークな機能 クリックハウス

ほぼすべてにおいて クリックハウス このような「ハイライト」はありますが、他のデータベースにはない独占性によって相殺されます。 たとえば、次のようなユニークな機能があります。 クリックハウス:

• 配列。 で クリックハウス 配列に対する非常に優れたサポートと、それらに対して複雑な計算を実行する機能。
• データ構造の集約。 これは「キラー機能」の XNUMX つです。 クリックハウス。 Yandex の担当者はデータを集約したくないと言っていますが、すべてが集約されています。 クリックハウス、速くて便利だからです。
• マテリアライズドビュー。 データ構造の集約と併せて、マテリアライズド ビューを使用すると、便利なデータ構造を実現できます。 への 集約。
• クリックハウスSQL。 これは言語拡張機能です SQL でのみ利用できるいくつかの追加および独占機能を備えています。 クリックハウス。 以前は、一方では拡大、他方では不利のような状況でした。 これまでと比べてほぼすべての欠点が解消されました。 SQL 92 それを削除しました。今は単なる拡張機能です。
• ラムダ–式。 それらはまだデータベースにありますか?
• ML-サポート。 これはさまざまなデータベースで利用できますが、より優れたデータベースもあれば、より劣ったデータベースもあります。
• オープンソース。 拡張できる クリックハウス 一緒に。 今 クリックハウス 寄稿者は約 500 名で、この数は増え続けています。

トリッキーなクエリ

В クリックハウス 同じことを行うのにさまざまな方法があります。 たとえば、次の XNUMX つの異なる方法でテーブルから最後の値を返すことができます。 CPU (XNUMX 番目もありますが、さらにエキゾチックです)。

最初のものは、それがいかに便利かを示しています クリックハウス それを確認したいときのクエリ タプル サブクエリに含まれます。 これは私が個人的に他のデータベースでは本当に見逃していたものです。 何かをサブクエリと比較したい場合、他のデータベースではスカラーのみを比較できますが、いくつかの列については次のように記述する必要があります。 登録。 で クリックハウス タプルを使用できます:

SELECT *
  FROM cpu 
 WHERE (tags_id, created_at) IN 
    (SELECT tags_id, max(created_at)
        FROM cpu 
        GROUP BY tags_id)

XNUMX 番目のメソッドは同じことを行いますが、集計関数を使用します。 argMax:

SELECT 
    argMax(usage_user), created_at),
    argMax(usage_system), created_at),
...
 FROM cpu 

В クリックハウス 集計関数は数十あり、コンビネータを使用すると、組み合わせの法則によれば、約 XNUMX 個の集計関数が得られます。 ArgMax - 最大値を計算する関数の XNUMX つ: リクエストは値を返します。 使用状況_ユーザー、最大値に達します created_at:

SELECT now() as created_at,
       cpu.*
  FROM (SELECT DISTINCT tags_id from cpu) base 
  ASOF LEFT JOIN cpu USING (tags_id, created_at)

アソフ結合 — 異なる時間の行を「接着」します。 これはデータベース固有の機能であり、 kdb +。 時間が異なる XNUMX つの時系列がある場合、 アソフ結合 XNUMX つのリクエストでそれらを移動およびマージできます。 一方の時系列の各値について、もう一方の時系列で最も近い値が検索され、それらが同じ行に返されます。

分析関数

標準では SQL-2003 次のように書くことができます:

SELECT origin,
       timestamp,
       timestamp -LAG(timestamp, 1) OVER (PARTITION BY origin ORDER BY timestamp) AS duration,
       timestamp -MIN(timestamp) OVER (PARTITION BY origin ORDER BY timestamp) AS startseq_duration,
       ROW_NUMBER() OVER (PARTITION BY origin ORDER BY timestamp) AS sequence,
       COUNT() OVER (PARTITION BY origin ORDER BY timestamp) AS nb
  FROM mytable
ORDER BY origin, timestamp;

В クリックハウス それはできません - 標準をサポートしていません SQL-2003 そしておそらくそれは決してしないだろう。 代わりに、 クリックハウス 次のように書くのが一般的です。

ラムダを約束しました - ここにあります!

これは、標準の分析クエリに似ています。 SQL-2003: 彼は XNUMX つの違いを数えます タイムスタンプ、期間、序数 - 私たちが通常分析関数を考慮するすべてのもの。 で クリックハウス 配列を通じてそれらをカウントします。最初にデータを配列に折りたたみ、その後配列に対して必要なことをすべて実行し、それを展開して戻します。 あまり便利ではなく、少なくとも関数型プログラミングの知識が必要ですが、非常に柔軟です。

特別な機能

さらに、 クリックハウス 多くの特殊な機能。 たとえば、同時に実行されているセッションの数を確認するにはどうすればよいでしょうか? 一般的な監視タスクは、XNUMX つのリクエストでの最大負荷を決定することです。 で クリックハウス この目的のために特別な関数があります。

一般に、ClickHouse にはさまざまな目的のための特別な機能があります。

• runningDifference、runningAccumulate、neighbor;
• sumMap(キー, 値);
• timeSeriesGroupSum(uid, タイムスタンプ, 値);
• timeSeriesGroupRateSum(uid, タイムスタンプ, 値);
• skewPop、skewSamp、kurtPop、kurtSamp;
• 中綿入り/ネクタイ付き。
• simpleLinearRegression、stochasticLinearRegression。

これは関数の完全なリストではなく、合計で 500 ～ 600 あります。 ヒント: のすべての関数 クリックハウス システム テーブルにあります (すべてが文書化されているわけではありませんが、すべて興味深いものです)。

select * from system.functions order by name

クリックハウス それ自体に関する多くの情報が保存されています。 ログテーブル, クエリログ、トレース ログ、データ ブロックを使用した操作のログ (パートログ)、メトリクス ログ、およびシステム ログ。通常、これらはディスクに書き込まれます。 ログメトリクスは 時系列 в クリックハウス 実際には クリックハウス: データベース自体が役割を果たすことができます 時系列 データベースを「食い荒らす」ことになります。

これもユニークなことです - 私たちは良い仕事をしているので、 時系列、なぜ私たちは必要なものをすべて自分の中に保管できないのでしょうか？ 私たちは必要としていない プロメテウス、私たちはすべてを自分自身に保ちます。 接続済み グラファナ そして私たちは自分自身を監視します。 ただし、 クリックハウス 落ちても理由が​​分からないので、通常はそんなことはしません。

大きなクラスターまたは多数の小さなクラスター クリックハウス

XNUMX つの大きなクラスターと多数の小さな ClickHouse ではどちらが優れていますか? 従来のアプローチ DWH 回路がアプリケーションごとに割り当てられる大規模なクラスターです。 私たちはデータベース管理者に相談し、図を見せてもらいました。すると、次の図をくれました。

В クリックハウス 別の方法で行うこともできます。 各アプリケーションを独自に作成できます クリックハウス:

巨大な怪物はもう必要ありません DWH そして手に負えない管理者。 各アプリケーションに独自のものを与えることができます クリックハウス開発者は自分でそれを行うことができます。 クリックハウス インストールは非常に簡単で、複雑な管理は必要ありません。

でも、たくさん持っていたら クリックハウス頻繁にインストールする必要がある場合は、このプロセスを自動化したいと考えます。 このために、たとえば、次のように使用できます。 Kubernetes и クリックハウス-オペレーター。 で Kubernetes クリックハウス 「オンクリック」と言い換えることもできます。ボタンをクリックしてマニフェストを実行すると、データベースの準備が整います。 すぐに図を作成し、そこにメトリクスのアップロードを開始すると、5 分でダッシュボードが完成します。 グラファナ。 とても簡単です！

その結果は？

このように、 クリックハウス - これ：

• すばやく。 これは誰もが知っています。
• ただ。 少し議論の余地がありますが、訓練では難しく、戦闘では簡単だと私は考えています。 やり方がわかれば クリックハウス それが機能すれば、すべてが非常に簡単になります。
• 普遍的に。 さまざまなシナリオに適しています。 DWH、時系列、ログストレージ。 そうではありません OLTP したがって、そこで短い挿入や読み取りを実行しないでください。
• おもしろいことに。 おそらく一緒に働いている人でしょう クリックハウス、良い意味でも悪い意味でも面白い瞬間をたくさん経験させていただきました。 たとえば、新しいリリースがリリースされた後、すべてが機能しなくなってしまいました。 あるいは、あるタスクに XNUMX 日間苦労していましたが、Telegram チャットで質問した後、そのタスクは XNUMX 分で解決したときもあります。 あるいは、レシャ・ミロヴィドフ氏の報告会見でのスクリーンショットのように、 クリックハウス 放送を中断した HighLoad ++。 このようなことは常に起こり、私たちの生活を困難にしています。 クリックハウス 明るくて面白い！

プレゼンテーションをご覧いただけます ここで.

待望の高負荷システム開発者会議が開催されました。 HighLoad ++ 9月10日とXNUMX日にスコルコボで開催される。 最後に、HighLoad++ のエネルギーをオンラインでパッケージ化することはできないため、これはオフライン カンファレンスになります (すべての予防措置を講じた上で)。

カンファレンスでは、テクノロジーの最大の機能に関する事例を見つけて紹介します。HighLoad++ は、Facebook、Yandex、VKontakte、Google、Amazon がどのように機能するかを XNUMX 日間で学べる唯一の場所です。

2007年から継続的に開催しており、今年で14回目となります。 この間、カンファレンスは 10 倍に成長し、昨年の主要な業界イベントには 3339 人の参加者、165 人の講演者、レポートやミートアップが集まり、16 のトラックが同時に実行されました。
昨年はバスが20台、お茶とコーヒーが5280リットル、フルーツドリンクが1650リットル、水が10200本あった。 さらに2640キログラムの食料、16枚の皿と000個のカップ。 ちなみに、再生紙から集めたお金で、25本のオークの苗木を植えました:)

チケットを購入できます ここで、カンファレンスに関するニュースを入手 - ここで、すべてのソーシャル ネットワークで話します。 Telegram, Facebook, Vkontakte и Twitter.

出所： habr.com