メインコンテンツまでスキップ
メインコンテンツまでスキップ

BigQuery対ClickHouse Cloud: 同等および異なる概念

リソースの組織

ClickHouse Cloudにおけるリソースの組織方法は、BigQueryのリソース階層に似ています。以下のClickHouse Cloudのリソース階層を示す図に基づいて、具体的な違いを説明します。

NEEDS ALT

組織

BigQueryと同様に、組織はClickHouse Cloudリソース階層のルートノードです。ClickHouse Cloudアカウントに最初に設定したユーザーは、自動的にそのユーザーが所有する組織に割り当てられます。このユーザーは、他のユーザーをその組織に招待することができます。

BigQueryプロジェクト対ClickHouse Cloudサービス

組織内で、ClickHouse Cloudにおけるサービスは、BigQueryプロジェクトに緩やかに相当します。なぜなら、ClickHouse Cloud内に保存されたデータはサービスに関連付けられるからです。ClickHouse Cloudには、いくつかのサービスタイプが利用可能です。各ClickHouse Cloudサービスは、特定のリージョンに展開され、以下を含みます。

  1. 計算ノードのグループ(現在、開発ティアサービスには2ノード、プロダクションティアサービスには3ノード)。これらのノードに対して、ClickHouse Cloudは手動および自動での垂直および水平方向のスケーリングをサポートしています
  2. サービスがすべてのデータを保存するオブジェクトストレージフォルダー。
  3. エンドポイント(またはClickHouse Cloud UIコンソールを介して作成された複数のエンドポイント) - サービスに接続するために使用するサービスURL(例:https://dv2fzne24g.us-east-1.aws.clickhouse.cloud:8443

BigQueryデータセット対ClickHouse Cloudデータベース

ClickHouseは論理的にテーブルをデータベースにグループ化します。BigQueryデータセットと同様に、ClickHouseデータベースはテーブルデータの整理とアクセス制御を行う論理的コンテナです。

BigQueryフォルダー

ClickHouse Cloudには、現在BigQueryのフォルダーに相当する概念はありません。

BigQueryスロット予約とクォータ

BigQueryスロット予約のように、ClickHouse Cloudでは垂直および水平方向のオートスケーリングを構成することができます。垂直オートスケーリングでは、サービスの計算ノードのメモリとCPUコアの最小および最大サイズを設定できます。サービスは、その範囲内で必要に応じてスケールします。これらの設定は、初回のサービス作成フローでも利用可能です。サービス内の各計算ノードは同じサイズです。サービス内の計算ノードの数は水平方向のスケーリングを使用して変更できます。

さらに、BigQueryのクォータに似て、ClickHouse Cloudは同時実行制御、メモリ使用量制限、I/Oスケジューリングを提供し、ユーザーがクエリをワークロードクラスに隔離することを可能にします。特定のワークロードクラスに対して共有リソース(CPUコア、DRAM、ディスクおよびネットワークI/O)の制限を設定することで、これらのクエリが他の重要なビジネスクエリに影響を及ぼさないようにします。同時実行制御は、高数の同時クエリがあるシナリオにおいてスレッドのオーバーサブスクリプションを防止します。

ClickHouseは、サーバー、ユーザー、クエリレベルでのメモリ割り当てのバイトサイズを追跡し、柔軟なメモリ使用制限を可能にします。メモリオーバーコミットにより、保証されたメモリを超えて追加の空きメモリをクエリが使用できるようにし、他のクエリのためのメモリ制限を保証します。さらに、集計、ソート、および結合句に対するメモリ使用量を制限できるため、メモリ制限を超えた場合には外部アルゴリズムにフォールバックすることができます。

最後に、I/Oスケジューリングは、ユーザーがワークロードクラスに対して最大帯域幅、処理中のリクエスト、およびポリシーに基づいてローカルおよびリモートディスクアクセスを制限できるようにします。

権限

ClickHouse Cloudは、クラウドコンソールとデータベースを通じて、ユーザーアクセスを制御します。コンソールアクセスは、clickhouse.cloudユーザーインターフェースを介して管理されます。データベースアクセスは、データベースユーザーアカウントとロールを介して管理されます。さらに、コンソールユーザーには、SQLコンソールを通じてデータベースと対話できるようにするロールが付与されることがあります。SQLコンソールを介して。

データ型

ClickHouseは数値に関してより詳細な精度を提供します。例えば、BigQueryはINT64NUMERICBIGNUMERICFLOAT64という数値型を提供します。これに対し、ClickHouseは小数、浮動小数点数、整数のための複数の精度型を提供しています。これらのデータ型を使用することで、ClickHouseユーザーはストレージとメモリのオーバーヘッドを最適化し、結果としてクエリの高速化とリソース消費の低減を実現できます。以下に、それぞれのBigQuery型に対するClickHouse型の対応を示します。

BigQueryClickHouse
ARRAYArray(t)
NUMERICDecimal(P, S)、Decimal32(S)、Decimal64(S)、Decimal128(S)
BIG NUMERICDecimal256(S)
BOOLBool
BYTESFixedString
DATEDate32 (範囲が狭い)
DATETIMEDateTimeDateTime64 (範囲が狭く、精度が高い)
FLOAT64Float64
GEOGRAPHYGeo Data Types
INT64UInt8、UInt16、UInt32、UInt64、UInt128、UInt256、Int8、Int16、Int32、Int64、Int128、Int256
INTERVALNA - 式としてサポート または 関数を通じて
JSONJSON
STRINGString (bytes)
STRUCTTupleNested
TIMEDateTime64
TIMESTAMPDateTime64

ClickHouse型の選択肢が複数存在する場合は、データの実際の範囲を考慮し、必要な最小限の型を選択してください。また、さらなる圧縮のために適切なコーデックを利用することを検討してください。

クエリ加速技術

主キーおよび外部キー、主インデックス

BigQueryでは、テーブルに主キーと外部キー制約を持たせることができます。通常、主キーおよび外部キーは、リレーショナルデータベースでデータの整合性を確保するために使用されます。主キーの値は通常、各行で一意であり、NULLではありません。行内の各外部キーの値は、主キーが設定されたテーブルの主キー列に存在するか、NULLである必要があります。BigQueryではこれらの制約は強制されませんが、クエリオプティマイザーはこの情報を利用してクエリを最適化することができます。

ClickHouseでもテーブルに主キーを持たせることができます。BigQueryと同様に、ClickHouseはテーブルの主キー列の値の一意性を強制しません。BigQueryとは異なり、ClickHouseのテーブルデータは主キー列で順序付けられた形でディスクに保存されます。クエリオプティマイザーはこのソート順序を利用して再ソートを防ぎ、結合に必要なメモリ使用量を最小限に抑え、制限句のショートサーキットを有効にします。ClickHouseでは、主キー列の値に基づいて(スパース)主インデックスが自動的に作成されます。このインデックスは、主キー列にフィルターを含むすべてのクエリの速度を向上させるために使用されます。現在、ClickHouseは外部キー制約をサポートしていません。

セカンダリインデックス(ClickHouse専用)

テーブルの主キー列の値から作成された主インデックスに加えて、ClickHouseでは主キー以外のカラムにセカンダリインデックスを作成することができます。ClickHouseは、さまざまなクエリタイプに適したいくつかのタイプのセカンダリインデックスを提供しています:

  • ブルームフィルターインデックス:
    • 等価条件のあるクエリを加速するために使用されます(例:=、IN)。
    • 確率的データ構造を使用して、データブロックに値が存在するかどうかを判定します。
  • トークンブルームフィルターインデックス:
    • ブルームフィルターインデックスに似ていますが、トークン化された文字列用で、全文検索クエリに適しています。
  • 最小・最大インデックス:
    • 各データパーツのカラムの最小値と最大値を保持します。
    • 指定された範囲に含まれないデータパーツの読み取りをスキップするのに役立ちます。

検索インデックス

BigQueryの検索インデックスに似て、ClickHouseのテーブルに文字列値を持つカラムに対して全文検索インデックスを作成できます。

ベクトルインデックス

BigQueryは最近、ベクトルインデックスをPre-GA機能として導入しました。同様に、ClickHouseはベクトル検索ユースケースを加速するためのインデックスに実験的に対応しています。

パーティショニング

BigQueryと同様に、ClickHouseはテーブルを小さく、管理可能な部分(パーティションと呼ばれる)に分けることで、大規模なテーブルのパフォーマンスと管理性を向上させるためのテーブルパーティショニングを利用します。ClickHouseのパーティショニングについての詳細はこちらで説明しています。

クラスタリング

クラスタリングにより、BigQueryは指定された数のカラムの値に基づいてテーブルデータを自動的にソートし、最適なサイズのブロックに配置します。クラスタリングはクエリパフォーマンスを向上させ、BigQueryがクエリの実行コストをより良く推定できるようにします。クラスタリングされたカラムを使用すると、不要なデータのスキャンを排除することもできます。

ClickHouseでは、データが自動的にディスク上でクラスタリングされるため、テーブルの主キー列に基づいて論理的に配置され、クエリが主インデックスデータ構造を利用することで迅速に特定されたり、剪定されたりします。

マテリアライズドビュー

BigQueryとClickHouseの両方は、性能と効率を向上させるために基底テーブルに対する変換クエリの結果に基づく事前計算された結果を持つマテリアライズドビューをサポートしています。

マテリアライズドビューのクエリ

BigQueryのマテリアライズドビューは直接クエリでき、オプティマイザーが基底テーブルへのクエリを処理するために使用することができます。基底テーブルに対する変更がマテリアライズドビューを無効にする可能性がある場合、データは直接基底テーブルから読み取られます。基底テーブルに対する変更がマテリアライズドビューを無効にしない場合、残りのデータはマテリアライズドビューから読み取られ、変更のみが基底テーブルから読み取られます。

ClickHouseでは、マテリアライズドビューは直接クエリのみ可能です。ただし、基底テーブルに変更があった際、BigQueryではマテリアライズドビューが変更後5分以内に自動的に更新されますが、頻度は30分ごとまでです。一方、ClickHouseではマテリアライズドビューは常に基底テーブルと同期しています。

マテリアライズドビューの更新

BigQueryでは、マテリアライズドビューが定期的に基底テーブルに対してビューの変換クエリを実行することで完全に更新されます。更新の合間に、BigQueryはマテリアライズドビューのデータを新しい基底テーブルデータと結合し、一貫したクエリ結果を提供します。

ClickHouseでは、マテリアライズドビューは段階的に更新されます。この段階的更新メカニズムは高いスケーラビリティと低コストを提供します:段階的に更新されたマテリアライズドビューは、基底テーブルに数十億または数兆の行が含まれるシナリオに特に適しています。マテリアライズドビューを更新するために基底テーブルを繰り返しクエリするのではなく、ClickHouseは新しく挿入された基底テーブル行の値から(のみ)部分的な結果を計算します。この部分的な結果は、以前に計算された部分的な結果とバックグラウンドで段階的に統合されます。これにより、マテリアライズドビューを基底テーブル全体から繰り返し更新することに比べ、計算コストが大幅に削減されます。

トランザクション

ClickHouseとは対照的に、BigQueryはセッションを使用する際に、単一のクエリ内または複数のクエリにまたがってマルチステートメントトランザクションをサポートしています。マルチステートメントトランザクションでは、1つまたは複数のテーブルに対して行の挿入や削除といった変更操作を行い、変更を原子性でコミットまたはロールバックできます。マルチステートメントトランザクションは、ClickHouseの2024年のロードマップにあります。

集約関数

ClickHouseはBigQueryと比較して、かなり多くのビルトイン集約関数を提供しています:

データソースとファイル形式

ClickHouseはBigQueryと比較して、かなり多くのファイル形式とデータソースをサポートしています:

  • ClickHouseは、ほぼすべてのデータソースから90以上のファイル形式でデータをロードするためのネイティブサポートを持っています。
  • BigQueryは5つのファイル形式と19のデータソースをサポートしています。

SQL言語機能

ClickHouseは、解析タスクにより親しみやすくする多くの拡張と改善を提供する標準SQLを提供しています。例えば、ClickHouse SQLはラムダ関数や高階関数をサポートしているため、変換を適用する際に配列をアンネスト/エクスプロードする必要がありません。これは、BigQueryなどの他のシステムに対する大きな利点です。

配列

BigQueryの8つの配列関数と比較して、ClickHouseは広範囲の問題を優雅で簡単にモデル化し解決するための80以上のビルトイン配列関数を持っています。

ClickHouseにおける典型的なデザインパターンは、groupArray集約関数を使用して、テーブルの特定の行の値を(一時的に)配列に変換することです。これは、その後配列関数で便利に処理でき、結果はarrayJoin集約関数を介して個々のテーブル行に戻すことができます。

ClickHouse SQLは高階ラムダ関数をサポートしているため、配列を一時的にテーブルに戻すのではなく、高階ビルトイン配列関数のいずれかを単に呼び出すことで、多くの高度な配列操作を実現できます。これは、通常、BigQueryでフィルタリングジッピングのための要件となるものです。ClickHouseではこれらの操作は単純な関数呼び出しとして扱われ、各々高階関数arrayFilterarrayZipを呼び出すことで実行されます。

次に、BigQueryからClickHouseへの配列操作のマッピングを提供します:

BigQueryClickHouse
ARRAY_CONCATarrayConcat
ARRAY_LENGTHlength
ARRAY_REVERSEarrayReverse
ARRAY_TO_STRINGarrayStringConcat
GENERATE_ARRAYrange

サブクエリ内の各行に対して1つの要素を持つ配列を作成する

_ BigQuery_

ARRAY function

_ ClickHouse_

groupArray集約関数

配列を行の集合に変換する

_ BigQuery_

UNNEST演算子

_ ClickHouse_

ARRAY JOIN

日付の配列を返す

_ BigQuery_

GENERATE_DATE_ARRAY関数

_ ClickHouse_

range + arrayMap関数

タイムスタンプの配列を返す

_ BigQuery_

GENERATE_TIMESTAMP_ARRAY関数

_ ClickHouse_

range + arrayMap関数

配列のフィルタリング

_ BigQuery_

UNNEST演算子を介して配列を一時的にテーブルに戻す必要があります。

_ ClickHouse_

arrayFilter関数

配列のジッピング

_ BigQuery_

UNNEST演算子を介して配列を一時的にテーブルに戻す必要があります。

_ ClickHouse_

arrayZip関数

配列の集約

_ BigQuery_

UNNEST演算子を通じて配列を一時的にテーブルに戻す必要があります。

_ ClickHouse_

arraySumarrayAvgなどの関数、または引数として引数のあるどの集約関数名でも使用できます。