Datastore Masakari Talks で Google Cloud Datastore について話をしてきました。
その時のスライドの内容に多少の補足をいれつつ、ここにまとめておきます。
なお、Masakari Talk ということで弱点や注意点だけを取り上げてていますが、Google Cloud Datastore はスケーラブルな分散データストアでありつつ、単純な KVS にとどまらずクエリで検索できるし、 ACID トランザクションもあるしで、とても優秀なデータストアです。
SQLっぽいけど、SQLではない
JOIN, GROUP BY, OR, 集計関数(MAX, MIN) などが無い。
基本的にインデックスを使って最小限にスキャンして、必要なエンティティを取ってくるデータベース。BigQueryと違ってフルスキャンではないので、集計やORなど出来ない。
クエリにはインデックス必須
インデックス数の上限もある。
クエリの WHERE や ORDER BY などで複数のプロパティを使う場合は、その組み合わせの複合インデックスが必要になる。事前に必要となるインデックスを考えながら設計が必要。
エンティティ1MB制限
無限のスケーラビリティと思いきや、1つのエンティティは1MB以下。
大きなデータは Google Cloud Storage に保存する必要がある。
結果整合性
強い整合性(Strong Consistency)のクエリが使える状況には制限があり、結果整合性(Eventual Consistency)のクエリを使う箇所が出てくる。
Strong Consistency が必要となる機能があるのであれば、パフォーマンスに注意しつつ Entity Group を設計する必要がある。
トランザクションに制限がある
最大で 25 Entity Group までしか、トランザクションに参加できない。
これも要件によって Entity Group を設計する必要がある。ただ、Web系のユースケースではそこまで多くの Entity Group をトランザクションに参加させることは少ないと思われる。
マイグレーションが面倒
新しいプロパティを追加しても、既存のエンティティは自動では更新されない。
実はスキーマレスなので、同じ Kind のエンティティが違うプロパティで保存されていても問題はない。プロパティの追加や変更をした時は、古いバージョンで保存したデータを読みだした時に問題が発生しないように実装する必要がある。
スナップショットが難しい
書き込みを停止してバックアップしないと、ちゃんとしたスナップショットにはならない。
あとはネームスペースを上手く使うと出来るかも？
まとめ
SQL風のクエリがあるからといって、RDBのように使えると勘違いして設計すると死ぬ。