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

クリックハウス は、Yandex によって作成された、オンライン分析クエリ処理 (OLAP) 用のオープンソースの列型データベース管理システムです。 これは、Yandex、CloudFlare、VK.com、Badoo、および世界中のその他のサービスで、非常に大量のデータ (XNUMX 秒あたり数千行、またはディスクに保存されるペタバイトのデータを挿入) を保存するために使用されます。

MySQL、Postgres、MS SQL Server などの通常の「文字列」DBMS では、データは次の順序で保存されます。

この場合、XNUMX つの行に関連する値が物理的に近くに格納されます。 列指向 DBMS では、異なる列の値は個別に保存され、XNUMX つの列のデータは一緒に保存されます。

列型 DBMS の例としては、Vertica、Paraccel (Actian Matrix、Amazon Redshift)、Sybase IQ、Exasol、Infobright、InfiniDB、MonetDB (VectorWise、Actian Vector)、LucidDB、SAP HANA、Google Dremel、Google PowerDrill、Druid、kdb+ があります。

郵便転送会社 クウィントリー は、2018 年にレポート作成に Clickhouse を使い始めましたが、そのシンプルさ、スケーラビリティ、SQL サポート、速度に非常に感銘を受けました。 この DBMS の速度は魔法に近いものでした。

緩和

Clickhouse はコマンド XNUMX つで Ubuntu にインストールされます。 SQL の知識がある場合は、ニーズに合わせてすぐに Clickhouse を使い始めることができます。 ただし、これは、MySQL で「show create table」を実行し、Clickhouse で SQL をコピー＆ペーストできるという意味ではありません。

MySQL と比較すると、テーブル スキーマ定義に重要なデータ型の違いがあるため、テーブル スキーマ定義を変更し、テーブル エンジンに慣れるまでにはまだ時間がかかるでしょう。

Clickhouse は追加のソフトウェアなしでうまく動作しますが、レプリケーションを使用したい場合は、ZooKeeper をインストールする必要があります。 クエリ パフォーマンス分析では優れた結果が示されています。システム テーブルにはすべての情報が含まれており、すべてのデータは古くて退屈な SQL を使用して取得できます。

Производительность

• 基準 サーバー構成における Clickhouse と Vertica および MySQL の比較: 5 ソケット Intel® Xeon® CPU E2650-2 v2.60 @ 128GHz。 5 GiB RAM; 8 6TB SATA HDD 上の md RAID-4、extXNUMX。
• 基準 Clickhouse と Amazon RedShift クラウド ストレージの比較。
• ブログの抜粋 Cloudflare によるクリックハウスのパフォーマンス:

ClickHouse データベースの設計は非常にシンプルです。クラスター内のすべてのノードは同じ機能を持ち、調整には ZooKeeper のみを使用します。 私たちは複数のノードからなる小規模なクラスターを構築し、テストを実行しました。その際、システムが非常に優れたパフォーマンスを備えていることがわかりました。これは、分析 DBMS ベンチマークで述べられている利点に相当します。 私たちは、ClickHouse の背後にあるコンセプトを詳しく見てみることにしました。 研究の最初の障害は、ツールの欠如と ClickHouse コミュニティの小ささでした。そこで、私たちはこの DBMS の設計を詳しく調べて、それがどのように機能するかを理解しました。

ClickHouse は単なるデータベースであるため、Kafka からのデータの直接受信をサポートしていません。そのため、Go で独自のアダプター サービスを作成しました。 Kafka から Cap'n Proto でエンコードされたメッセージを読み取り、TSV に変換し、HTTP インターフェイス経由でバッチで ClickHouse に挿入しました。 その後、パフォーマンスを向上させるために、Go ライブラリを ClickHouse 独自のインターフェイスと組み合わせて使用​​するようにこのサービスを書き直しました。 パケット受信のパフォーマンスを評価するときに、重要なことがわかりました。ClickHouse の場合、このパフォーマンスはパケットのサイズ、つまり同時に挿入される行の数に大きく依存することがわかりました。 なぜこれが起こるのかを理解するために、ClickHouse がデータをどのように保存するかを調べました。

ClickHouse がデータを保存するために使用するメイン エンジン、つまりテーブル エンジンのファミリーは MergeTree です。 このエンジンは概念的には Google BigTable や Apache Cassandra で使用される LSM アルゴリズムに似ていますが、中間メモリ テーブルの構築を回避し、データをディスクに直接書き込みます。 これにより、挿入された各パケットが主キーのみでソートされ、圧縮されてディスクに書き込まれてセグメントが形成されるため、優れた書き込みスループットが得られます。

