仕組み
- Kinds
- Entities
- Properties
- Entities
Full Indexing
- Built-in: 各プロパティー、各エンティティ
- Composite: 複数のプロパティで構成される複合インデクス
注意：自動的に複数のプロパティ値を持つエンティティを書き込むと、インデックス爆発が発生するので手動的にインデックスを設定
特徴
- Keysで検索すると早い
- 実行時間の依存はデータセットのサイズではなくりリターンデータのサイズ（データセットは10行数と10億行数でも5行数結果ならば実行時間は同じ）
- 事実上あらゆるサイズにスケーリングと効率が高い
【干し草の山の針】こんなアプリケーションタイプにこれを考える (needle in a haystack)
欠点
- Updateが遅い
- JOINできない
Cases
データ対象
- Document database
- Hierarchical（XML, HTML）
- NoSQL
- Key-value 構造
データ対象外
- OLTP (Online Transaction Processing)：トランザクション処理用（RDBMSを考え）
- OLAP (Online Analytical Processing)：データ分析処理用（BigQueryを考え）
- Non-HierarchicalとUn-Structuredデータ（BigTableを考え）
- immutable blobs（Cloud Storageを考え）
- カラムキーは書き込み、書き直しのが多い
比較
vs. 伝統的なRDBMS
| 項目 | RDBMS | DataStore |
|---|---|---|
| トランザクション | 自動的 | 同じ |
| インデックスを使うクエリ | 有り | 全て |
| 実行時間の依存 | データセットのサイズと結果データのサイズ | 結果データのサイズのみ |
| データ構造 | リレーションデータ | 階層型データ（XML、HTML） |
| オブジェクトのカテゴリ | 種類（Kinds）の異なるエンティティ（HTML tags） | テーブル |
| オブジェクト単体 | 行（Rows） | エンティティ（Entities） |
| オブジェクトの個々のデータ | 列（Cols） | プロパティー（Properties） |
| 単体 | 各Row、同じプロパティー | 各Entity、異なれるプロパティー |
| 個々 | 各Col、同じタイプ | 同じプロパティー名で異なれるタイプ |
| クエリ | JOINが多い、サーブクエリにフィルターあり、複数の不等式フィルターができ | JOINがない、サーブクエリにフィルターなし、－つ 不等式フィルターのみ |
関連記事
All about indexes of datastore
Using App Engine APIs with Datastore
ま～ また続きますね！！！