Spannerの階層型ストレージを解説

記事タイトルとURLをコピーする

G-gen の佐々木です。当記事では Spanner の階層型ストレージ(tiered storage)機能について解説します。

Spanner とは

Spanner は、強整合性を保証する RDB(リレーショナルデータベース)の特徴と、グローバルに水平スケーリングできる NoSQL データベースの特徴を併せ持つ、フルマネージドな RDB サービスです。

Spanner の詳細については、以下の記事も参照してください。

blog.g-gen.co.jp

階層型ストレージについて

概要

Spanner に保存されるデータは、デフォルトでは SSD(solid state drive)に保存され、高スループット、低レイテンシのデータアクセスが可能となっています。

階層型ストレージ機能を用いると、データのアクセス頻度などに応じて、データの保存先として SSD もしくは安価なストレージである HDD(hard disk drive)を利用できるようになります。いずれの保存先を利用していても、データアクセスの方法やバックアップに影響はありません。

データ保存先のストレージタイプは、以下のレベルで設定することができます。たとえばクエリで取得する頻度の低い列に対して HDD を使用するように設定することで、データ保存のコストを節約することができます。

  • データベース
  • テーブル
  • セカンダリインデックス

階層型ストレージは Spanner Enterprise エディションおよび Enterprise Plus エディションで使用できる機能です。

エディション 階層型ストレージの使用可否
Standard ×
Enterprise
Enterprise Plus

また、当機能は Google 標準 SQL 言語データベースと PostgreSQL 言語データベースの両方でサポートされています。

ストレージの選択

階層型ストレージを利用すると、データを最初から SSD もしくは HDD に保存されるように設定できるほか、最初は SSD に保存しておき、一定期間経過後に HDD に移動することもできます。これは古いデータがあまりアクセスされないようなユースケースにおいてコスト節約に役立ちます。

選択できるストレージタイプには以下のような違いがあります。基本的には SSD の利用が推奨されています。

SSD HDD
特徴 秒間クエリ数(QPS)が多く、ほとんどのユースケースでパフォーマンスが高い。
費用対効果が高い。
ストレージの費用が安い。
ユースケース 書き込み、読み取りに高スループット、低レイテンシが要求されるデータセット レイテンシの影響を受けにくい大規模データセット、またはアクセス頻度が低いデータセット
単一リージョン構成時の予想スループット(ノードあたり) 読み取り:最大 22,500 QPS
書き込み:最大 3,500 QPS
読み取り:最大 1,500 QPS
書き込み:最大 3,500 QPS
デュアルリージョン・マルチリージョン構成時の予想スループット(ノードあたり) リージョンあたり
読み取り:最大 15,000 QPS
書き込み:最大 2,700 QPS
リージョンあたり
読み取り:最大 1,000 QPS
書き込み:最大 2,700 QPS
サポートされるオペレーション 読み取り、書き込み、更新、削除 読み取り、書き込み、更新、削除
1GBあたりの料金(東京リージョンの場合) $0.00053/hour $0.00011/hour

ローカリティグループ

階層型ストレージを利用するには、利用するストレージタイプを指定したローカリティグループ(Locality groups)を作成し、それをテーブルや列に紐付ける必要があります。ローカリティグループは、Spanner ストレージ内でテーブルや列のデータの分離を行うための機能で、同じローカリティグループのデータは物理的に近くに配置されます。

ユーザーがローカリティグループを作成していないデフォルトの状態では、すべてのデータが default ローカリティグループに含まれ、SSD に保存されます。

階層型ストレージを使用する方法

ローカリティグループの作成

階層型ストレージを利用するには、まず使用するストレージを指定したローカリティグループを作成する必要があります。ローカリティグループは CREATE LOCALITY GROUP DDL ステートメントを使用して作成することができます。

SSD のみを使用するローカリティグループ

SSD ストレージのみにデータを保存するローカリティグループは以下のように作成します。default ローカリティグループ同様、このローカリティグループを紐付けたテーブルや列などのデータは SSD に保存されます。

# Google 標準 SQL の場合
CREATE LOCALITY GROUP <グループ名> OPTIONS (storage='ssd');
# PostgreSQL 互換の場合
CREATE LOCALITY GROUP <グループ名> STORAGE 'ssd';

HDD のみを使用するローカリティグループ

HDD ストレージのみにデータを保存するローカリティグループは以下のように作成します。このローカリティグループを紐付けたテーブルや列などのデータは HDD に保存されます。

# Google 標準 SQL の場合
CREATE LOCALITY GROUP <グループ名> OPTIONS (storage='hdd');
# PostgreSQL 互換の場合
CREATE LOCALITY GROUP <グループ名> STORAGE 'hdd';

時間経過でデータを HDD に移動するローカリティグループ

以下のステートメントでは、最初の10日間はデータを SSD に保存し、その後 HDD に移動するローカリティグループを作成します。

# Google 標準 SQL の場合
CREATE LOCALITY GROUP <グループ名>
OPTIONS (storage = 'ssd', ssd_to_hdd_spill_timespan = '10d');
# PostgreSQL 互換の場合
CREATE LOCALITY GROUP <グループ名>
STORAGE 'ssd' SSD_TO_HDD_SPILL_TIMESPAN '10d';

HDD に移動するまでの時間は最小で1時間(1h)、最大で365日(265d)となっています。

通常は、指定した時間から7日間の間に行われるデータの圧縮サイクル内でストレージの移行が行われるため、指定した時間が経過してもすぐに移行が行われるわけではありません。

