このページでは、AlloyDB Omni バージョン 15.7.0 のドキュメントについて説明します。
AlloyDB Omni のドキュメントのバージョンに移動して、別のバージョンを選択します。

このページは Cloud Translation API によって翻訳されました。

AlloyDB Omni の概要

AlloyDB Omni は、ダウンロード可能なデータベースソフトウェアパッケージで、独自のコンピューティング環境に AlloyDB for PostgreSQL の簡素化されたバージョンをデプロイできます。AlloyDB Omni と Google Cloud のフルマネージド AlloyDB for PostgreSQL サービスは、同じコアコンポーネントを共有しています。AlloyDB for PostgreSQL は、WAL のパフォーマンスを最適化するクラウドネイティブストレージレイヤを使用しますが、AlloyDB Omni は PostgreSQL で使用されているのと同じ標準ファイルシステムインターフェースを使用します。

AlloyDB Omni のポータビリティにより、次のような多くの環境で実行できます。

データセンター
ノートパソコン
クラウドベースの VM インスタンス

AlloyDB Omni のユースケース

AlloyDB Omni は、次のようなシナリオに適しています。

スケーラブルでパフォーマンスの高いバージョンの PostgreSQL が必要ですが、規制要件またはデータ主権要件により、クラウドでデータベースを実行できません。
インターネットから切断されても実行を続けるデータベースが必要です。
レイテンシを最小限に抑えるには、データベースをユーザーの地理的位置にできるだけ近づける必要があります。
完全なクラウドへの移行にコミットせずに、レガシーデータベースから移行する方法がほしい。

AlloyDB Omni には、 Google Cloudのオペレーションに依存する AlloyDB for PostgreSQL の機能は含まれていません。プロジェクトを AlloyDB for PostgreSQL のフルマネージドスケーリング、セキュリティ、可用性機能にアップグレードする場合は、他の初期データのインポートと同様に、AlloyDB Omni データを AlloyDB for PostgreSQL クラスタに移行できます。

主な機能

PostgreSQL 互換のデータベースサーバー。
AlloyDB AI のサポート。運用データを使用してエンタープライズグレードの生成 AI アプリケーションを構築できます。
Vertex AI Model Garden やオープンソースの生成 AI ツールなど、 Google Cloud AI エコシステムとの統合。
Google Cloud で AlloyDB for PostgreSQL の自動パイロット機能をサポート。これにより、AlloyDB Omni をセルフマネージドおよびセルフチューニングできます。

たとえば、AlloyDB Omni は、自動メモリ管理と古いデータの適応型自動バキュームをサポートしています。
頻繁に実行されるクエリを分析し、クエリのパフォーマンスを向上させる新しいインデックスを推奨するインデックスアドバイザー。
AlloyDB Omni のカラム型エンジン。頻繁にクエリされるデータをインメモリカラム型形式で保持し、ビジネスインテリジェンス、レポート、ハイブリッドトランザクション処理と分析処理（HTAP）のワークロードでパフォーマンスを向上させます。

Google のパフォーマンステストでは、AlloyDB Omni のトランザクションワークロードは標準の PostgreSQL よりも 2 倍以上高速で、分析クエリは最大 100 倍高速です。

AlloyDB Omni の仕組み

AlloyDB Omni は、スタンドアロンサーバーとして、または Kubernetes 環境の一部としてインストールできます。

AlloyDB Omni は、独自の環境にインストールした Docker コンテナで実行されます。AlloyDB Omni は、SSD ストレージと CPU あたり 8 GB 以上のメモリを備えた Linux システムで実行することをおすすめします。

AlloyDB Omni Kubernetes オペレーターは、ほとんどの CNCF 準拠の Kubernetes 環境で AlloyDB Omni を実行できるようにする Kubernetes API の拡張機能です。詳細については、Kubernetes に AlloyDB Omni をインストールするをご覧ください。

