Bigtable でのデータ型の適用

Bigtable の柔軟なスキーマにより、文字列、日付、数値、JSON ドキュメント、画像、PDF など、あらゆる種類のデータを Bigtable テーブルに保存できます。

このドキュメントでは、Bigtable が型を適用し、アプリケーション コードでエンコードまたはデコードする必要がある場合について説明します。Bigtable のデータ型の一覧については、Data API リファレンス ドキュメントの型をご覧ください。

適用されるタイプ

次のデータに対してデータ型が適用されます。

  • 集計列ファミリー(カウンタ)
  • タイムスタンプ
  • 継続的マテリアライズド ビュー
  • 構造化された行キー

集約

集計データ型の場合、エンコードは集計タイプによって異なります。集計列ファミリーを作成する場合は、集計タイプを指定する必要があります。

次の表に、各集計タイプの入力タイプとエンコードを示します。

集計タイプ 入力タイプ エンコード
合計 Int64 BigEndianBytes
最小 Int64 BigEndianBytes
最大 Int64 BigEndianBytes
HLL バイト Zetasketch HLL++

SQL を使用して集計セルのデータをクエリすると、SQL は型情報を自動的に組み込みます。

Data API の ReadRows メソッドを使用して集計セルのデータを読み取ると、Bigtable はバイトを返します。そのため、アプリケーションは、Bigtable が型付きデータをバイトにマッピングするために使用したエンコードを使用して値をデコードする必要があります。

非集計データを含む列ファミリーを集計列ファミリーに変換することはできません。集計列ファミリー内の列には非集計セルを含めることはできず、標準列ファミリーには集計セルを含めることはできません。

集計列ファミリーを含むテーブルの作成の詳細については、テーブルの作成をご覧ください。エンコードされた値を使用して集計セルをインクリメントする方法を示すコードサンプルについては、値をインクリメントするをご覧ください。

タイムスタンプ

各 Bigtable セルには、Unix エポック(1970-01-01 00:00:00 UTC)からのマイクロ秒数を表す Int64 タイムスタンプがあります。

タイムスタンプの起点

Bigtable テーブルのすべてのタイムスタンプには、タイムスタンプの設定方法を示すオリジンがあります。Bigtable は、次のタイムスタンプの起点を認識します。

  • ユーザー指定: ユーザーまたはアプリケーションによって設定されたタイムスタンプ。
  • Bigtable で生成: クライアントのローカル システム クロックを使用するクライアント ライブラリによって設定されたタイムスタンプ、またはサーバーの現在時刻を使用するサーバーで生成されたタイムスタンプ。

タイムスタンプの粒度と精度

Bigtable は、次のレベルのタイムスタンプの粒度をサポートしています。

  • ミリ秒単位(デフォルト): タイムスタンプは、ミリ秒以下の精度のマイクロ秒値(3023483279876000 など)にする必要があります。Bigtable は、マイクロ秒精度のユーザー指定のタイムスタンプを拒否し、マイクロ秒精度の Bigtable 生成のタイムスタンプをミリ秒精度に切り捨てます。
  • マイクロ秒単位の粒度: タイムスタンプは、3023483279876543 などの完全なマイクロ秒単位の精度にできます。Bigtable は、ユーザー指定のタイムスタンプと Bigtable で生成されたタイムスタンプをマイクロ秒単位の精度で受け入れます。

タイムスタンプの粒度は、テーブルの作成時に設定します。

タイムスタンプの制限事項

