ClickHouse/docs/ja/integrations/data-ingestion/dbms/postgresql/postgres-vs-clickhouse.md

slug	title	keywords
/ja/integrations/postgresql/postgres-vs-clickhouse	PostgreSQLとClickHouseの比較	postgres postgresql comparison

PostgresとClickHouseの比較: 同等および異なる概念

ACIDトランザクションに慣れたOLTPシステムから来たユーザーは、ClickHouseがパフォーマンスのためにこれらを完全に提供しないという意図的な妥協を行っていることを理解しておく必要があります。ClickHouseのセマンティクスは、よく理解されれば、高い耐久性保証と高い書き込みスループットを提供することができます。以下に、PostgresからClickHouseを使用する前に知っておくべきいくつかの重要な概念を示します。

シャードとレプリカ

シャーディングとレプリケーションは、ストレージやコンピュートがパフォーマンスのボトルネックになったときに、1つのPostgresインスタンスを超えてスケーリングするために使用される2つの戦略です。Postgresのシャーディングは、大規模なデータベースを複数のノードに分けて管理しやすくすることです。ただし、Postgresはネイティブにシャーディングをサポートしていません。代わりに、Postgresを水平にスケール可能な分散データベースにする拡張機能であるCitusを使用することでシャーディングを実現できます。このアプローチにより、Postgresは複数のマシンに負荷を分散することで、より高いトランザクションレートとより大きなデータセットを処理できます。シャードは、トランザクション系または分析系のようなワークロードタイプに柔軟性を提供するために、行ベースまたはスキーマベースにすることができます。シャーディングは、データ管理とクエリ実行において、複数のマシン間の調整と一貫性保証が必要なため、かなりの複雑さを生む可能性があります。

シャードとは異なり、レプリカはプライマリノードからの全データまたは一部のデータを含む追加のPostgresインスタンスです。レプリカは、読み取り性能の向上や高可用性（HA）シナリオを含むさまざまな理由で使用されます。物理レプリケーションはPostgresのネイティブ機能であり、すべてのデータベース、テーブル、インデックスを含むデータベース全体またはその大部分を別のサーバーにコピーすることを伴います。これには、プライマリノードからレプリカへのWALセグメントのTCP/IP経由でのストリーミングが含まれます。対照的に、論理レプリケーションは、「INSERT」、「UPDATE」、「DELETE」操作に基づいて変更をストリーミングする、より高い抽象化レベルです。同じ結果が物理レプリケーションにも適用されるかもしれませんが、特定のテーブルと操作を対象にしたり、データの変換や異なるPostgresバージョンをサポートするための柔軟性が高まります。

対照的に、ClickHouseのシャードとレプリカはデータの分散と冗長性に関連する2つの重要な概念です。 ClickHouseのレプリカは、Postgresのレプリカと類似していると思えますが、レプリケーションは最終的に一貫性があり、プライマリの概念がありません。シャーディングは、Postgresとは異なり、ネイティブにサポートされています。

シャードは、テーブルデータの一部です。常に少なくとも1つのシャードがあります。複数のサーバーにわたってシャーディングデータを使用すると、すべてのシャードが並行してクエリを実行するために使用される単一サーバーの容量を超える場合に、負荷を分散できます。ユーザーは、テーブルのシャードを異なるサーバーで手動で作成し、データを直接挿入できます。あるいは、データがどのシャードにルーティングされるかを定義するシャーディングキーを持つ分散テーブルを使用することもできます。シャーディングキーはランダムでも、ハッシュ関数の出力でもかまいません。重要なのは、シャードは複数のレプリカで構成できることです。

レプリカは、データのコピーです。ClickHouseは常にデータの少なくとも1つのコピーを持ち、したがってレプリカの最小数は1です。データの2番目のレプリカを追加すると、耐障害性が向上し、より多くのクエリを処理するための追加のコンピュート能力が得られる可能性があります（Parallel Replicasも使用して、単一のクエリのために計算を分散することができ、これによりレイテンシを下げることができます）。レプリカはReplicatedMergeTreeテーブルエンジンを使用することで実現され、ClickHouseは異なるサーバー間でデータの複数のコピーを同期に保持できます。レプリケーションは物理的で、ノード間で転送されるのは圧縮された部分だけであり、クエリではありません。

