ご要望にお応えし、Spanner の生産性向上機能がさらに充実
Google Cloud Japan Team
※この投稿は米国時間 2020 年 12 月 23 日に、Google Cloud blog に投稿されたものの抄訳です。
2020 年は Cloud Spanner にとって飛躍の 1 年でした。ユーザー マネージドのバックアップと復元、ローカル エミュレータ、数多くのマルチリージョン構成をはじめ、より多くのエンタープライズ向け機能を導入しました。手動によるシャーディング、ダウンタイム、パッチ適用がなく、しかも 99.999% という業界トップクラスの SLA により、これまでよりもずっと簡単にアプリケーションを複数のリージョンでテストしてデプロイできるようになりました。
また、エンタープライズ向け機能だけでなく、デベロッパーの生産性向上にも引き続き注力しました。2020 年の初めには、外部キー、C++ クライアント ライブラリ、クエリ オプティマイザー、各種イントロスペクション機能をリリースしました。本投稿では、Spanner の新機能であるチェック制約、生成列、NUMERIC データ型についてご説明します。これらは、Spanner でアプリケーションを構築する際の生産性を高めるために導入した機能です。各機能の簡単な説明をお読みになり、チェック制約と生成列を組み合わせてアプリケーションの参照整合性を高める方法の例をご確認ください。
チェック制約
チェック制約では、1 つ以上の列の値がブール式を満たさなければならないことを指定できます。つまり、テーブルに述語（ブール式）を指定して、テーブル内のすべての行がそれらの述語を満たすことを要求します。たとえば、コンサートの終了時間は開始時間よりも遅くなければならないことを要求できます。
この例では、「start_before_end」制約によって、StartTime 列の値が EndTime 列の値よりも小さくなければならないことを要求しています。この要求が満たされない場合、行の挿入や更新は失敗します。チェック制約は外部キー、NOT NULL 制約、UNIQUE インデックスとともに、データベースに整合性制約を追加するメソッドとして機能します。
生成列
生成列は、同じ行内の他の列から値が計算される列です。これは、アプリケーション層に依存することなく、重要なデータロジックをデータベースに落とし込むうえで役立ちます。生成列によって、クエリの簡素化や、クエリ実行時に式を評価する費用の削減を実現できます。ほかの列型と同様に、インデックスを付けたり、外部キーとして使用することもできます。たとえば、姓のフィールドと名のフィールドを連結して新たな生成列を作成できます。
この例では、新しい行が挿入されるか、既存の行の「FirstName」または「LastName」が更新されると、「FullName」の値が計算されます。計算された値の保存方法やアクセス方法はテーブル内の他の列と同様ですが、単独で更新することはできません。
NUMERIC データ型
お客様からのご要望は機能導入の優先順位を決めるうえで重要な役割を果たしており、中でも NUMERIC データ型のサポートはよく寄せられるご要望の一つでした。NUMERIC データ型は精度が高く、金融、科学、エンジニアリングのアプリケーションなど、多くの業界や職種で役立ちます。たとえば、一般に 30 桁以上の精度が必要とされる場合に最適です。Spanner の NUMERIC データ型の精度は 38、スケールは 9 です。つまり全体で 38 桁、小数点以下（0 の桁より右側）が 9 桁の数字を保存できます。NUMERIC データ型で提供できるよりも高い精度の数値を Spanner データベースに保存する必要がある場合は、値を 10 進表記で STRING 列に保存することをおすすめします。
ユースケースの例で Spanner の新機能を使う
次に e コマースのアプリケーションを例にとり、チェック制約、生成列、基本的なインデックスがアプリケーションのパフォーマンスと信頼性の向上にどのように役立つかを見てみましょう。よくあるパターンとして、e コマースサイトでは大文字と小文字を区別しない商品検索機能が作成されます。ただし多くの場合、商品名は大文字と小文字を区別して保存され、大文字の使い方は商品によって大きく異なります。商品名検索のパフォーマンスを向上させるためには、商品名を大文字に変換する生成列を作成し、その列にインデックスを作成します。
商品テーブルのスキーマは次のようになります。
これで、表記を大文字に統一した商品名を保存する生成列が作成されました。この生成列は、テーブル内の他の列と同じように保存されます。また、次のようにインデックスを付けて、高速ルックアップを実現できます。
商品名を検索するには、最初に検索語句を大文字に変換します。作成したインデックスを使用するように Spanner に指示する必要もあります。
これで、リスト内での商品名の大文字の使われ方に関係なく、商品名の検索において高速かつ一貫した結果を得られるようになります。
e コマース企業では、商品価格用に独立したテーブルを用意している場合があります。いくつかの簡単なチェック制約を利用して、商品の価格が無効な状態にならないようにしたり、割引プログラムが重複しないようにしたりできます。たとえば、次の制約は商品の価格が負にならないことを確認します。
価格表には割引用の列が 2 つあります。1 つは特定の季節休暇中に適用される季節割引で、もう 1 つは新規顧客の登録時に適用される割引です。既存のテーブルに対するチェック制約をここで追加して、一度に 1 つの割引のみが有効になるようにすることができます。
チェック制約、生成列、NUMERIC データ型は、スキーマを定義して高性能なアプリケーションを作成するための新たなツールとして、多くのお客様から歓迎されるでしょう。
2020 年のリリースにより、Spanner をグローバルな整合性を備えたデータベースとして利用して、アプリケーションの構築、テスト、デプロイをより簡単に行えるようになることを願っています。皆様からのフィードバックをお待ちしております。2021 年も引き続きよろしくお願い申し上げます。
詳細
Spanner の利用を開始するには、インスタンスを作成するか、Spanner Qwiklabs でお試しください。
-プロダクト マネージャー Philip Simko