マイクロ秒単位のタイムスタンプ粒度を持つテーブルには、次の制限が適用されます。

  • マイクロ秒単位のタイムスタンプの粒度をサポートしているのは、Java 用 Bigtable クライアント ライブラリ バージョン 2.82.0 以降のみです。別のクライアントを使用する読み取りリクエストまたは書き込みリクエストは失敗します。
  • マイクロ秒のタイムスタンプの粒度は、Enterprise Plus エディションのインスタンスでのみ使用できます。
  • テーブルの作成後に、テーブルのタイムスタンプの粒度を変更することはできません。
  • マイクロ秒単位の粒度のテーブルでは、継続的マテリアライズド ビューを作成できません。
  • マイクロ秒単位の粒度のテーブルでは、論理ビューを作成できません。
  • マイクロ秒単位の粒度を持つテーブルが含まれている場合、インスタンスを Enterprise Plus から Enterprise にダウングレードすることはできません。ダウングレードを開始する前に、これらのテーブルを削除する必要があります。
  • マイクロ秒単位の粒度を持つテーブルのバックアップは、Enterprise Plus インスタンスにのみ復元できます。

継続的マテリアライズド ビュー

継続的なマテリアライズド ビューは、SQL または ReadRows Data API 呼び出しを使用して読み取ることができる読み取り専用リソースです。マテリアライズド ビューのデータは、それを定義するクエリに基づいて型指定されます。概要については、継続的マテリアライズド ビューをご覧ください。

SQL を使用して継続的マテリアライズド ビューをクエリすると、SQL はタイプ情報を自動的に組み込みます。

Data API の ReadRows リクエストを使用して継続的マテリアライズド ビューから読み取る場合は、各列の型を把握し、アプリケーション コードでデコードする必要があります。

継続的なマテリアライズド ビューの集計値は、ビュー定義の列の出力タイプに基づいて、次の表に示すエンコードを使用して保存されます。

型 エンコード
BOOL 1 バイト値、1 = true、0 = false
BYTES エンコードなし
INT64(または INT、SMALLINT、INTEGER、BIGINT、TINYINT、BYTEINT) 64 ビット ビッグ エンディアン
FLOAT64 64 ビット IEEE 754(NaN と +/-inf を除く)
STRING UTF-8
TIME/TIMESTAMP Unix エポックからの経過マイクロ秒数を表す 64 ビット整数(GoogleSQL と整合)
詳細については、Data API リファレンスの エンコードをご覧ください。

構造化された行キー

構造化行キーを使用すると、リレーショナル データベースの複合キーと同様に、複数列キーを使用してデータにアクセスできます。

構造化された行キーのタイプとエンコードは、行キーのスキーマによって定義されます。このスキーマは、必要に応じて Bigtable テーブルに追加できます。構造化された行キーデータはバイトとして保存されますが、テーブルに対して SQL クエリを実行すると、Bigtable 用の GoogleSQL は、行キー スキーマで定義された型とエンコードを自動的に使用します。

行キーのスキーマを使用して ReadRows リクエストでテーブルをクエリすることはできません。継続的マテリアライズド ビューには、デフォルトで行キーのスキーマがあります。構造化行キーの詳細については、行キーのスキーマを管理するをご覧ください。

適用されないタイプ

型情報が指定されていない場合、Bigtable は各セルを不明なエンコードのバイトとして扱います。

型を適用せずに作成された列ファミリーをクエリする場合は、読み取り時に型情報を指定して、データが正しく読み取られるようにする必要があります。これは、動作がデータ型に依存するデータベース関数に関連しています。Bigtable 用 GoogleSQL には、クエリ時に型変換を行う CAST 関数が用意されています。これらの関数は、バイトからさまざまな関数が想定する型に変換します。

Bigtable では型が強制適用されませんが、特定のオペレーションではデータ型が想定されます。これを知っておくと、データベース内で処理できる方法でデータが書き込まれるようにできます。次に例を示します。

  • ReadModifyWriteRow を使用した増分では、セルに 64 ビット ビッグ エンディアン符号付き整数が含まれていると想定されます。
  • SQL の TO_VECTOR64 関数は、セルに 64 ビット浮動小数点数のビッグ エンディアン バイトを連結したバイト配列が含まれていることを想定しています。
  • SQL の TO_VECTOR32 関数は、32 ビット浮動小数点数のビッグエンディアン バイトを連結したバイト配列がセルに含まれていることを想定しています。

次のステップ