要約すると、レプリカは冗長性と信頼性（および潜在的に分散処理）を提供するデータのコピーであり、シャードは分散処理とロードバランシングを可能にするデータのサブセットです。

ClickHouse Cloudは、S3にバックアップされた単一のデータコピーを使用し、複数の計算レプリカを持ちます。データは各レプリカノードで利用可能で、各ノードにはローカルのSSDキャッシュが備わっています。これは、ClickHouse Keeperを介してメタデータのレプリケーションのみを行うことで機能します。

結果整合性

ClickHouseは、その内部レプリケーションメカニズムを管理するためにClickHouse Keeper（C++で実装されたZooKeeper、またはZooKeeper自体も使用可能）を使用し、主にメタデータの保存と最終的一貫性の保証に焦点を当てています。 Keeperは、分散環境での各挿入に対して一意の連番を割り当て、オペレーション間の順序と一貫性を維持するために重要です。このフレームワークはまた、マージや変異といったバックグラウンドの操作を管理し、それらがすべてのレプリカで同じ順序で実行されることを保証しつつ、作業を分散させます。メタデータに加えて、Keeperはレプリケーションの包括的な制御センターとして機能し、保存されたデータ部分のチェックサムを追跡し、レプリカ間の分散通知システムとしても機能します。

ClickHouseのレプリケーションプロセスは、（1）データが任意のレプリカに挿入されると始まります。このデータは、その生の挿入形式のまま、（2）そのチェックサムと共にディスクに書き込まれます。書き込まれると、レプリカは（3）Keeperにおいてこの新しいデータ部分を登録し、一意のブロック番号を割り当てて新しい部分の詳細を記録しようとします。他のレプリカは、（4）レプリケーションログ内の新しいエントリを検出すると、（5）ZooKeeperにリストされたチェックサムと照合しながら、内部のHTTPプロトコルを介して対応するデータ部分をダウンロードします。この方法により、処理速度が異なる場合や潜在的な遅延が発生しても、すべてのレプリカが最終的に一貫性があり最新のデータを保持することを保証します。さらに、このシステムは複数の操作を同時に処理する能力があり、データ管理プロセスを最適化し、システムのスケーラビリティとハードウェアの違いに対する堅牢性を保証します。

<img src={require('../images/postgres-replicas.png').default}
class="image" alt="NEEDS ALT" style={{width: '500px'}} />

ClickHouse Cloudは、ストレージとコンピュートのアーキテクチャを分離するために適応されたクラウド最適化レプリケーションメカニズムを使用しています。共有オブジェクトストレージにデータを保存することで、ノード間で物理的なデータの複製を必要とせずに、すべての計算ノードでデータが自動的に利用可能になります。その代わりに、Keeperを使用してコンピュートノード間でメタデータ（オブジェクトストレージ内のどこにデータが存在するか）を共有するだけです。

PostgreSQLは、主にプライマリレプリカモデルを使用してデータをプライマリから1つ以上のレプリカノードに連続的にストリーミングするストリーミングレプリケーションを主なレプリケーション戦略として採用しています。このタイプのレプリケーションは、リアルタイムに近い一貫性を保証し、同期または非同期であり、管理者に可用性と一貫性のバランスを取る制御を与えます。ClickHouseとは異なり、PostgreSQLは論理レプリケーションとデコードを使用したWAL（Write-Ahead Logging）に依存して、ノード間でデータオブジェクトと変更をストリーミングします。このアプローチはPostgreSQLではより直接的であるが、ClickHouseがその複雑なKeeperの分散操作の調整とイベントチュアルコンシステンシによって達成する非常に分散された環境での同じレベルのスケーラビリティと耐障害性を提供するかもしれません。

ユーザーへの影響

ClickHouseでは、あるレプリカにデータを書き込んでから、別のレプリカから未レプリケートのデータを読み取る可能性のあるダーティリードが発生する可能性があります。これは、Keeperを通じて管理される最終的に一貫したレプリケーションモデルによるもので、このモデルは分散システム全体でパフォーマンスとスケーラビリティを強調し、レプリカが独立して操作し、非同期で同期することを許可します。結果として、新しく挿入されたデータは、レプリケーションの遅延とシステム全体で変更が伝播するのにかかる時間に応じて、すぐにすべてのレプリカで表示されないことがあります。