メモリ テーブルやデータの「鮮度」の概念が存在しないということは、データは追加のみ可能であり、システムは変更や削除をサポートしていないことを意味します。 現在、セグメントは月の境界を越えることがないため、データを削除する唯一の方法は暦月ごとに削除することです。 ClickHouse チームは、この機能をカスタマイズ可能にするために積極的に取り組んでいます。 一方、書き込みセグメントとマージセグメントの競合がなくなるため、I/O またはコアの飽和が発生するまで、受信スループットは同時挿入の数に比例して増加します。
ただし、これはシステムが小さなパケットには適していないことも意味するため、バッファリングには Kafka サービスとインサータが使用されます。 次に、バックグラウンドの ClickHouse がセグメントのマージを継続的に実行し続けるため、多数の小さな情報が結合され、より多くの回数記録されるため、記録強度が高まります。 ただし、未接続の部分が多すぎると、マージが継続する限り、挿入の積極的なスロットルが発生します。 リアルタイムの取り込みと取り込みのパフォーマンスの間の最良の妥協点は、XNUMX 秒あたりのテーブルへの挿入の数を制限することであることがわかりました。

テーブル読み取りパフォーマンスの鍵となるのは、インデックス付けとディスク上のデータの場所です。 処理がどれほど高速であっても、エンジンがディスクからテラバイト単位のデータをスキャンし、その一部のみを使用する必要がある場合、時間がかかります。 ClickHouse は列型ストアであるため、各セグメントには、各行のソートされた値を含む各列 (列) のファイルが含まれています。 この方法では、クエリに含まれていない列全体を最初にスキップしてから、複数のセルをベクトル化された実行で並行して処理できます。 フル スキャンを回避するために、各セグメントには小さなインデックス ファイルがあります。

すべての列が「主キー」でソートされている場合、インデックス ファイルには N 行ごとのラベル (キャプチャされた行) のみが含まれており、非常に大きなテーブルであってもラベルをメモリ内に保持できます。 たとえば、デフォルト設定を「8192 行ごとにマークする」ように設定し、1 兆のテーブルの「貧弱な」インデックスを設定できます。 メモリに簡単に収まる行であれば、わずか 122 文字しかかかりません。

システム開発

Clickhouse の開発と改善は次の場所で追跡できます。 Githubレポ そして「成長」のプロセスが素晴らしいペースで起こるようにしてください。

人気

Clickhouse の人気は、特にロシア語圏のコミュニティで急激に高まっているようです。 昨年の Highload 2018 カンファレンス (モスクワ、8 年 9 月 2018 ～ 40 日) では、vk.com や Badoo などのモンスターが Clickhouse を使用し、数万のサーバーから同時にデータ (ログなど) を挿入していることが示されました。 XNUMX分のビデオで VKontakte チームのYuri Nasretdinov が、これがどのように行われるかについて語ります。。 資料の取り扱いを容易にするために、間もなくそのトランスクリプトを Habr に投稿する予定です。

アプリケーション

時間をかけて調査した結果、ClickHouse が役立つ分野、または MySQL、PostgreSQL、ELK、Google Big Query、Amazon RedShift、TimescaleDB、Hadoop、MapReduce、Pinot などの他のより伝統的で人気のあるソリューションを完全に置き換えることができる分野があると思います。ドルイド僧。 以下では、ClickHouse を使用して上記の DBMS を最新化または完全に置き換える方法の詳細を説明します。

MySQL と PostgreSQL の機能の拡張

つい最近、ニュースレター プラットフォームの MySQL を ClickHouse に部分的に置き換えました。 Mautic ニュースレター。 問題は、MySQL の設計が不十分で、送信されたすべての電子メールとその電子メール内のすべてのリンクを Base64 ハッシュで記録し、巨大な MySQL テーブル (email_stats) を作成していたことでした。 サービス加入者に 10 万件の電子メールを送信しただけで、このテーブルは 150 GB のファイル スペースを占有し、MySQL は単純なクエリでは「愚か」になり始めました。 ファイル スペースの問題を解決するために、InnoDB テーブル圧縮を使用して、ファイル スペースを 4 分の 20 に削減しました。 ただし、履歴を読み取るためだけに 30 ～ XNUMX 万件を超える電子メールを MySQL に保存することは依然として意味がありません。何らかの理由でフル スキャンを実行する必要がある単純なクエリでは、スワップと大量の IE が発生するためです。 /O ロード。これによると、Zabbix から定期的に警告を受け取りました。

