ClickHouseの特徴

ClickHouseが他のデータベース管理システムと一線を画す理由を理解する

​

真のカラム指向データベース管理システム

真のカラム指向DBMSでは、値と一緒に余分なデータは格納されません。つまり、値の横に長さを表す「数値」を格納しなくて済むよう、固定長の値をサポートする必要があります。たとえば、10億個の UInt8 型の値は、非圧縮で約 1 GB を消費するはずであり、そうでなければ CPU 使用率に大きく影響します。伸長の速度 (CPU 使用率) は主に非圧縮データの量に依存するため、非圧縮時であっても、データはできるだけコンパクトに (いかなる「ごみ」もなく) 格納することが重要です。

これは、異なるカラムの値を個別に格納できても、HBase、Bigtable、Cassandra、Hypertable のように別の用途向けに最適化されているため、分析クエリを効率的に処理できないシステムとは対照的です。これらのシステムで得られるスループットは毎秒 10 万行程度であり、毎秒数億行には達しません。

最後に、ClickHouse は単一のデータベースではなく、データベース管理システムです。これにより、サーバーを再設定して再起動しなくても、実行時にテーブルやデータベースを作成し、データを読み込み、クエリを実行できます。

​

データ圧縮

カラム指向DBMSの中には、データ圧縮を使用しないものもあります。しかし、優れた性能を実現するうえで、データ圧縮は重要な役割を果たします。

ClickHouseは、ディスク容量とCPU使用量のトレードオフが異なる効率的な汎用圧縮コーデックに加え、特定の種類のデータ向けに専用コーデックも提供しています。これにより、時系列データベースのような、より特化したデータベースとも競合し、それらを上回る性能を発揮できます。

​

データのディスクストレージ

データを主キーで物理的にソートされた状態に保つことで、特定の値や値の範囲に基づくデータ抽出を、数十ミリ秒未満という低レイテンシで行えます。SAP HANA や Google PowerDrill などの一部のカラム指向 DBMSs は、RAM 上でしか動作できません。このアプローチでは、リアルタイム分析に必要以上のハードウェアコストがかかります。

ClickHouse は一般的なハードドライブ上で動作するように設計されているため、データストレージの GB あたりのコストを低く抑えられます。一方で、SSD や追加の RAM が利用可能な場合は、それらも十分に活用できます。

​

複数コアでの並列処理

大規模なクエリは自然に並列化され、現在のサーバーで利用可能な必要なリソースをすべて活用します。

​

複数サーバーでの分散処理

前述した列指向DBMSのほとんどは、分散クエリ処理をサポートしていません。

ClickHouse では、データを異なる分片に配置できます。各分片は、耐障害性のために使用されるレプリカのグループにすることもできます。ユーザーが意識することなく、すべての分片がクエリの並列実行に使用されます。

​

SQL のサポート

ClickHouse は、ANSI SQL 標準とおおむね互換性のある、SQL ベースの宣言型クエリ言語をサポートしています。

サポートされるクエリには、GROUP BY、ORDER BY、FROM句内のサブクエリ、JOIN句、IN演算子、ウィンドウ関数、およびスカラーサブクエリが含まれます。

執筆時点では、相関 (従属) サブクエリはサポートされていませんが、今後サポートされる可能性があります。

​

ベクトル演算エンジン

データはカラム単位で格納されるだけでなく、ベクトル (カラムの一部) 単位で処理されるため、高いCPU効率を実現できます。

​

リアルタイムのデータ挿入

ClickHouse は、主キーを持つテーブルをサポートしています。主キーの範囲を対象とするクエリを高速に実行できるように、データはマージツリーによって段階的にソートされます。そのため、テーブルには継続的にデータを追加できます。新しいデータの取り込み時にロックは取得されません。

​

プライマリインデックス

データを主キーで物理的にソートしておくことで、特定の値や値の範囲に基づいて、数十ミリ秒未満の低レイテンシでデータを抽出できます。

​

セカンダリ索引

他のデータベース管理システムとは異なり、ClickHouse のセカンダリ索引は特定の行や行の範囲を指すものではありません。代わりに、一部のデータパーツに含まれるすべての行がクエリの絞り込み条件に一致しないことをデータベースが事前に判断し、それらをまったく読み込まないようにします。そのため、これらは データスキッピングインデックス と呼ばれます。

​

オンラインクエリに適している

多くのOLAPデータベース管理システムは、サブ秒レベルのレイテンシでオンラインクエリを処理することを前提としていません。ほかのシステムでは、レポートの生成に数十秒、場合によっては数分かかっても許容されることがよくあります。さらに長くかかることもあり、その結果、システムはレポートをオフラインで準備せざるを得なくなります (事前に作成しておくか、「後でもう一度お試しください」と返す形です) 。

ClickHouseでいう「低レイテンシ」とは、クエリを遅延なく、事前に結果を用意することなく、UIページの読み込み時点でその場で処理できること、つまり オンライン であることを意味します。

​

近似計算のサポート

ClickHouse には、精度とパフォーマンスを引き換えにできるさまざまな方法があります。

1. 異なる値の数、中央値、分位点を近似的に計算するための集約関数。
2. データの一部 (SAMPLE) に基づいてクエリを実行し、近似結果を取得する方法。この場合、ディスクから読み取られるデータ量も比例して少なくなります。
3. すべてのキーではなく、限られた数のランダムなキーに対して集約を実行する方法。データ内のキー分布が一定の条件を満たしていれば、使用するリソースを抑えながら、十分に正確な結果を得られます。

​

適応型JOINアルゴリズム

ClickHouse は、複数のテーブルを JOIN する際の方法を適応的に選択し、ハッシュ結合を優先しつつ、大きなテーブルが複数ある場合はマージ結合に切り替えます。

​

データレプリケーションとデータ整合性のサポート

ClickHouse は非同期のマルチマスター レプリケーションを使用します。利用可能な任意のレプリカに書き込まれると、残りのすべてのレプリカはバックグラウンドでそのコピーを取得します。システムは、異なるレプリカ間で同一のデータを維持します。ほとんどの障害からの復旧は自動的に行われ、複雑な場合は半自動的に行われます。

詳しくは、データレプリケーション のセクションを参照してください。

​

ロールベースアクセス制御

ClickHouse は、SQLクエリによるユーザーアカウント管理を実装しており、ANSI SQL標準や一般的なリレーショナルデータベース管理システムと同様のロールベースアクセス制御の設定をサポートしています。

​

欠点と見なされることがある特徴

1. 本格的なトランザクションはありません。
2. すでに挿入されたデータを高頻度・低レイテンシで変更または削除するのは苦手です。データのクリーンアップや変更のために、たとえば GDPR への準拠を目的としたバッチ削除や更新は利用できます。
3. スパースインデックスのため、ClickHouse はキーによって単一の行を取得するポイントクエリにはあまり効率的ではありません。