対照的に、PostgreSQLのストリーミングレプリケーションモデルは、通常、同期レプリケーションオプションを使用することでダーティリードを防ぐことができ、プライマリが少なくとも1つのレプリカにデータ受信を確認するまで待機してトランザクションをコミットします。これにより、トランザクションがコミットされると、別のレプリカでデータが利用可能であるという保証が得られます。プライマリの障害が発生した場合、レプリカはクエリがコミットされたデータを確認することを保証し、より厳格な一貫性のレベルを維持します。

推奨事項

ClickHouseに新しく移行するユーザーは、レプリケート環境でこれらの違いが表れることを認識しておくべきです。通常、数十億から数兆に及ぶデータポイントに対する分析では、最終的な一貫性が十分であり、メトリクスがより安定しているか、あるいは推定が十分であるため、新しいデータが高速で継続的に挿入されています。

読み取りの一貫性を高めるためのオプションはいくつか存在します。これらの例はどちらも、クエリパフォーマンスを低下させ、ClickHouseのスケーリングをより難しくするために、複雑さやオーバーヘッドの増加を必要とします。これらのアプローチを必要に応じてのみ推奨します。

一貫したルーティング

最終的な一貫性の限界を克服するために、ユーザーはクライアントが同じレプリカにルーティングされるようにすることができます。これは、MultipleユーザーがClickHouseでクエリを実行し、その結果を要求間で決定論的にする必要がある場合に役立ちます。新しいデータが挿入されるため、結果が異なる可能性がありますが、同じレプリカがクエリされることで一貫したビューが保証されます。

使用しているアーキテクチャやClickHouse OSSまたはClickHouse Cloudを使用しているかによって、いくつかのアプローチが可能です。

ClickHouse Cloud

ClickHouse Cloudは、S3にバックアップされた単一のデータコピーを使用し、複数の計算レプリカを持っています。データはローカルのSSDキャッシュを持つ各レプリカノードで利用可能です。ユーザーは同じノードへの一貫したルーティングを確実にするだけで、一貫した結果が得られます。

ClickHouse Cloudサービスのノードへの通信はプロキシ経由で行われます。HTTPおよびネイティブプロトコル接続は、それらが開いている間同じノードにルーティングされます。HTTP 1.1接続がほとんどのクライアントから行われる場合、これはKeep-Aliveウィンドウに依存します。これは、Node Jsなどのほとんどのクライアントで設定できます。これには、サーバー側の設定が必要であり、クライアントよりも高いものであり、ClickHouse Cloudでは10sに設定されています。

接続プールを使用している場合や接続が期限切れになる場合には、同じ接続を使用する（ネイティブでより容易）か、スティッキーエンドポイントの公開を要求することもできます。これにより、クライアントがクエリを決定論的にルーティングできるようにするために、クラスター内の各ノードのいくつかのエンドポイントが提供されます。

スティッキーエンドポイントへのアクセスを得るには、サポートに連絡してください。

ClickHouse OSS

OSSでこの動作を実現するには、シャードとレプリカのトポロジーおよびクエリのために分散テーブルを使用しているかが依存します。

シャードが1つだけの時とレプリカのある時（ClickHouseが垂直にスケールするために一般的）は、ユーザーはクライアントレイヤーでノードを選択し、直接レプリカをクエリして、これが決定論的に選ばれることを確認します。

分散テーブルを持たない複数のシャードとレプリカを持つトポロジが可能ですが、これらの高度なデプロイメントは通常独自のルーティングインフラストラクチャを持っています。したがって、複数のシャードを持つデプロイメントは分散テーブルを使用していると想定します（単一シャードデプロイメントでも分散テーブルを使用できますが、通常は必要ありません）。

この場合、ユーザーはsession_idやuser_idなどのプロパティに基づいて一貫したノードルーティングを行う必要があります。設定prefer_localhost_replica=0、load_balancing=in_orderはクエリで設定するべきです。これにより、シャードのローカルレプリカが優先され、エラー数が同じ場合は設定にリストされている順にレプリカが優先されることが保証されます。エラーが高い場合はランダム選択でフェイルオーバーが発生します。load_balancing=nearest_hostnameも、この決定論的シャード選択の代替として使用できます。

