このドキュメントは、データベースとして Bigtable を使用する既存の Aerospike アプリケーションを移行するソフトウェア デベロッパーとデータベース管理者を対象としています。Aerospike の知識を使用して、Bigtable に移行する前に理解しておく必要のあるコンセプトについて説明します。
このドキュメントでは、Bigtable と Aerospike の使用を開始するために、次のことを行います。
- Aerospike と Bigtable の用語を比較します。
- Bigtable オペレーションの概要と、Bigtable 内のデータ レイアウトについて説明します。
- データ モデリングと主な設計上の考慮事項について説明します。
- レプリケーションの実現方法とその影響を明確にします。
移行プロセスと、移行の完了に使用できるオープンソース ツールについては、Aerospike から Bigtable への移行をご覧ください。
用語の比較
Aerospike と Bigtable はどちらも分散 NoSQL データベースですが、設計、運用、用語が大きく異なります。
Aerospike では、データはレコードに格納されます。各レコードには、1 つ以上の名前付きビンと、レコードサイズ（バイト単位）、有効期間（TTL）、最終更新時間（LUT）などのメタデータが含まれています。
Bigtable では、スケーラブルなテーブル（並べ替えられた Key-Value マップ）にデータが格納されます。テーブルは、行キーでインデックス付けされた行と、列修飾子で識別される列で構成されます。相互に関連する列は、列ファミリーを形成できます。この構造により、同じキーの下に値の複数のバージョンを保存できます。各バージョンは一意のタイムスタンプで識別されます。以前のバージョンは、読み取りオペレーション中にフィルタリングするか、構成されたポリシーに基づいてガベージ コレクションで削除できます。
詳細については、Bigtable ストレージ モデルをご覧ください。
次の表では、各プロダクトで使用されている共通のコンセプトと、対応する用語を取り上げて説明します。
| Aerospike | Bigtable |
|---|---|
| 直接対応する項目はありません。 | インスタンス: レプリケーションや接続ルーティングが相互間で発生するさまざまな Google Cloud ゾーンまたはリージョンのクラスタのマネージド グループ。 |
| クラスタ: ノードの集合で構成される Aerospike デプロイ。 | クラスタ: 同じ地理的 Google Cloud ゾーンにあるノードのグループ。 |
| ノード: コンピューティングを提供し、ストレージを所有するサーバー。 | node: コンピューティングのみを提供するサーバー。ストレージは、別の分散ファイル システムである Colossus によって処理されます。 |
| namespace: TTL やストレージ タイプなどのパラメータを保存します。名前空間内では、データはセットとレコードに細分化されます。 | table: Aerospike 名前空間に最も近い同等のもの。一部のパラメータは、クラスタレベルですべてのテーブルに設定されます。テーブルまたは列ファミリー レベルでより細かい制御が可能です。 |
| set: レコードと TTL や上限サイズなどのパラメータの論理分割に使用されます。キーはセット内で一意である必要があります。 | 直接対応する項目はありません。 |
| 直接対応する項目はありません。 | table: すべてのクラスタに自動的に複製されるインスタンス レベルのリソース。テーブルには、一意の行キーで識別される値のセットが含まれています。テーブルはスパースです。つまり、値を含まない列を保存するために追加のスペースを使用しません。 |
| 直接対応する項目はありません。 | tablet: 連続する行の範囲がまとめて保存されます。Bigtable は、タブレットをノードに割り当てることでロード バランシングを行います。タブレットの境界は動的で、時間の経過とともに分割または統合される可能性があります。 |
| レコード: データを保存するために使用される名前付きビンの一連のセット。最大 8 MB までです。 | 行: 列ファミリー、列修飾子、タイムスタンプで識別される値のセット。すべての操作は行レベルでアトミックに実行されます。 |
| 直接対応する項目はありません。 | 列ファミリー: 辞書順に並べ替えられた列のグループ。ガベージ コレクションはこのレベルで設定されます。 |
| bin: Key-Value ペア。ビン名はレコード内の値の識別子です。 | 列修飾子: テーブルに保存されている値のラベル。 |
| 直接対応する項目はありません。 | セル: テーブルに保存されているタイムスタンプ値のラベル。 |
| （レコード）ダイジェスト: レコード（名前空間、セット、キー）を識別する 3 タプルのハッシュ。 | 直接対応する項目はありません。 |
| key: セット内で一意のレコード識別子。 | 行キー: テーブル内で一意の行識別子。 |
| AQL:データを閲覧し、Aerospike データベースのユーザー定義関数を開発するためのコマンドライン ツール。 | GoogleSQL: Spanner、BigQuery、Bigtable などの複数の Google Cloud サービスで使用されるクエリ言語。 |
データ型の制限
次の表は、Aerospike と Bigtable で使用されるデータ型の制限を比較したものです。
| Aerospike | Bigtable |
|---|---|
| namespace: Enterprise Edition の Namespace の最大数は 32 です。 | table: インスタンスには最大 1,000 個のテーブルを含めることができます。テーブル名は 50 文字以内で指定してください。 |
| set: クラスタには最大 4,095 個のセットを設定できます。セット名は 63 バイト以内で指定してください。 | 直接対応する項目はありません。 |
| record: レコードの最大サイズは 8 MB です。 | row: 行の最大サイズは 256 MB です。 |
| 直接対応する項目はありません。 | 列ファミリー: 列ファミリーの数に制限はありませんが、100 個を超えるとパフォーマンスが低下する可能性があります。 |
| bin: ビンの数に制限はありませんが、各ビンに格納できるデータのサイズは 1 MB 以下です。ビン名は 15 バイト以内で指定してください。 | 列修飾子: 上限は 100 MB ですが、10 MB を超えないようにすることをおすすめします。列の数に制限はありません。 |
| key: キーの最大サイズは 8 KB です。 | 行キー: 行キーの最大サイズは 4 KB です。 |
Bigtable と Aerospike の上限の詳細については、それぞれ割り当てと上限と Aerospike のシステム上限としきい値をご覧ください。
アーキテクチャ
以降のセクションでは、Bigtable と Aerospike のアーキテクチャの概要について説明します。
Bigtable
Bigtable ノードはストレージ レイヤとは分離されているため、ノードはデータの耐久性に影響しません。Bigtable テーブル クライアントは、基盤となるデータ分布を認識しません。追加のルーティング レイヤが、リクエストを適切なノードに分散します。各ノードは、クラスタに対するリクエストの一部を処理します。Bigtable テーブルは、連続する行ブロック（タブレット）として共有され、高い耐久性を提供する分散ファイル システムである Colossus に保存されます。各タブレットは個々の Bigtable ノードに関連付けられます。
Bigtable のアーキテクチャには次のメリットがあります。
- Bigtable クライアントは、データの分散とロード バランシングを認識する必要はありません。このような複雑さは、ルーティング レイヤによって処理されます。
- ノード間で実際のデータがコピーされないため、再調整は非常に高速に行われ、障害からの復旧も迅速に行われます。
- Bigtable ノードで障害が発生してもデータが失われることはありません。
Aerospike
Bigtable とは異なり、Aerospike のストレージは、サービスを提供するノードにあります。Aerospike クラスタ内のすべてのノード（サーバー）は同一です。各名前空間のデータは、レコード名をハッシュ化することで、正確に 4,096 個のパーティションに分割されます。これらのパーティションはノード間で均等に分散されます。
ノードは互いに認識しており、クラスタが変更されると、保存されたパーティションの再調整を行います。クラスタの変更が発生するたびに、レプリカは再調整を調整するプライマリ レプリカを選出します。クライアント ライブラリは、どのレプリカがプライマリ パーティションを保存しているかを追跡し、書き込みリクエストを適切なレプリカに送信することが想定されています。クライアントが誤ったノードにリクエストを送信した場合（リバランス中に発生する可能性があります）、リクエストはノードによって再ルーティングされます。
レプリケーション
このセクションでは、Aerospike と Bigtable のレプリケーション プロセスを比較します。
Bigtable
Bigtable インスタンスは、単一のクラスタまたは複数のレプリケートされたクラスタで構成できます。テーブルは常にインスタンス内のすべてのクラスタに複製されます。クラスタは、他のクラスタへの影響を最小限に抑えながらインスタンスに追加または削除できます。
Bigtable は、単一クラスタ内で書き込み後読み取りの一貫性を提供します。書き込みは単一クラスタで実行され、最終的にインスタンス内の他のクラスタ間で整合性が保たれます。Aerospike とは異なり、Bigtable では個々のセルが内部的にバージョン管理されているため、中間更新が失われることはありません。各クラスタでは、利用可能な最新のタイムスタンプを持つセルが提供されます。
Bigtable API には、テーブルレベルの整合性トークンが用意されています。このトークンを使用すると、トークンが作成される前に行われたすべての変更が完全にレプリケートされたかどうかを確認できます。
Aerospike
Aerospike は、クラスタ内のレプリケーションをパーティション レベルで処理します。名前空間は、ノード間で均等に分散されるパーティションに分割されます。クラスタ内では強整合性が確保されます。書き込みオペレーションは、クラスタ内のすべてのレプリカが確認応答した後にのみ確認されます。
クロスデータセンター レプリケーション（XDR）は、異なるクラスタ間のデータ同期用に構成できます。Aerospike のビン コンバージェンスにより、レプリケーションの終了時にすべてのデータセンターでデータが最終的に同じになりますが、中間更新が失われる可能性があります。
耐久性のため、Aerospike の名簿ベースの整合性アルゴリズムでは、N 個の障害を処理するために N+1 個のコピーが必要です。
データモデル
このセクションでは、Bigtable と Aerospike で使用されるデータモデルを比較します。
柔軟なスキーマ
Aerospike はスキーマ制約を適用しないため、各レコードはさまざまな値型を持つ異なるビンを持つことができます。同様に、Bigtable はスパース列をサポートしているため、値のない列に対してストレージが消費されることはありません。列または列ファミリーの数に厳密な制限はありませんが、パフォーマンス上の理由から、列ファミリーの数を 100 未満に抑えることをおすすめします。
行キーの設計
Bigtable は、テーブル内で一意である行キーで行を識別します。これらは辞書順に並べ替えられ、タブレットにまとめられます。これは、ハッシュに基づいてレコードがノード間で分散される Aerospike とは異なります。行キーは、一緒にアクセスされる頻度の高い行が一緒に保存されるように設計する必要があります。
データ型
Aerospike は、スカラー、GeoJSON、HyperLogLog、リスト、ネストされたオブジェクトなどの高度なデータ型をサポートしています。これらの型は、セカンダリ インデックスのサポートにより、インデックス登録とクエリが可能です。また、Aerospike には、位置情報によるフィルタリングやリストの内容の操作など、これらのデータ型に対する複雑なオペレーションを可能にするサーバーサイド API が用意されています。
Bigtable API は、主に未加工のバイトの処理に重点を置いていますが、一部例外があります。また、タイムスタンプとカウンタに INT64 をネイティブで使用し、アトミック オペレーションとしてインクリメントできます。クエリ言語は、スカラー、JSON オブジェクト、HLL ビンなどの複雑な型もサポートしています。高度な型は今後ますますサポートされる可能性がありますが、このドキュメントの作成時点では、そのような型を Bigtable に配置する方法はありません。すべてがクライアント側でシリアル化されます。aerospike-migration-tools のアダプタ ライブラリを使用して、データ型をシリアル化できます。
列ファミリー
Bigtable では、テーブル内で一緒に保存および取得される列は、列ファミリーによって決まります。各テーブルには少なくとも 1 つの列ファミリーが必要です。関連する列は同じファミリーにグループ化する必要があります。ガベージ コレクション ポリシーは列ファミリー レベルで適用されるため、保持要件が異なるデータは個別の列ファミリーに分離する必要があります。
列修飾子
Bigtable では、列ファミリー内で列修飾子を使用して個々の列を定義します。テーブルは数百万の列をサポートできますが、ベスト プラクティスは、単一行の列数を制限することです。必要に応じて、列修飾子をデータとして扱うことができます。これにより、値を列名に直接埋め込んでスペースを節約できます。
セル
Bigtable では、セルは行キーと列名の交差（列ファミリーと列修飾子を組み合わせた部分）です。各セルには、クライアントによって提供されるか、サービスによって自動的に適用される、タイムスタンプ付きの 1 つ以上の値が含まれます。
セカンダリ インデックス
継続的マテリアライズド ビューは非同期セカンダリ インデックスとして機能し、テーブルをさまざまな検索パターンや属性を使用してクエリできます。詳細については、非同期セカンダリ インデックスを作成するをご覧ください。
トランザクション
Bigtable と Aerospike はどちらも複数行トランザクションをサポートしていませんが、単一行機能は異なります。Bigtable は、クラスタ内で完全に一貫した単一行の書き込みを提供し、mutate-row リクエストを通じて単一行トランザクションをサポートします。これらを使用すると、単一行に対して複数のオペレーションを実行できます。これらのオペレーションはすべてアトミックに実行され、すべて成功するか、すべて失敗します。また、読み取り - 変更 - 書き込みオペレーションと確認 - 変更オペレーションもありますが、これらはマルチクラスタ ルーティング プロファイルでは使用できません。これに対し、Aerospike は、サーバーサイドのデータ操作とクライアント定義関数の実行によって単一行トランザクションを拡張します。
ロード バランシングとフェイルオーバー
Aerospike は、スマート クライアントを使用してクライアント側のロード バランシングを処理します。クラスタの状態とデータ分散を認識するクライアントサイドで実行されるプロセス。このクライアントはリクエストのルーティングを担当します。
ノードに障害が発生した場合や新しいノードが追加された場合は、クラスタの再調整が必要です。一時的なプライマリが選択され、ノード間のパーティションの再調整と再分配が調整されます。この間、クラスタは動作し続けますが、クライアントはリクエストのルーティングの変更を追跡する必要があります。リクエストが間違ったノードに到達した場合は、正しいノードに内部的にルーティングされます。
Bigtable クライアントはシン クライアントであり、クラスタの状態やデータ分散などの複雑な処理をすべてユーザーから隠蔽します。リクエストのルーティングは、次のレイヤである Google CloudBigtable インフラストラクチャ内のシン クライアントによって処理されます。
もう 1 つの違いは、Aerospike では使用できないルーティング ポリシーです。Bigtable は、アプリケーション プロファイルを使用してリクエストのルーティングを管理します。リクエストの処理順序を制御する優先度を構成できます。ルーティング ポリシーには、単一クラスタとマルチクラスタの 2 種類があります。マルチクラスタ プロファイルは、オペレーションを、使用可能で最も近いクラスタに転送します。オペレーション ルーターの観点からは、同じリージョン内にあるクラスタは、等距離とみなされます。リクエストされたキー範囲を受け持つノードが過負荷になっている場合や、クラスタで一時的に利用できない場合、このプロファイルにより自動フェイルオーバーが行われます。一方、Aerospike はクラスタ全体で障害が発生した場合の自動フェイルオーバーを提供しません。
バックアップと復元
Aerospike には、asbackup と asrestore という外部バックアップ ツールと復元ツールが用意されています。これらのツールは、クライアント側で論理バックアップを作成し、スキャンを実行するのと同様の処理を行います。バックアップ管理は、Aerospike Backup Service または Aerospike Kubernetes Operator を使用して処理することもできます。どちらも内部で asbackup と asrestore を使用し、スケジューリングとマルチプロセス調整を行います。バックアップはアトミックではありません。つまり、バックアップ中に発生した書き込みオペレーションがキャプチャされない可能性があります。
Bigtable では、Bigtable バックアップとマネージド データ エクスポートという 2 つの一般的なバックアップ ニーズに対応しています。バックアップでは、クラスタのメンバー オブジェクトとして保存する、テーブルの復元可能なコピーが作成されます。バックアップは、バックアップを開始したクラスタ内の新しいテーブルとして復元できます。このバックアップは、アプリケーション レベルの破損が発生したときに復元ポイントを作成するように設計されています。Bigtable バックアップはアトミックではありません。バックアップでコピー済みのテーブルのセクションが変更されることがあります。
バックアップ処理の主な違い
- Aerospike バックアップはクライアントサイドで作成されます。サーバー側で追加のスペースは必要ありませんが、処理速度は遅くなります。Bigtable では、バックアップはソーステーブルとテーブルの他のバックアップと物理ストレージを共有します。
- Aerospike のユーザーは、古いバックアップのエクスポート、保存、削除を処理する必要があります。Bigtable のバックアップは完全に統合されているため、これらのアクションはすべて Bigtable サービスによって自動的に処理されます。
パフォーマンスに関する注意事項
Aerospike と Bigtable では読み取りオペレーションと書き込みオペレーションの処理方法が異なるため、パフォーマンスに違いが生じます。この違いを考慮することが重要です。次の表に、2 つのデータベース間のパフォーマンスの違いの例をいくつか示します。詳細については、Bigtable のパフォーマンス ガイドラインをご覧ください。
| 検討対象 | Bigtable | Aerospike |
|---|---|---|
| ホット行 | リソース使用量を均等にするために、タブレットとオペレーションを分散します。頻繁にアクセスされる行を 1 つのノードの 1 行タブレットに分離して、他の行への影響を制限できます。 | トラフィックに関係なく、ハッシュに基づいてすべてのノードに行を分散します。ホット行は、パーティション全体のパフォーマンスに影響を与える可能性があります。 |
| ソートされたキーに対するスキャン | データを辞書順で保存するため、ソートされたデータのストリーミングに非常に効果的です。 | ハッシュに基づいてレコードを分散するため、連続するキーを多数スキャンするには、複数のノードにクエリを実行して結果を集計する必要があります。このため、処理が遅くなる可能性があります。高度な型を含むセカンダリ インデックスをサポートします。これにより、スキャンの必要性が軽減される可能性があります。 |
| 多数の連続するキーの挿入 | データを辞書順に保存します。つまり、1 つのノードが連続する多くのキー書き込みオペレーションを処理します。その結果、読み取り / 書き込みパターンが、行キー空間の末尾を担当するタブレットを保持するノードに集中し、効果的にオーバーロードされる可能性があります。 | ハッシュに基づいてキーを分散し、連続するキーを書き込むときに複数のノード間で負荷を分散します。 |
| 列数が非常に多い行 | Bigtable は最大 256 MB の行をサポートできますが、大きな行を処理するとパフォーマンスに影響する可能性があります。Bigtable は小さい行に最適化されています。そのため、スキーマ設計では、不要な場合にデータが多くのセルに分散しないように、セルの編成とデータへのアクセスを考慮する必要があります。 | 列またはビンの数が非常に多い行またはレコードに遭遇すると、パフォーマンスが最適ではなくなります。 |
| コールド スタート | 頻繁にアクセスされる大きなテーブルで優れたパフォーマンスを発揮します。使用していない期間（コールド スタート）の後にリクエストの送信を開始すると、レイテンシが高くなる可能性があります。これは、タブレットへの分割とノード間の分散が最適でないことと、キャッシュがコールドであるためです。コールド スタート時と再調整時には、数分間ノード間の分散が完全に最適化されないことがあります。 | データ分布は負荷ベースではないため、パフォーマンスは時間の経過とともに変化しません。キャッシュのウォームアップが必要ですが、インデックスはメモリに保持されるため、ディスク検索時間が最小限に抑えられ、キャッシュの重要性が低下します。 |
| 多くの小さなテーブル | 小さなテーブルを多数作成しないでください。別のテーブルは、異なるユースケースやスキーマでは正当化されますが、類似したデータでは正当化されません。ロード バランシングが改善されず、管理オーバーヘッドが増加するためです。 | ほとんどのレコードは 1 つの Namespace に存在し、セットにグループ化されます。セットには特定のスキーマはありませんが、セカンダリ インデックスまたはスキャン オペレーションはセットごとに設定できます。データをセットに分割しても、パフォーマンスには影響しません。 |
| 大規模なデータセット | エクサバイト規模のデータセットを保存できます。アーキテクチャと動的タブレット分割により、パフォーマンスはデータセットの合計サイズの影響を受けません。 | 技術的には、Aerospike データベースにサイズ制限はありませんが、Aerospike はインデックスとレコードを別々に保存します。両方の種類のデータを さまざまな種類のストレージ デバイスに保存して、パフォーマンスを向上させることができます。低レイテンシを実現するには、インデックスを RAM に保存することが不可欠ですが、非常に大きなデータセットでは実現できない可能性があります。たとえば、40 億個のオブジェクトとレプリケーション係数 2（RF2）の場合、All Flash のクラスタ全体でプライマリ インデックスに関連して使用されるメモリは 2.5 GiB です。ハイブリッド メモリ構成で同じ例を使用すると、プライマリ インデックスがメモリ内にあるため、476.8 GiB のメモリが使用されます。 |
| スケーリング | 処理とストレージが分離され、個別にスケーリングできます。1 つのノードで、数百テラバイト、あるいは数ペタバイトのデータチャンクを処理できます。 | 低レイテンシを実現するには、インデックスを RAM に保存することが不可欠です。このような場合、プライマリ インデックスを考慮して、マシンをストレージ容量とともに垂直方向にスケーリングする必要があります。 |
次のステップ
- Bigtable のスキーマ設計について確認する。
- Aerospike の詳細を確認する。
- Bigtable エミュレータについて確認する。
- Google Cloud に関するリファレンス アーキテクチャ、図、ベスト プラクティスを確認する。Cloud アーキテクチャ センターをご覧ください。