Clickhouse は XNUMX つの圧縮アルゴリズムを使用して、データ量を約 XNUMX/XNUMX 削減します。 3-4回ただし、この特定のケースでは、データは特に「圧縮可能」でした。

ELKの置き換え

私自身の経験に基づくと、ELK スタック (ElasticSearch、Logstash、Kibana、この例では ElasticSearch) の実行には、ログの保存に必要なリソースよりもはるかに多くのリソースが必要です。 ElasticSearch は、優れた全文ログ検索が必要な場合 (実際には必要ないと思います) には優れたエンジンですが、なぜこれが事実上の標準のログ エンジンになったのか疑問に思っています。 Logstash と組み合わせたその取り込みパフォーマンスにより、負荷がかなり軽い場合でも問題が発生し、RAM とディスク領域をさらに追加する必要がありました。 データベースとしては、Clickhouse が ElasticSearch よりも優れているのは、次の理由からです。

• SQL 方言のサポート。
• 保存されたデータの最適な圧縮度。
• 全文検索の代わりに Regex 正規表現検索をサポート。
• クエリのスケジューリングが改善され、全体的なパフォーマンスが向上しました。

現在、ClickHouse と ELK を比較するときに生じる最大の問題は、ログをアップロードするためのソリューションが不足していることと、このトピックに関するドキュメントやチュートリアルが不足していることです。 さらに、各ユーザーは Digital Ocean マニュアルを使用して ELK を設定できます。これは、このようなテクノロジーを迅速に実装するために非常に重要です。 データベース エンジンはありますが、ClickHouse 用の Filebeat はまだありません。 はい、そこにあります 流暢 ログを操作するためのシステム ログハウス、ツールがあります クリックテール ログ ファイル データを ClickHouse に入力する必要がありますが、これにはさらに時間がかかります。 ただし、ClickHouse はそのシンプルさにより依然としてリーダーであり、初心者でも簡単にインストールして、わずか 10 分で完全に機能的に使い始めることができます。

私は最小限のソリューションを好み、Kafka の使用を避けながら、ClickHouse とともに、非常に少ないメモリでログを配布するツールである FluentBit を使用してみました。 ただし、次のような軽微な非互換性に対処する必要があります。 日付形式の問題データを FluentBit から ClickHouse に変換するプロキシ レイヤーなしでこれを実行できる前に。

代わりに、Kibana を ClickHouse バックエンドとして使用できます。 グラファナ。 私の理解では、これにより、特に古いバージョンの Grafana で大量のデータ ポイントをレンダリングするときにパフォーマンスの問題が発生する可能性があります。 Qwintry ではまだこれを試していませんが、これに関する苦情が Telegram の ClickHouse サポート チャネルに時々表示されます。

Google Big QueryとAmazon RedShiftの置き換え（大企業向けソリューション）

BigQuery の理想的なユースケースは、1 TB の JSON データを読み込み、それに対して分析クエリを実行することです。 Big Query は、そのスケーラビリティを誇張してもしすぎることのない優れた製品です。 これは、内部クラスター上で実行される ClickHouse よりもはるかに複雑なソフトウェアですが、クライアントの観点から見ると、ClickHouse と多くの共通点があります。 BigQuery は、SELECT ごとに支払いを開始するとすぐに高価になる可能性があるため、長所と短所をすべて備えた真の SaaS ソリューションです。

ClickHouse は、大量の計算コストのかかるクエリを実行する場合に最適な選択肢です。 毎日実行する SELECT クエリが増えるほど、Big Query を ClickHouse に置き換えることは理にかなっています。数テラバイトのデータを処理する場合、このような置き換えにより数千ドルを節約できるからです。 これは、Big Query での処理が非常に低コストである保存データには適用されません。

Altinity の共同創設者、Alexander Zaitsev 氏の記事 「クリックハウスへの切り替え」 では、このような DBMS 移行の利点について説明します。

TimescaleDB の置き換え