アプリケーションが標準の PostgreSQL データベースサーバーに接続して通信するのと同じように、アプリケーションは AlloyDB Omni インストールに接続して通信します。ユーザーアクセス制御も PostgreSQL 標準に依存しています。

ロギングからバキューム、列エンジンまで、データベースフラグを使用して AlloyDB Omni のデータベース動作を構成できます。

AlloyDB Omni をコンテナとして実行するメリット

Google は、Docker や Podman などのコンテナランタイムで実行できるコンテナとして AlloyDB Omni を配布しています。運用面では、コンテナには次のような利点があります。

透明な依存関係管理: 必要な依存関係はすべてコンテナにバンドルされ、Google によってテストされ、AlloyDB Omni と完全に互換性があることが確認されています。
ポータビリティ: AlloyDB Omni は、環境間で一貫して動作します。
セキュリティの分離: AlloyDB Omni コンテナがホストマシンでアクセスできる内容を選択します。
リソース管理: AlloyDB Omni コンテナで使用するコンピューティングリソースの量を定義できます。
シームレスなパッチ適用とアップグレード: コンテナにパッチを適用するには、既存のイメージを新しいイメージに置き換えるだけです。

データのバックアップと障害復旧

AlloyDB Omni には、調整可能な保持期間内の任意の時点に基づいて新しいデータベースクラスタを作成できる継続的なバックアップと復元システムが用意されています。これにより、データ損失の事故から迅速に復旧できます。

さらに、AlloyDB Omni では、データベースクラスタのデータの完全なバックアップをオンデマンドで、または定期的に作成して保存できます。バックアップから AlloyDB Omni データベースクラスタに復元できます。このクラスタには、バックアップの作成時点で元のデータベースクラスタのすべてのデータが含まれています。

詳細については、AlloyDB Omni のバックアップと復元をご覧ください。

障害復旧のもう 1 つの方法として、別のデータセンターにセカンダリデータベースクラスタを作成することで、データセンター間のレプリケーションを実現できます。AlloyDB Omni は、指定されたプライマリデータベースクラスタから各セカンダリクラスタにデータを非同期でストリーミングします。必要に応じて、セカンダリデータベースクラスタをプライマリ AlloyDB Omni データベースクラスタに昇格できます。

詳細については、クロスデータセンターレプリケーションについてをご覧ください。

AlloyDB Omni VM コンポーネント

VM 上の AlloyDB Omni は、AlloyDB for PostgreSQL の拡張機能を含む PostgreSQL コンポーネントと AlloyDB for PostgreSQL コンポーネントの 2 つのアーキテクチャコンポーネントで構成されています。次の図は、両方のコンポーネントセット、VM またはサーバーのどのインフラストラクチャレイヤに存在するか、各コンポーネントで期待できる関連機能の概要を示しています。

AlloyDB for PostgreSQL 固有のコンポーネントを PostgreSQL コンポーネントから分離した AlloyDB Omni コンポーネントアーキテクチャ図。

図 1: AlloyDB Omni アーキテクチャ

データベースエンジン

このドキュメントでは、コンテナ内の AlloyDB Omni のデータベースアーキテクチャについて説明します。このドキュメントは、PostgreSQL に精通していることを前提としています。

データベースエンジンは次のタスクを実行します。

クライアントからのクエリを実行可能なプランに変換します。
クエリを満たすために必要なデータを検索します。
必要なフィルタリング、並べ替え、集計を実行します。
結果をクライアントに返します。

図 1. クライアントアプリケーションからのクエリに応答するために連携するデータベースレイヤを示しています。

クライアントアプリケーションが AlloyDB Omni にクエリを送信すると、次の処理が行われます。

クエリ処理レイヤは、クエリをクエリ実行レイヤに渡す実行プランに変換します。
クエリ実行レイヤは、クエリへのレスポンスを計算するために必要なオペレーションを実行します。
実行中に、データはバッファキャッシュから読み込まれるか、ストレージから直接読み込まれます。データがストレージから読み込まれると、ストレージのデータは将来の使用のためにキャッシュに保存されます。

