9/5開催の『GCPUG Tokyo Spanner Day September 2018』に行ってきました。Blog枠での参加ということもあり、参加レポートを書いておきたいと思います。
Google Cloud Spanner Deep Dive (by sinmetal)
sinmetalさんによる、Spannerについてひと通りを紹介するセッションでした。資料は公開されています(↑)。
Cloud SpannerはGoogleが開発した分散型データベースです。KVSとして開発が始まったもので、RDBMSも合体したようなもの。ただしMySQLのノリで使うと性能が出せません。事例としてはPokemon Goや、タクシー配車アプリの「フルクル」など。バンダイナムコのゲームでも使用実績があるとのことです。
性能を出すためのチューニングのためには、とにかくデータが局所的に集まる(HotSpot問題)ことがないようにバラけさせるようにプライマリキーを設計させるのが重要という印象でした。UUIDをプライマリキーにするのが公式のベストプラクティス。UUIDならばアプリケーションの特性に左右されることもありません。特に何も考えたくなければUUID使っておけばよさげです。
インデックスの貼り方については注意が必要に感じました。インデックス自体も裏側ではテーブルとして保存されているため、タイムスタンプのカラムに貼るなど、インデックスの貼り方によってはインデックスのテーブルにHotSpot問題が起きてしまいます。
また、クエリを書く際には、クエリオプティマイザがあまり賢くないので自分でFORCE_INDEX指定をして無理やりインデックスを使わせないといけない場面が多そうなことも注意です。
Spannerの全体感が分かるとても貴重なお話が聞けたように思います。sinmetalさんに感謝です。
GCPUG Shared Spanner Release (by sinmetal)
引き続きsinmetalさんによるお話、というか宣伝。
Spannerは個人で使うには高くつくので、みんなで使えるインスタンスを立てた(Sponsored by メルペイ)のでどうぞ使って下さい、そしてみんなで知見を共有しましょう！というもの。本当にありがたいです！
使用にあたっては申請が必要です。詳しくは下記のページから。
自分も申請させてもらい、使えるようにしました。早速DB一個作成してみました。
色々試してみたいと思います。いや、本当にありがたい。
インターリーブ実践入門 (by matsumatsu20)
リクルートライフスタイルのmatsumatsu20さんによるインターリーブの説明および実際に性能比較してみた結果報告。
Spannerでは、親子関係のあるテーブルにおいて、親レコードに紐づく子レコードを同Splitに配置されるよう、テーブル作成時点でインターリーブ構成を定義することができます。同Splitに親子レコードを配置することで、親子レコードのデータを一緒に取得したい場合にパフォーマンスを高めることができます。
親子レコードをJOINで同時に取得するクエリで実際に検証してみたところ、インターリーブでテーブルを組んだ方が性能改善しているという結果が得られたとのことでした。
ただ、データの取得の仕方によっては性能劣化する場合もあるというのがポイントでした。例えば、子テーブルのデータのみを取得したい場合はSplitをまたぐので、性能劣化します。検証でも実際にパフォーマンスが低下したとの報告でした。
なんでもインターリーブすればよいというわけではなく、まとめのスライドにあるように、「ユースケースを把握し、適用を判断することが重要」ですね。
所感
勉強会を終えてのCloud Spannerの所感ですが「使いどころを見極めて正しく運用できれば」強力な武器になるという印象です。
普通のRDBMSと特性が異なる点を把握しておき、アプリケーションの仕様を考える時点から「これはSpannerで捌けるだろうか」と意識しておき、適切な設計をする必要があるかな、と感じました。まあ、それって他のDB使うときも意識してなきゃいけないことですけどね。
なにはともあれ、共用Spannerが提供されるのはとても嬉しいです。色々触ってみようと思います。