elasticsearch

Elasticsearch — 分布式搜索与分析引擎

Elasticsearch 是基于 Apache Lucene 的分布式搜索和分析引擎，提供近实时的全文搜索、结构化搜索、聚合分析、地理空间查询和向量搜索能力。

Workflow — 从数据到搜索的 5 步决策流程

遇到 ES 相关需求时按以下顺序决策:

Step 1: 明确场景
├── 全文搜索?                    → Step 2
├── 结构化数据分析 (日志/指标)?   → Step 2
├── 向量/KNN 搜索?               → references/ 向量搜索
├── 地理空间查询?                 → references/ 地理查询
├── 集群运维/性能问题?             → references/ 07-cluster-ops
└── 数据管道/日志采集?             → references/ 08-elk-integration

Step 2: 设计索引 (Mapping + Analyzer)
├── 确定字段类型 (text/keyword/date/geo/nested…)
├── 选择分词器 (standard/ik/pinyin/自定义)
├── 规划主分片数 (每个分片 20-50GB), 建后不可改
└── 设置别名用于零停机重建

Step 3: 写入数据
├── Index API (单条), Bulk API (批量, 5-15MB/批)
├── _update (部分更新), _update_by_query (条件更新)
└── Logstash/Filebeat (日志采集管道)

Step 4: 构建查询
├── 全文搜索: match / multi_match / query_string
├── 精确过滤: term / terms / range / exists / bool filter
├── 复合查询: bool (must/should/filter/must_not)
├── 聚合分析: terms + avg → references/ 聚合专题
└── 排序/分页: sort / search_after (深度分页) / scroll (导出)

Step 5: 持续优化
├── 性能问题?  → Profile API + 慢查询日志
├── 数据增长?  → ILM + Rollover 自动化 (references/ 07-cluster-ops)
├── Mapping 变更? → Reindex + Alias 零停机 (examples/03)
└── 查询优化?  → filter 优先 query, 避免 script, 限制 _source

When to Use / When NOT to

✅ 使用 ES	❌ 不要用 ES
全文搜索 — 商品/文章/文档关键词搜索	复杂事务 — 需要 ACID/多表 JOIN, 选 PostgreSQL
日志/指标分析 — ELK Stack 日志场景	键值缓存 — 简单 KV 查询, 选 Redis
搜索型应用 — 电商/知识库/文档管理	强 Schema 约束 — 需要外键/触发器, 选 RDBMS
聚合/仪表盘 — 实时统计 + Kibana 可视化	海量文档存储无需搜索 — 选 MongoDB
地理空间查询 — 附近的人/POI/地理围栏	纯 OLAP 分析 — PB 级离线分析, 选 ClickHouse
向量搜索 — 语义相似度/RAG 检索	消息队列 — 选 Kafka/Pulsar

核心原则：Elasticsearch 是搜索服务器，不是关系型数据库的替代品。

Boundary — 能力边界

✅ 完全适用	⚠️ 有条件适用	❌ 不适用
全文搜索、模糊搜索、相关性排序	强一致性（ES 是近实时，默认 1s refresh）	代替关系型数据库做核心业务存储
日志/指标聚合分析 (Kibana)	秒级以下数据可见性（需调 refresh_interval）	复杂 JOIN 查询（ES 有有限 nested 支持）
地理空间、自动补全、搜索建议	极高写入量（需调优线程池和批量写入）	ACID 事务保证
文档搜索、知识库、RAG 检索	50+ 节点大集群（需专用协调节点）	存储二进制大文件（存 OSS 路径）
时序数据 + ILM 滚动	PB 级深度分页（需 search_after / PIT）	强关联约束数据模型
向量搜索 (dense_vector + KNN)	自定义分词器（需先测试分析效果）	替代 Kafka 做消息队列

核心概念速查

概念	ES 术语	关系型 DB 类比	关键说明	深度参考
Index	索引	Table	存储文档的逻辑命名空间，名称必须小写	references/05
Document	文档	Row	JSON 格式基本数据单元，不可变（update = delete+index）	—
Shard	分片	Partition	水平切分单元，主分片数建后不可改，推荐 20-50GB/分片	references/07
Replica	副本	Replica	冗余副本提供高可用和读扩展，可动态调整	references/07
Mapping	映射	Schema	定义字段类型和分词配置，已有字段类型不可修改	references/05
Analyzer	分词器	—	text 字段必须配置，决定搜索质量	references/06

查询 DSL 速查

