tblsがデータソースとしてCloud Spannerに対応した

GCP Go

約1,000円の資金を投じて作りました。

Cloud Spannerのスキーマをtblsで出力するとどのようになるのか

例えば、 https://github.com/k1LoW/tbls/blob/master/testdata/spanner.sql のSQLで作成したデータベーススキーマから以下のようなドキュメントが生成されます。

https://github.com/k1LoW/tbls/tree/master/sample/spanner

使い方

tblsの他のRDBMSと使い方は変わりません。Cloud SpannerのDSNは

spanner://[ProjectID]/[InstanceID]/[databaseID]

となっています。ADCの設定がされていて（ gcloud auth application-default login していて）、データベースへのアクセス権限があれば、もう tbls doc でのドキュメント生成が可能なはずです。

サービスアカウントのクレデンシャルファイルがあれば、?creds=[GOOGLE_APPLICATION_CREDENTIALS] をDSNに付与する形での対応も可能です。

$ tbls doc spanner://[ProjectID]/[InstanceID]/[databaseID]?creds=spanner_client_secrets.json

Cloud Spannerの運用にtblsを利用すると何が嬉しいのか

「Cloud SpannerはGCP上にスキーマ情報を確認できるWebUIがあるので特にいらない」となるかと思います。

ただ、以下の点でCloud Spannerの運用にtblsを使うメリットがあると考えています。

1. .tbls.yml を使ってテーブルコメント/カラムコメントをドキュメントにでき、CIを回せる

.tbls.yml によるコメントの付与は、MySQLやPostgreSQLといったRDBMSにおいては「 ALTER TABLE する必要なく、コメント運用ができる」というメリットをうたっていましたが、Cloud Spannerにはそもそもテーブルコメント/カラムコメントというものがないようです。

tblsであれば、 .tbls.yml の comments ディレクティブで各テーブル各カラムコメントを付与して、さらに tbls lint を使ってCIを回せばコメントの追加漏れがなくなる*1、など、スキーマの長期運用においてメリットがあると考えています。

2. .tbls.yml で設計上テーブル間をINTERLEAVEにしない判断をしたが、実は存在するテーブル間の関係をドキュメントにでき、CIを回せる

tblsではINTERLEAVEで親子関係になっているテーブルについて、リレーションがあると判断してその情報をドキュメントに追加します。

INTERLEAVEについては以下のドキュメントをご覧ください。

cloud.google.com

一方で、何かしらの理由でINTERLEAVEで親子関係にはしていないものの、論理的にはテーブル間に関係があるということはあります。

tblsはそれらについても .tbls.yml の relations ディレクティブでテーブル間の関係をドキュメントに追加できます。そして tbls lint を使ったチェックが可能です*2。

これもMySQLやPostgreSQLといったRDBMSにおいては「外部キー制約がないがテーブル間の関係があるということをドキュメント化できる」というようにメリットをうたっていたのですが、Cloud SpannerのINTERLEAVEの特性をみると外部キー制約よりも積極的にインターリーブ しない という選択がありそうなので、「制約はないけど実は関係がある」というような情報を付与するのにtblsはメリットがありそうです。

というわけで

Amazon Redshiftに続き、Cloud Spannerもちゃんとプロダクションで使ったことがないので是非フィードバックが欲しいと考えています。

既にCloud Spannerをガンガン使っている皆さま、是非使ってみてください。

*1:コメントがないカラムやテーブルに対してチェックができる requireTableComment や requireColumnComment があります

*2:リレーションのないテーブルをチェックできる unrelatedTable があります