TimescaleDB は、通常のデータベースでの timeseries 時系列の操作を最適化する PostgreSQL 拡張機能です (https://docs.timescale.com/v1.0/introduction, https://habr.com/ru/company/zabbix/blog/458530/).

ClickHouse は、時系列のニッチな分野では深刻な競合相手ではありませんが、列構造とベクトル クエリの実行では、分析クエリ処理のほとんどのケースで TimescaleDB よりもはるかに高速です。 同時に、ClickHouse からバッチ データを受信するパフォーマンスは約 3 倍向上し、使用するディスク容量も 20 分の XNUMX に削減されます。これは、大量の履歴データを処理する場合に非常に重要です。 
https://www.altinity.com/blog/ClickHouse-for-time-series.

ClickHouse とは異なり、TimescaleDB でディスク領域を節約する唯一の方法は、ZFS または同様のファイル システムを使用することです。

ClickHouse の今後のアップデートでは、デルタ圧縮が導入される可能性が高く、時系列データの処理と保存により適したものになります。 次の場合には、TimescaleDB が裸の ClickHouse よりも優れた選択肢となる可能性があります。

• RAM が非常に少ない (3 GB 未満) 小規模なインストール。
• 大きなフラグメントにバッファリングしたくない多数の小さな INSERT。
• 一貫性、均一性、ACID 要件の向上。
• PostGIS のサポート。
• Timescale DB は本質的に PostgreSQL であるため、既存の PostgreSQL テーブルと結合します。

Hadoop および MapReduce システムとの競合

Hadoop やその他の MapReduce 製品は多くの複雑な計算を実行できますが、実行すると待ち時間が大きくなる傾向がありますが、ClickHouse はテラバイト規模のデータを処理し、ほぼ瞬時に結果を生成することでこの問題を解決します。 したがって、ClickHouse は、データ サイエンティストにとって興味深いはずの、高速でインタラクティブな分析調査をより効果的に実行できます。

ピノとドルイドとの競争

ClickHouse の最も近い競合相手は、カラム型で直線的にスケーラブルなオープンソース製品である Pinot と Druid です。 これらのシステムを比較した優れた研究が記事に掲載されています。 ロマーナ・レベントワ 1 2月2018

この記事は更新する必要があります。ClickHouse は UPDATE および DELETE 操作をサポートしていないと書かれていますが、これは最新バージョンに完全に当てはまるわけではありません。

私たちはこれらのデータベースの使用経験があまりありませんが、Druid と Pinot を実行するために必要なインフラストラクチャの複雑さがあまり好きではありません。それは、四方八方を Java で囲まれた可動部分の塊です。

Druid と Pinot は Apache インキュベーター プロジェクトであり、その進捗状況は Apache の GitHub プロジェクト ページで詳しく説明されています。 ピノは2018年8月に保育器に現れ、ドルイドはXNUMXか月前のXNUMX月に生まれました。

AFS がどのように機能するかについての情報が不足しているため、いくつかの、おそらく愚かな疑問が私に生じました。 Pinot の著者たちは、Apache Foundation が Druid に対して好意的であることに気づいたのだろうか、また競合他社に対するこの態度が羨望の感情を引き起こしたのだろうか? ドルイドの支援者が突然後者に興味を持ち始めたら、ドルイドの発展は減速し、ピノの発展は加速するでしょうか?

クリックハウスのデメリット

未熟さ: もちろん、これはまだ退屈なテクノロジではありませんが、いずれにしても、このようなことは他のカラム型 DBMS では見られません。

小さな挿入は高速ではパフォーマンスが良くありません。小さな挿入のパフォーマンスは各行の列数に比例して低下するため、挿入は大きなチャンクに分割する必要があります。 ClickHouse がデータをディスクに保存する方法は次のとおりです。各列は 1 つ以上のファイルを表すため、1 列を含む 100 行を挿入するには、少なくとも 100 個のファイルを開いて書き込む必要があります。 これが、バッファリング挿入に仲介者 (クライアント自体がバッファリングを提供しない限り) - 通常は Kafka またはある種のキュー管理システムを必要とする理由です。 バッファ テーブル エンジンを使用して、後で大きなデータ チャンクを MergeTree テーブルにコピーすることもできます。

テーブル結合はサーバーの RAM によって制限されますが、少なくとも存在します。 たとえば、Druid と Pinot にはそのような接続がまったくありません。これは、ノード間で大量のデータを移動することをサポートしていない分散システムに直接実装することが難しいためです。

所見

この DBMS はパフォーマンス、低オーバーヘッド、スケーラビリティ、シンプルさの優れたバランスを提供するため、今後数年間で Qwintry で ClickHouse を広く使用する予定です。 ClickHouse コミュニティが小規模から中規模のインストールで使用する方法をさらに考案したら、すぐに普及し始めると確信しています。

いくつかの広告 🙂

いつもご宿泊いただきありがとうございます。 私たちの記事が気に入っていますか? もっと興味深いコンテンツを見たいですか? 注文したり、友人に勧めたりして私たちをサポートしてください。 開発者向けのクラウド 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