查询类别	核心查询	用途	深度参考
全文查询	match / match_phrase / multi_match / query_string	文本分词搜索、短语匹配、多字段搜索	references/01
精确查询	term / terms / range / exists / ids	keyword 字段精确匹配、范围过滤、存在检查	references/02
复合查询	bool (must/filter/should/must_not)	90% 搜索需求可用 bool 实现	references/02
嵌套/父子	nested / has_child / has_parent	对象内跨字段关联、父子关系查询	references/02
地理查询	geo_distance / geo_bounding_box / geo_shape	附近查询、矩形区域、复杂地理形状	见 geospatial 技能
向量查询	knn 参数 / k-NN 插件	语义相似度、RAG 检索	references/05
特殊查询	fuzzy / wildcard / regexp / script / percolate	模糊纠错、通配符、脚本、反向搜索	references/02

聚合速查

聚合类型	核心聚合	类似 SQL	深度参考
指标聚合	avg / sum / min / max / stats / cardinality / percentiles	AVG / SUM / COUNT(DISTINCT) / PERCENTILE	references/03
桶聚合	terms / date_histogram / histogram / range / filters	GROUP BY / 日期分组 / 区间分组 / 过滤分组	references/04
管道聚合	derivative / moving_fn / bucket_script / bucket_selector	环比 / 移动平均 / 子聚合计算 / HAVING	references/04

集群运维概述

运维领域	关键要点	深度参考
节点类型	Master(3个专用) + Data(SSD) + Coordinating(大查询)	references/07
分片管理	分配/再平衡/reroute/延迟分配	references/07
快照备份	S3/FS/GCS 仓库, SLM 自动管理, 增量快照	references/07
ILM 生命周期	hot → warm → cold → frozen → delete 自动化	references/07
监控命令	_cluster/health, _cat/nodes, _cat/shards, hot_threads	references/07
安全	RBAC 角色, 字段/文档级安全, TLS, API Key	references/07

落とし穴 — よくある落とし穴とアンチパターン

#	落とし穴	問題	解決策
1	term クエリで text フィールドを検索	text はトークン分割されるため、完全一致する値が見つかりません	match または .keyword サブフィールドを使用します
2	from+size による深いページネーション	深くなるほど遅くなり、最終的に OOM が発生します（上限 10000）	深いページネーションには search_after、エクスポートには scroll/PIT を使用します
3	インデックス作成後にプライマリシャード数を変更	作成後は変更できません	事前に計画するか、インデックスを再作成します（reindex）
4	すべてのフィールドに text を使用	集計／ソートでエラーが発生します	text + keyword のマルチフィールドを使用します
5	動的マッピングに依存	タイムスタンプが long などとして認識されます	本番環境では mapping を明示的に設定します
6	ネストされたオブジェクトに通常のクエリを使用	フィールド間の関連条件が誤って一致します	必ず nested クエリを使用します
7	シャードが多すぎる、または少なすぎる	多すぎると管理のオーバーヘッドが大きく、少なすぎると拡張できません	シャードあたり 20-50GB にします
8	大量書き込みを最適化しない	頻繁な refresh により小さなセグメントが大量に生成されます	refresh を無効化（-1）し、Bulk API を使い、レプリカを 0 にします
9	filter キャッシュを無視	重複して計算され、パフォーマンスが低下します	スコア計算が不要な条件は filter に入れます
10	wildcard/regexp による前方一致検索	転置インデックスを利用できず、パフォーマンスが非常に低下します	prefix または edge_ngram を使用します
11	スクリプトクエリの乱用	キャッシュできず、パフォーマンスが低下し、デバッグも困難です	ingest pipeline で前処理します
12	クラスターロールを分離しない	Data の GC により Master が切断されます	専用の Master ノードを 3 台用意します
13	ログインデックスに ILM がない	インデックスが無制限に増加します	ILM でロールオーバー／圧縮／削除を自動化します
14	ignore_above を無視	keyword が長すぎるとインデックス作成に失敗します	ignore_above: 256 を設定します
15	text フィールドで fielddata を有効にする	メモリ消費が大きくなります	代わりに .keyword マルチフィールドを使用します

よくある質問

Q1: ES はリレーショナルデータベースの代替ですか？ いいえ。ES は検索サーバーであり、ACID トランザクション、外部キー、複雑な JOIN をサポートしていません。適切なアーキテクチャは、業務データを RDBMS に保存し、ES を検索と集計に使用することです。

Q2: データを書き込んでから検索可能になるまで、どのくらいかかりますか？ ほぼリアルタイムです。書き込みデータはまず buffer に入り、デフォルトでは 1s 後の refresh で検索可能になります。refresh_interval を調整するか、?refresh パラメーターを追加できます。

