👻

Google Cloud Datastore Masakari Talk

2020/10/01に公開

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 などで複数のプロパティを使う場合は、その組み合わせの複合インデックスが必要になる。事前に必要となるインデックスを考えながら設計が必要。

無限のスケーラビリティと思いきや、1つのエンティティは1MB以下。

大きなデータは Google Cloud Storage に保存する必要がある。

強い整合性(Strong Consistency)のクエリが使える状況には制限があり、結果整合性(Eventual Consistency)のクエリを使う箇所が出てくる。

Strong Consistency が必要となる機能があるのであれば、パフォーマンスに注意しつつ Entity Group を設計する必要がある。

最大で 25 Entity Group までしか、トランザクションに参加できない。

これも要件によって Entity Group を設計する必要がある。ただ、Web系のユースケースではそこまで多くの Entity Group をトランザクションに参加させることは少ないと思われる。

新しいプロパティを追加しても、既存のエンティティは自動では更新されない。

実はスキーマレスなので、同じ Kind のエンティティが違うプロパティで保存されていても問題はない。プロパティの追加や変更をした時は、古いバージョンで保存したデータを読みだした時に問題が発生しないように実装する必要がある。

書き込みを停止してバックアップしないと、ちゃんとしたスナップショットにはならない。

あとはネームスペースを上手く使うと出来るかも？

SQL風のクエリがあるからといって、RDBのように使えると勘違いして設計すると死ぬ。

この記事はQiitaの記事をエクスポートしたものです