分散テーブルを作成する際、ユーザーはクラスターを指定します。このクラスター定義はconfig.xmlで指定され、シャード（およびそのレプリカ）がリストされます。これにより、ユーザーは各ノードから使用される順序を制御できます。これを使用することで、ユーザーは選択が決定論的であることを確認できます。

シーケンシャルコンシステンシ

例外的なケースでは、ユーザーはシーケンシャルコンシステンシを必要とすることがあります。

データベースでのシーケンシャルコンシステンシとは、データベース上の操作があるシーケンス順で実行されるように見え、その順序がデータベースと対話するすべてのプロセスで一貫していることです。つまり、各操作がその呼び出しと完了の間に瞬間的に効果を発揮し、すべての操作がどのプロセスによっても観察される単一の合意された順序があることを意味します。

ユーザーの観点からは、通常、ClickHouseにデータを書き込み、データを読み出す際に最新の挿入された行が返されることを保証する必要がある場合に現れます。 これはいくつかの方法で実現できます（優先順）：

1. 同じノードへの読み書き - ネイティブプロトコルを使用している場合、またはHTTP経由でのセッションでの書き込み/読み取りを行っている場合、あなたは同じレプリカに接続されているはずです。このシナリオでは、あなたが書き込んでいるノードから直接読み取るため、一貫した読み取りが保証されます。
2. 手動でのレプリカの同期 - 1つのレプリカに書き込み、別のレプリカから読み取る場合、SYSTEM SYNC REPLICA LIGHTWEIGHTを発行してから読み取ることができます。
3. シーケンシャルコンシステンシの有効化 - クエリ設定select_sequential_consistency = 1を通じて。OSSでは、insert_quorum = 'auto'も指定する必要があります。

これらの設定を有効にする詳細についてはこちらを参照してください。

シーケンシャルコンシステンシの使用は、ClickHouse Keeperに負荷をかける可能性があります。その結果として、挿入と読み取りが遅くなる可能性があります。SharedMergeTreeは、ClickHouse Cloudの主要なテーブルエンジンとして使用されており、シーケンシャルコンシステンシは少ないオーバーヘッドを発生し、より良くスケールします。OSSユーザーはこのアプローチを慎重に使用し、Keeperの負荷を測定するべきです。

トランザクション（ACID）サポート

PostgreSQLから移行するユーザーは、トランザクションデータベースとしてPostgreSQLを信頼できる選択肢にする、ACID（Atomicity, Consistency, Isolation, Durability）特性への強力なサポートに慣れているかもしれません。PostgreSQLのアトミシティは、各トランザクションが単一のユニットとして扱われ、完全に成功するか、完全にロールバックされることで、部分的な更新を防ぎます。整合性は、すべてのデータベーストランザクションが有効な状態をもたらすことを保証する制約、トリガ、およびルールを強制することによって維持されます。読み取りコミットからSerializableまでの隔離レベルは、PostgreSQLでサポートされており、並行トランザクションによって行われた変更の可視性に対する詳細な制御を可能にします。最後に、耐久性は書き込み先行ログ（WAL）によって達成され、トランザクションがコミットされると、システム障害が発生してもそれを維持します。

これらの特性は、真実の源として機能するOLTPデータベースに共通です。

強力である一方で、これは固有の制約とPBスケールを取り扱うことの難しさをもたらします。ClickHouseは、これらの特性を犠牲にして、高速な分析クエリをスケールで提供しつつ高い書き込みスループットを維持します。

ClickHouseは、限られた構成の下でACID特性を提供しています - もっとも単純には、MergeTreeテーブルエンジンを使用している非レプリケートのインスタンスで1つのパーティションのみを使用している場合です。ユーザーは、これらのケースを除いてこれらの特性を期待するべきではなく、これが要求ではないことを確認してください。

PeerDBによるPostgresデータのレプリケーションまたは移行

ClickHouse, Inc.は、Postgresレプリケーション会社であるPeerDBを買収しました。PeerDBを使用すると、PostgresからClickHouseへのデータのシームレスなレプリケーションを可能にします。このツールを使用して、a）PostgresとClickHouseを共存させるCDCを使用した継続的なレプリケーションを行ったり、b）PostgresからClickHouseへの移行を行ったりできます。