tkzwhr's notes

tkzwhrの技術、中国語などのメモです。

Elasticsearchメモ

全文検索エンジンのElasticsearchについてわかったことを簡単にメモする。

概念

物理層

  • 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保存のイメージ)

name
alice
bob
email
alice@example.com
bob@example.com

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

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

(nested指定時のmembers保存のイメージ)

name email
alice alice@example.com
bob bob@example.com

Parent-Child

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

Nested

divisionsテーブル

id type name members_json
1 sales 関東グループ [{"name":"alice","email":"alice@example.com"},{"name":"bob","email":"bob@example.com"}]
Parent-Child

divisionsテーブル

id type name
1 sales 関東グループ

division_membersテーブル

id division_id member_json
1 1 {"name":"alice","email":"alice@example.com"}
2 1 {"name":"bob","email":"bob@example.com"}

Nested vs Parent-Child

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

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

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

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

種別 主なプロダクト 得意 苦手
関係データベース Oracle DB、MySQL 一貫性のある永続化、システムスケーリング 大量データの保持、複雑な検索
キーバリューストア DynamoDB、Cassandra 高速なデータ更新、シンプルなデータ管理 高度な検索
ドキュメント指向 Firestore、Elasticsearch 大量データの保持、データ分析 関連性の保持

参考文献