[解決済み] データベースではなく、データストアで考えるには？

質問

例として、Google App Engineはデータの保存に標準的なデータベースではなく、Google Datastoreを使用しています。 データベースの代わりにGoogle Datastoreを使用するためのヒントがある方はいらっしゃいますか？ 私は、テーブル構造に直接対応するオブジェクトの関係で100％考えるように訓練されたようで、今では別のものを見るのは難しいです。 Google Datastoreの利点（パフォーマンスやデータの分散など）は理解できるのですが、データベースの優れた機能（結合など）が犠牲になっているのです。

Google DatastoreやBigTableを使ったことがある方で、何か良いアドバイスがあれば教えてください。

どのように解決するのですか？

従来の」リレーショナル データベースと比較した場合、App Engine のデータストアに慣れる必要があるのは主に 2 点です。

• データストアは、挿入と更新を区別しません。あるエンティティに対して put() を呼び出すと、そのエンティティは一意のキーとともにデータストアに保存され、そのキーを持つものはすべて上書きされます。基本的に、データストアの各エンティティの種類は、巨大なマップやソートされたリストのように動作します。
• ご指摘の通り、クエリーはかなり制限されます。まず、結合ができません。

この2つの違いの背景には、Bigtableが基本的に巨大な順序付き辞書のように動作していることがあります。従って、put操作は与えられたキーの値を設定するだけで、そのキーに以前どのような値があったかは関係ありませんし、fetch操作は単一のキーか連続した範囲のキーの取得に限定されます。インデックスとは、基本的にそれ自体がテーブルであり、より複雑な問い合わせを連続した範囲に対するスキャンとして実装することができるものである。

ここまで理解すれば、データストアの機能と制限を理解するのに必要な基礎知識は身についたことになります。これまで恣意的と思われた制限も、おそらくはより理にかなっているはずです。

ここで重要なのは、これらはリレーショナル・データベースでできることの制限ですが、同じ制限があるからこそ、Bigtableが扱うべき規模にスケールアップすることが現実的であるということです。紙面上ではよくても、SQLデータベースでは極端に遅くなるようなクエリを実行することはできないのです。

データの表現方法をどう変えるかという点で、最も重要なのは事前計算です。クエリ時に結合を行うのではなく、可能な限りデータを事前計算してデータストアに格納します。ランダムなレコードを選びたければ、乱数を生成して各レコードと一緒に保存します。この種のヒントやトリックをまとめたクックブックがあります。 こちら .