ガベージ コレクションの概要
このページでは、Bigtable のガベージ コレクションの仕組みについて説明します。取り上げる事項は次のとおりです。
- ガベージ コレクションの種類
- デフォルトのガベージ コレクション設定
- データが削除されるとき
- レプリケートされたテーブルのガベージ コレクション ポリシーの変更
ガベージ コレクションの概要
ガベージ コレクションは、期限切れデータや古くなったデータを Bigtable テーブルから自動的かつ継続的に削除するプロセスです。1 つのガベージ コレクション ポリシーは、特定の列ファミリー内のデータが不要になるタイミングを規定するユーザー作成の複数のルールからなります。
ガベージ コレクションは、組み込みの非同期バックグラウンド プロセスです。ガベージ コレクションの対象のデータが実際に削除されるまでには、最長で 1 週間かかることがあります。ガベージ コレクションは、削除が必要なデータ量によって変わることのない、固定スケジュールで発生します。データが削除されるまで、読み取り結果に表示されます。このデータは、読み取りをフィルタリングすることで除外できます。
ガベージ コレクション ポリシーの利点は次のとおりです。
- 行サイズを最小化する - 行サイズは、無限に大きくならないように注意する必要があります。大きな行はパフォーマンスに悪影響を及ぼします。理想的な行サイズは 100 MB 以下で、上限は 256 MB です。古いデータや現在のデータの古いバージョンを保存する必要がない場合、ガベージ コレクションを使用すると、各行サイズを最小限に抑えられます。
- 費用を低く抑える - ガベージ コレクションを使用すると、不要になったデータや使用しなくなったデータの保存にかかる費用を節約できます。コンパクションが発生し、ガベージ コレクションの対象となるデータが削除されるまで、期限切れのデータや古くなったデータの保存には課金されます。通常このプロセスには数日かかりますが、最長で 1 週間かかることがあります。
ガベージ コレクション ポリシーは、プログラムによって設定することも、cbt CLI を使って設定することもできます。ガベージ コレクション ポリシーは列ファミリー レベルで設定されます。
テーブルの各列ファミリーには、独自のガベージ コレクション ポリシーがあります。ガベージ コレクション プロセスは、現在のガベージ コレクション ポリシーを列ファミリーごとに検索してから、そのポリシーのルールに従ってデータを削除します。
タイムスタンプ
Bigtable では、行と列の交点に複数のセルを含めることができます。これらのセルには、その交点の値のタイムスタンプをしたバージョンが含まれます。各セルにはタイムスタンプがあります。タイムスタンプは、Unix エポックからの経過時間 1970-01-01 00:00:00 UTC（マイクロ秒単位）です。デフォルトのタイムスタンプを使用する、または書き込みリクエストを送信する際に設定できます。
Bigtable に送信するタイムスタンプは、ミリ秒以下の精度を持つマイクロ秒の値にする必要があります。マイクロ秒精度のタイムスタンプ（3023483279876543 など）は拒否されます。この例では、指定できるタイムスタンプ値は 3023483279876000 です。
セルのタイムスタンプ プロパティは、セルの値が書き込まれた実際の時間を反映する「実際の」タイムスタンプにする、または「人為的な」タイムスタンプにすることができます。人為的なタイムスタンプには、セルが実際に書き込まれた時刻ではない、連続番号、ゼロ、タイムスタンプ形式の値があります。人為的なタイムスタンプを使用する前に、使用することに伴うリスクを含めて、使用例をご確認ください。
書き込みリクエストを送信する場合は、必ずタイムスタンプを設定してください。ただし、人為的なタイムスタンプを含むユースケースをサポートする場合は除きます。
ガベージ コレクションの種類
このセクションでは、Bigtable で利用可能なガベージ コレクションの種類について説明します。それぞれの種類のガベージ コレクションのコードサンプルについては、ガベージ コレクションの構成をご覧ください。
期限切れ値（エージベース）
ガベージ コレクション ルールを、各セルのタイムスタンプに基づいて設定できます。たとえば、現在の日時から 31 日以上前のタイムスタンプを持つセルを保持する必要がないとします。この種のガベージ コレクション ルールでは、データの有効期間（TTL）を設定します。Bigtable は、ガベージ コレクションの際に各列ファミリーを調べ、期限切れになったセルを削除します。
バージョン数
列ファミリーのすべての列について、保持する最大セル数を明示的に指定するガベージ コレクション ルールを設定できます。
たとえば、お客様の最新のユーザー名とメールアドレスのみを保持する場合は、これら 2 つの列を含む列ファミリーを作成し、その列ファミリーの値の最大数を 1 に設定できます。
また、パスワードを再利用しないように、ユーザーのパスワード ハッシュのバージョンを最新から 5 つ保持する場合、パスワード列を含む列ファミリーの最大バージョン数を 5 に設定します。Bigtable がガベージ コレクションの際に列ファミリーを調べる時点で、パスワード列に 6 つ目のセルが書き込まれている場合、最も古いセルが削除され、バージョン数は 5 に保たれます。
期限切れルールとバージョン数ルールの組み合わせ
ガベージ コレクションには、有効期限とバージョン番号のルールを組み合わせて使用できます。組み合わせのタイプは、インターセクション、ユニオン、ネストです。構成例については、複数の基準に基づくガベージ コレクションをご覧ください。
インターセクション
インターセクション ガベージ コレクション ポリシーは、所定のルールセットの条件をすべて満たした場合に、削除対象データをマークします。たとえば、31 日以上経過したプロファイルを削除しても、ユーザーごとに最低 1 つのプロファイルは残す必要があるとします。この場合、プロファイル列を含む列ファミリーのインターセクション ポリシーは、期限切れ値ルールとバージョン数ルールの両方で構成されます。
Union
ユニオン ガベージ コレクション ポリシーは、所定のルール内のいずれかのアイテムに一致する場合、データを削除対象とマークします。たとえば、30 日未満しか経過していないページビュー レコードのみをユーザーごとに最大 2 つまで保持する必要があるとします。この場合、ユニオン ポリシーは期限切れ値またはバージョン数のいずれかに対して設定されます。
ネスト
ネストされたガベージ コレクション ポリシーは、ユニオンルールとインターセクション ルールの組み合わせです。
ガベージ コレクションのデフォルト設定
列ファミリーにデフォルトの TTL はありません。以降のセクションで説明するように、1 つの列に対して保持されるセル数は、その列が属する列ファミリーの作成方法によって異なります。
HBase ポリシー
Java 用 HBase クライアント、HBase シェル、または Java 用 HBase クライアントを使用する別のツールを使用して列ファミリーを作成した場合、ルールを変更しない限り、Bigtable は列ファミリーの各列の最新のセルのみを保持します。このデフォルトの設定は HBase と一致しています。
他のすべてのクライアント ライブラリまたはツール
他のクライアント ライブラリやツールを使用して列ファミリーを作成した場合、Bigtable は列ファミリーの各列に無限数のセルを保持します。これには、gcloud と cbt CLI で作成された列ファミリーが含まれます。バージョン数を制限する場合は、列ファミリーのガベージ コレクション ポリシーを変更する必要があります。
データが削除されるとき
ガベージ コレクションは、Bigtable が継続的に各列ファミリーのルールをチェックし、それに応じて期限切れのデータや古くなったデータを削除するプロセスです。一般に、データがルール内の基準に一致してから実際に削除されるまで、最長で 1 週間かかることがあります。ガベージ コレクションのタイミングを変更することはできません。
期限切れのデータが削除されるまでに最長で 1 週間かかることがあるため、ガベージ コレクション ポリシーのみでは、読み取りリクエストで必要なデータが返されない場合があります。必ず、ガベージ コレクション ルールと同じ値を除外するフィルタを読み取りリクエストに適用してください。1 列あたりのセル数を制限するか、タイムスタンプの範囲を指定することでフィルタできます。
たとえば、列ファミリーのガベージ コレクション ルールで最も新しい 5 つのプロファイル バージョンのみを保持し、5 つのバージョンがすでに格納されているとします。新しいバージョンのプロファイルが書き込まれると、最も古いセルが削除されるまでに最長で 1 週間かかることがあります。したがって、6 つ目の値を読み取らないようにするには、常に最も新しい 5 つのバージョンを除くすべてを除外する必要があります。
コンパクションが発生し、データが削除されるまで、期限切れデータのストレージに対しても料金が発生します。
ガベージ コレクションは遡及的です。新しいガベージ コレクション ポリシーが設定されると、その後数日間でテーブル内のすべてのデータに適用されます。新しいポリシーが以前のポリシーよりも制限が厳しい場合、バックグラウンド作業が発生したときに古いデータが削除されます。ポリシー変更前に書き込まれたデータも対象になります。
ガベージ コレクションとしてマークされているデータが確実に削除されるようにするには、テーブルに対してクエリを実行し、そのデータと想定結果と比較します。Google Cloud Console でテーブルをモニタリングすることもできます。テーブルがまったく小さくならない場合は、ガベージ コレクション ポリシーが期待どおりに機能していないことが考えられますが、ガベージ コレクションは遅れて実行されることに注意が必要です。
レプリケーションとガベージ コレクション
レプリケーションは、いくつかの点でガベージ コレクションに影響を与える可能性があります。
バージョン ベースのガベージ コレクションと CPU 使用率
レプリケーションを使用しているインスタンスでは、アプリケーション リクエストを複製する場合と同じ方法で、インスタンス内のすべてのクラスタにバージョン ベースのガベージ コレクションからの削除が複製されます。古いセルを削除対象としてマークする新しいセルを作成してすぐに Bigtable が古いセルを削除し、その削除をインスタンス内の他のクラスタに複製すると、CPU 使用率が増加する場合があります。バージョンベースのガベージ コレクションを使用するテーブルを含むインスタンスにクラスタを追加する場合は、この CPU 使用率の増加に備えてください。
一方、経過時間ベースのガベージ コレクションの場合、レプリケートされたインスタンスで CPU 使用率が増加することはありません。
バージョン ベースのガベージ コレクション ポリシーの変更
レプリケートされたテーブルの列ファミリーの最大バージョン数は、変更できます。ただし、列ファミリーのバージョン数を減らすと、その数がすべてのレプリケートされたクラスタで反映されるまでに、最長で 1 週間かかることがあります。したがって、データを読み取るときは常にフィルタを使用する必要があります。
経過時間に基づくガベージ コレクション ポリシーの変更
インスタンスがレプリケーションを使用するかどうかにかかわらず、ガベージ コレクション ポリシーで指定された保持時間を増減できます。経過時間に基づくガベージ コレクション ポリシーを削除することもできます。
保持期間の短縮
年齢ベースのポリシーの保持時間を短縮すると、すべてのクラスタが同期して新しいポリシーを使用するまでに最長で 1 週間かかることがあります。
保持期間の延長
複製されたテーブルでは、ガベージ コレクション ポリシーの保持時間を最大 90 日間延長できます。
列ファミリーの保持期間を延長する場合は、クラスタが 1 週間以上同期されていない可能性があることに注意してください。その理由を理解するために、2 つのクラスタ インスタンスにテーブルがあり、列ファミリーの保持期間を 30 日から 50 日に変更する場合について考えてみましょう。
- 行キー
ip#685の書き込みリクエストが、列ファミリーprofileの列click-throughの値が2023-01-02であるクラスタ A に送信されます。データはクラスタ B にレプリケートされます。 - 31 日後、クラスタ A でガベージ コレクションが行われ、
click-through列の値は期限切れとして認識され、削除されます。 - 列ファミリー
profileのガベージ コレクション ポリシーを変更して、TTL を 30 日から 50 日に増やします。 - 1 日後、ガベージ コレクションがクラスタ B で実行されます。TTL は 50 日であるため、値
2023-01-02は保持されます。 - クラスタは同期されていない状態になり、クラスタ B に存在するがクラスタ A には存在しない値が最終的に削除されるまでの約 20 日間はそのままです。
次のステップ
- セルレベルの TTL をシミュレートする方法を探る。
- 連番のタイムスタンプがガベージ コレクションに与える影響について読む。
- ストレージ料金の詳細を確認する。
- 目的のプログラミング言語でのガベージ コレクションのコードサンプルを見る。