Q3: text フィールドと keyword フィールドの違いは何ですか？ text：トークン分割してインデックス化され、match 検索をサポートしますが、ソート／集計はサポートしません。keyword：値全体をインデックス化し、term 検索、ソート、集計をサポートします。

Q4: プライマリシャード数を変更できないのはなぜですか？ ルーティングルールが hash(_id) % shards であり、変更すると既存データの場所を特定できなくなるためです。変更するには reindex が必要です。

Q5: シャード数はどのように選べばよいですか？ シャードあたり 20-50GB にします。元データが 500GB の場合、プライマリシャードは 10-25 個です。ノードあたりのシャード数は、ヒープメモリ 1GB につき ≤25 個にします。

Q6: ES の検索が高速なのはなぜですか？ 転置インデックスにより、各語句がドキュメントのリストにマッピングされ、検索時に直接特定できます。さらに、シャードによる並列処理と filter キャッシュを利用します。

Q7: 集計（Aggregation）とは何ですか？ Bucket = GROUP BY によるグループ化、Metric = AVG/SUM/COUNT、Pipeline = 集計結果の再分析です。詳細は references/03、references/04 を参照してください。

Q8: Green/Yellow/Red の状態とは何ですか？ Green=すべて正常、Yellow=プライマリシャードは正常だがレプリカが未割り当て、Red=プライマリシャードが失われています。

Q9: ダウンタイムなしでインデックスを再作成するにはどうすればよいですか？ Alias + Reindex：新しいインデックスを作成 → データを Reindex → Alias をアトミックに切り替え → 古いインデックスを削除します。examples/03 を参照してください。

Q10: ES と Solr はどちらを選べばよいですか？ ES はクラスタ管理が組み込みで、1s でほぼリアルタイム検索ができ、強力な集計機能があり、ELK エコシステムも充実しています。Solr は ZK に依存し、設定が複雑です。

Q11: Mapping は変更できますか？ フィールドの追加はできますが、既存フィールドの型（text→keyword など）は変更できません。インデックスの再作成が必要です。

Q12: search_after と from+size の違いは何ですか？ from+size は深いページネーションで OOM が発生します（上限 10000）。search_after はソート値に基づいてページを進めるため、深さに関係なくパフォーマンスが一定です。

Q13: データはどのようにバックアップすればよいですか？ Snapshot API で S3/GCS/FS にバックアップします。SLM による自動管理を推奨します。増分スナップショットには変更分のみが保存されます。

Q14: クエリが遅い場合、どのように調査すればよいですか？ Profile API → スロークエリログ → filter vs query → segments 数 → GC ログ。

Q15: ILM でどのような問題を解決できますか？ ロールオーバー（サイズ／時間のしきい値）、自動移行（ホット→ウォーム→コールド）、自動圧縮、自動削除を実行できます。

キーワード

elasticsearch, ES, 検索エンジン, 全文検索, 転置インデックス, Lucene, index, mapping, document, shard, replica, analyzer, ik, pinyin, クエリ DSL, match, term, bool, filter, range, multi_match, query_string, nested, geo, aggregation, 集計, terms, date_histogram, avg, sum, cardinality, percentiles, pipeline, reindex, bulk, scroll, search_after, ILM, rollover, force_merge, alias, snapshot, cluster, ELK, Logstash, Kibana, Filebeat, KNN, dense_vector, ベクトル検索, painless, ingest pipeline, RBAC, profile API, スロークエリ, ダウンタイムなし

参考資料

• references/01-query-dsl-fulltext.md — 全文検索（match/multi_match/query_string）
• references/02-query-dsl-term.md — 完全一致検索と複合検索（term/range/bool）
• references/03-aggregations-metric.md — 指標集計（avg/sum/stats/cardinality/percentiles）
• references/04-aggregations-bucket.md — バケット集計（terms/date_histogram/range）
• references/05-mapping-types.md — マッピングとフィールド型の詳細
• references/06-analyzers.md — トークナイザー（標準/IK/pinyin/カスタム）
• references/07-cluster-ops.md — クラスター運用（シャード/監視/スナップショット/ILM）
• references/08-elk-integration.md — Logstash/Filebeat/Kibana の設定
• examples/01-fulltext-search.md — 全文検索の実践
• examples/02-aggregation-report.md — 集計レポートの実践
• examples/03-reindex-zero-downtime.md — ダウンタイムなしのインデックス再作成
• examples/04-cluster-monitoring.md — クラスター監視の実践