スキーマの設計

Bigtable テーブルに最適なスキーマは、ユースケース、データアクセスパターン、保存するデータなど、複数の要素によって大きく異なります。このページでは、Bigtable のスキーマ設計プロセスの概要について説明します。

このページを読む前に、スキーマ設計のコンセプトとベストプラクティスを理解する必要があります。必要に応じて、時系列データ用のスキーマ設計もご覧ください。

始める前に

スキーマのテストに使用できる Bigtable インスタンスを作成または特定します。

Bigtable への保存を予定しているデータを特定する。次の点などを確認してください。
- どのようなデータ形式を使用しますか？使用可能な形式には、RAW バイト、文字列、protobuf、json などがあります。
- データ内のエンティティの構成要素はどのようなものですか？たとえば、ページビュー、株価、広告のプレースメント、デバイス測定、その他の種類のエンティティを保存しますか？エンティティの構成要素はどのようなものですか？
- データは時間ベースですか？
必要なデータの取得に使用するクエリを特定してランク付けする。保存するエンティティについて、データを使用するときに、どのように並べ替えとグループ化するかを検討してください。スキーマ設計はすべてのクエリを満たすわけではありませんが、最も重要なクエリや最も頻繁に使用するクエリに最適です。クエリの例には次のようなものがあります。
- IoT オブジェクトの 1 か月間の温度測定値。
- IP アドレスの 1 日の広告ビュー。
- モバイルデバイスの最新の場所。
- ユーザーごとの 1 日あたりのすべてのアプリケーションイベント

初期スキーマ設計を決定します。つまり、行キーが従うパターン、テーブルに設定する列ファミリー、および列ファミリー内の列に必要な列修飾子を指定する必要があります。一般的なスキーマ設計ガイドラインに従います。データが時間ベースの場合は、時系列データに関するガイドラインにも従ってください。

スキーマに使用した列ファミリーと列修飾子を使用してテーブルを作成します。
下書き計画で特定した行キーを使用して、少なくとも 30 GB のテストデータでテーブルを読み込みます。ノードあたりのストレージ使用率の上限を超えないように設定します。
高負荷のテストを数分間実行します。この手順により、Bigtable は、モニタリングされたアクセスパターンに基づいてノード間でデータを分散できるようになります。
テーブルに通常送信する読み取りと書き込みについて 1 時間のシミュレーションを実行します。
Key Visualizer と Cloud Monitoring を使用してシミュレーションの結果を確認します。
- Bigtable 用 Key Visualizer ツールは、クラスタ内の各テーブルをスキャンし、その使用パターンを表示します。Key Visualizer は、スキーマ設計と使用パターンによって、特定の行のホットスポットなど、望ましくない結果を引き起こしているかどうかを確認するうえで有用です。
- Monitoring を使用すると、クラスタ内で最もホットなノードの CPU 使用率などの指標を確認することで、スキーマ設計が原因で問題が発生しているかどうかを判断できます。

Key Visualizer で確認した内容に基づいて、必要に応じてスキーマ設計を変更します。
- ホットスポット化発生の証拠を確認する場合は、別の行キーを使用します。
- レイテンシが見受けられる場合は、行が 1 行あたりの上限である 100 MB を超えているかどうかを確認します。
- 必要なデータを取得するためにフィルタを使用することが必要であると判断した場合は、行キーごとに 1 行または行の範囲を読み取ることにより、読み込みをよりシンプルかつ高速に行えるようにデータを正規化することを検討してください。
スキーマを変更したら、もう一度テストして結果を確認します。
Key Visualizer で検査して、スキーマ設計が最適であることが示されるまで、スキーマ設計の変更とテストの実施を続けます。