クライアントのクエリの処理に使用されるリソースには、CPU、メモリ、I/O、ネットワーク、データベースロックなどの同期プリミティブが含まれます。パフォーマンスチューニングは、クエリ実行の各ステップでリソース使用率を最適化することを目的としています。

高パフォーマンスのデータベースエンジンの目標は、必要なリソースを最小限に抑えてクエリに応答することです。この目標を達成するには、優れたデータモデルとクエリ設計から始めます。

最小限のデータを確認しながらクエリに回答するにはどうすればよいですか？
検索空間と I/O を削減するために必要なインデックス
データの並べ替えには CPU が必要であり、大規模なデータセットの場合はディスクアクセスも必要になるため、データの並べ替えを回避するにはどうすればよいでしょうか。

データストレージ

AlloyDB Omni は、基盤となるファイルシステムに保存される固定サイズのページにデータを保存します。クエリがデータにアクセスする必要がある場合、AlloyDB Omni はまずバッファプールをチェックします。必要なデータを保持するページがバッファプールにない場合、AlloyDB Omni は必要なページをファイルシステムから読み取ります。バッファプールからのデータへのアクセスは、ファイルシステムからの読み取りよりもはるかに高速です。そのため、アプリケーションがアクセスするデータ量に合わせてバッファプールのサイズを最大化することが重要な要素となります。

リソース管理

AlloyDB Omni は、動的メモリ管理を使用して、システムのメモリ需要に応じて、構成された境界内でバッファプールを動的に拡大および縮小します。したがって、バッファプールサイズを調整する必要はありません。パフォーマンスの問題を診断する際は、まずバッファプールのヒット率と読み取り率の指標を検討して、アプリケーションがバッファプールのメリットを享受しているかどうかを確認します。収まらない場合は、アプリケーションのデータセットがバッファプールに収まらないことを示します。メモリ容量の大きいマシンにサイズを変更することを検討してください。

データの取得、フィルタリング、集計、並べ替え、投影のプロセスには、データベースサーバー上の CPU リソースが必要です。このプロセスに必要な CPU リソースの量を減らすには、操作する必要があるデータの量を最小限に抑えます。データベースサーバーの CPU 使用率をモニタリングし、安定状態の使用率が 70% 程度であることを確認します。この量により、使用率の急増やアクセスパターンの変化に応じて、サーバーに十分なヘッドルームが確保されます。使用率が 100% に近づくと、プロセスのスケジューリングとコンテキストスイッチングによるオーバーヘッドが発生し、システムの他の部分でボトルネックが発生する可能性があります。高い CPU 使用率は、マシンの仕様を決定する際に使用するもう 1 つの重要な指標です。

1 秒あたりの入出力オペレーション（IOPS）は、データベースアプリケーションのパフォーマンスにおいて重要な要素です。これは、基盤となるストレージデバイスがデータベースに提供できる 1 秒あたりの入出力オペレーションの数です。データベースストレージの IOPS の上限に達しないようにするには、バッファプールに収まるデータ量を最大化して、ストレージへの読み取りと書き込みを最小限に抑えます。

カラム型エンジン

カラム型エンジンは、次のコンポーネントを提供することで、スキャン、結合、集計の SQL クエリ処理を高速化します。

インメモリ列ストア: 選択した列のテーブルデータとマテリアライズドビューデータを列指向形式で格納します。デフォルトでは、列ストアは 1 GB の使用可能なメモリを使用します。カラムストアで使用可能なメモリ量を変更するには、AlloyDB Omni インスタンスで使用される postgresql.conf で google_columnar_engine.memory_size_in_mb パラメータを設定します。

パラメータを変更する方法の詳細については、構成パラメータを変更するをご覧ください。
カラム型クエリプランナーと実行エンジン: クエリで列ストアを使用できます。