既存のローカリティグループの設定を変更する場合

ALTER LOCALITY GROUP DDL ステートメントを使用することで、ローカリティグループの設定を変更することができます。

たとえば、以下のステートメントでは、指定したローカリティグループで使用するストレージを HDD に変更します。

# Google 標準 SQL の場合
ALTER LOCALITY GROUP <グループ名> SET OPTIONS (storage='hdd');
# PostgreSQL 互換の場合
ALTER LOCALITY GROUP <グループ名> STORAGE 'hdd';

ローカリティグループの紐付け

CREATE TABLE または ALTER TABLE DDL を使用して、作成したローカリティグループをテーブルや列に紐付けることで、階層型ストレージを利用できるようにします。

データベースレベルの設定

デフォルトでは default ローカリティグループがデータベース全体に適用されており、データベース内のすべてのデータが SSD に保存されるようになっています。データベースレベルで階層型ストレージの設定をする場合、この default ローカリティグループを ALTER LOCALITY GROUP で変更します。

default ローカリティグループを指定する場合、Google 標準 SQL の場合は `default`、PostgreSQL 互換の場合は "default" のように文字列を囲む必要があります。

# Google 標準 SQL の場合
ALTER LOCALITY GROUP `default` SET OPTIONS (storage = 'ssd', ssd_to_hdd_spill_timespan = '10d');
# PostgreSQL 互換の場合
ALTER LOCALITY GROUP "default" STORAGE 'ssd' SSD_TO_HDD_SPILL_TIMESPAN '10d';

上記のステートメントにより、データベース内のすべてのデータにおいて、最初の10日間はデータを SSD に保存し、その後 HDD に移動する設定が適用されます。

テーブルレベルの設定

CREATE TABLE ステートメントでテーブルを作成する際に、テーブル全体に対してローカリティグループを設定できます。以下の例では、Singers テーブル全体にローカリティグループを設定しています。

# Google 標準 SQL の場合
CREATE TABLE Singers (
SingerId INT64 NOT NULL,
FirstName STRING(1024),
LastName STRING(1024),
SingerInfo BYTES(MAX)
) PRIMARY KEY (SingerId), OPTIONS (locality_group = '<グループ名>');
# PostgreSQL 互換の場合
CREATE TABLE Singers (
SingerId bigint PRIMARY KEY,
FirstName varchar(1024),
LastName varchar(1024),
SingerInfo bytea
) LOCALITY GROUP <グループ名>;

テーブルレベルのローカリティグループを変更する場合、ALTER TABLE ステートメントを使用します。

# Google 標準 SQL の場合
ALTER TABLE Singers SET OPTIONS (locality_group = '<グループ名>');
# PostgreSQL 互換の場合
ALTER TABLE Singers SET LOCALITY GROUP <グループ名>;

列レベルの設定

列レベルでは、CREATE TABLE ステートメント内で列に対して個別にローカリティグループを指定します。以下の例では、Singers テーブル全体に加え、 Awards 列に別のローカリティグループを設定しています。

# Google 標準 SQL の場合
CREATE TABLE Singers (
SingerId INT64 NOT NULL,
FirstName STRING(1024),
LastName STRING(1024),
Awards ARRAY<STRING(MAX)> OPTIONS (locality_group = '<列レベルのグループ名>')
) PRIMARY KEY (SingerId), OPTIONS (locality_group = '<テーブルレベルのグループ名>');
# PostgreSQL 互換の場合
CREATE TABLE Singers (
SingerId bigint PRIMARY KEY,
FirstName varchar(1024),
LastName varchar(1024),
Awards varchar[] LOCALITY GROUP <列レベルのグループ名>
) LOCALITY GROUP <テーブルレベルのグループ名>;

列レベルのローカリティグループを変更する場合、ALTER TABLEALTER COLUMN を使用します。

# Google 標準 SQL の場合
ALTER TABLE Singers
ALTER COLUMN LastName SET OPTIONS(locality_group = '<グループ名>');
# PostgreSQL 互換の場合
ALTER TABLE Singers
ALTER COLUMN LastName SET LOCALITY GROUP <グループ名>;

セカンダリインデックスレベルの設定

セカンダリインデックスレベルでは、CREATE INDEX ステートメント内でセカンダリインデックスに対して個別にローカリティグループを指定します。以下の例では、SingersByFirstLastName というセカンダリインデックスにローカリティグループを設定しています。

# Google 標準 SQL の場合
CREATE INDEX SingersByFirstLastName ON Singers(FirstName, LastName)
OPTIONS (locality_group = '<グループ名>');
# PostgreSQL 互換の場合
CREATE INDEX SingersByFirstLastName ON Singers(FirstName, LastName)
LOCALITY GROUP <グループ名>;

セカンダリインデックスレベルのローカリティグループを変更する場合、ALTER INDEX を使用します。

# Google 標準 SQL の場合
ALTER INDEX SingersByFirstLastName SET OPTIONS(locality_group = '<グループ名>');
# PostgreSQL 互換の場合
ALTER INDEX SingersByFirstLastName SET LOCALITY GROUP <グループ名>;

佐々木 駿太 (記事一覧)

G-gen最北端、北海道在住のクラウドソリューション部エンジニア

2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2025 Fellowに選出。好きなGoogle CloudプロダクトはCloud Run。

趣味はコーヒー、小説(SF、ミステリ)、カラオケなど。