概念

物理層

• Cluster (Clusters)
  • Nodeを構成管理する単位
• Node (Nodes)
  • Elasticsearchのサーバ
  • 複数のShardを配置可能
  • Nodeを増減させることでスケールイン/アウトができる
• Shard (Shards)
  • 論理層のIndexは実際には1つまたは複数のShardに分散されて配置される
  • PrimaryとReplicaがある
  • Primaryは後から変更不可能（再インデックスが必要）
  • Replicaは後からでも変更できる

論理層

• Index (Indices)
  • 最も大きなデータ管理単位
• Type (Types)
  • データ管理単位
• Document (Documents)
  • 他と同一性を区別可能なデータの集まり（DDDにおけるEntity）
• Field (Fields)
  • データの属性（DDDにおけるValue Object）

Index vs Type

• データ量や処理分散したいならIndexを分ける
• Parent-Childのデータ構造を適用するならIndexは分けない

関連データの取り扱い

Nested

通常、配列データはキーごとに個別に保持され、その組み合わせは考慮されない。

PUT /divisions/sales/1

{
    "name": "関東グループ",
    "members": [
        {
            "name: "alice",
            "email": "alice@example.com"
        },
        {
            "name: "bob",
            "email": "bob@example.com"
        }
    ]
}

（通常のmembers保存のイメージ）

そのため members.name = 'alice' AND members.email LIKE 'bob%' のような検索をすると、
どちらのデータも個々に存在するため /divisions/sales/1 が検索結果に含まれてしまう。

Nested型にすると組み合わせも考慮されるため、そのようなことが起こらなくなる。

（nested指定時のmembers保存のイメージ）

Parent-Child

Nestedに似たものにParent-Childがあるが、RDBに喩えると下記のテーブル・データ設計の違いに似ている。

Nested

divisionsテーブル

Parent-Child

divisionsテーブル

division_membersテーブル

Nested vs Parent-Child

どちらを使うかは悩ましいが、概ね下記の基準で選ぶと良い。

• 商品に対するカラーバリエーションなどのように少量かつ変更が少ないなら → Nested
• 独立性を犠牲にして検索高速性を重視するなら → Nested
• 商品に対する口コミなどのように独立性があり成長するデータなら → Parent-Child
• とにかく子データが多いなら → Parent-Child

他のデータ管理ソフトウェアとの住み分け

どれも一長一短のため、特徴に合わせて選択する必要があり、
また、要件によっては複数のプロダクトを組み合わせて実現することも珍しくない。