自動的なメモリ管理

自動メモリマネージャーは、AlloyDB Omni インスタンス全体のメモリ使用量を継続的にモニタリングして最適化します。ワークロードを実行すると、このモジュールはメモリ圧力に基づいて共有バッファキャッシュのサイズを調整します。デフォルトでは、自動メモリマネージャーは上限をシステムメモリの 80% に設定し、共有バッファキャッシュにシステムメモリの 10% を割り当てます。共有バッファキャッシュのサイズの上限を変更するには、AlloyDB Omni インスタンスで使用される postgresql.conf に shared_buffers パラメータを設定します。

詳細については、自動メモリ管理をご覧ください。

適応型自動バキューム

適応型自動バキュームは、データベースのワークロードに基づいてオペレーションを分析し、バキュームの頻度を自動的に調整します。この自動調整により、ワークロードが変化しても、バキュームプロセスによる干渉なしで、データベースをピークパフォーマンスで実行できます。

適応型自動バキュームは、次の要素に基づいてバキュームオペレーションの頻度と強度を決定します。

データベースのサイズ
データベース内のデッドタプルの数
データベース内のデータの年齢
1 秒あたりのトランザクション数と推定バキューム速度

適応型自動バキュームには次のような利点があります。

動的バキュームリソース管理: AlloyDB Omni では、固定費用制限の代わりにリアルタイムのリソース統計情報を使用して、バキュームワーカーが調整されます。システムの負荷が高い場合には、バキュームプロセスと関連するリソース使用率がスロットリングされます。十分なメモリが使用可能な場合は、エンドツーエンドのバキューム時間を短縮するために、maintenance_work_mem に追加のメモリが割り当てられます。
動的 XID スロットリング: バキューム処理の進捗状況とトランザクション ID の消費速度を自動的かつ継続的にモニタリングします。トランザクション ID ラップアラウンドのリスクが検知されると、AlloyDB Omni はトランザクションの処理速度を遅くして ID の使用量をスロットリングします。また、AlloyDB Omni は、トランザクション ID スペースの進捗と解放をブロックしているテーブルを処理するために、バキュームワーカーにさらにリソースを割り当てます。このプロセスでは、トランザクション ID がセーフゾーンに収まるまで、秒あたりのトランザクション総数が減少します（AdaptiveVacuumNewXidDelay を待機しているセッションとして確認できます）。トランザクション ID の経過時間が長くなると、バキュームワーカーは動的に増加します。
大きなテーブルに対する効率的なバキューム処理: テーブルのバキューム処理のタイミングを決定するために使用されるデフォルトの PostgreSQL ロジックは、pg_stat_all_tables に格納されているテーブル固有の統計情報に基づいています。これにはデッドタプルの比率が含まれています。このロジックは小さなテーブルでは有効ですが、大規模で頻繁に更新されるテーブルでは効率的に機能しない可能性があります。AlloyDB Omni では、自動バキュームをより頻繁にトリガーできる最新のスキャンメカニズムを提供しています。このスキャンメカニズムは、大きなテーブルのチャンクをスキャンし、デフォルトの PostgreSQL ロジックよりも効率的にデッドタプルを削除します。
警告メッセージをログに記録する: AlloyDB Omni では、長時間実行されているトランザクション、準備済みトランザクション、ターゲットを失ったレプリケーションスロットなどのバキュームのブロッカーが検出されると、PostgreSQL ログに警告が登録されます。これにより、問題にタイムリーに対応できます。

AI/ML ワーカー

AlloyDB Omni では、AI/ML バックグラウンドワーカーが、データベースから Vertex AI モデルを直接呼び出すために必要なすべての機能を提供します。AI/ML ワーカーは、omni ml worker というプロセスとして実行されます。

詳細については、AlloyDB AI を使用した生成 AI アプリケーションの構築をご覧ください。