検索エンジンは『DBの限界』を超えるための専用ツール
Elasticsearch / OpenSearch は全文検索・ログ分析・ベクトル検索で広く採用される検索エンジンです。本記事では編集部の視点で、実務での組み込み方を公開情報をもとに整理します。ログ管理実践 もご参考に。
RDBMS との使い分け
(1) RDBMS：構造化データ・トランザクション・厳密な整合性。(2) 検索エンジン：全文検索・あいまい検索・集計・ランキング。(3) 併用が一般的：RDB が主、検索エンジンが副。(4) データ同期：CDC / アプリ側で二重書き。(5) 遅延整合性を許容：完全同期は別物。
マッピングの設計
(1) text と keyword の違い：text は解析、keyword は完全一致。(2) 多言語対応：日本語は kuromoji / mecab。(3) nested フィールド：配列の各要素を独立に扱う。(4) 動的マッピング無効化：本番では明示推奨。(5) シャード設計：将来のデータ量を見積もり。
クエリの基本
(1) match / term / range：基本クエリ。(2) bool で組合せ：must / should / must_not / filter。(3) aggregations：集計（GROUP BY 相当）。(4) highlight：マッチ箇所のハイライト。(5) sort と scoring：関連度 vs 並び順。
ベクトル検索の実装
(1) dense_vector フィールドでベクトル保存。(2) 埋め込みモデル：OpenAI/Cohere/オープンソース。(3) kNN クエリ：類似検索。(4) ハイブリッド検索：BM25 + ベクトルの組合せ。(5) 専用ベクトルDB との比較：Pinecone/Weaviate/Qdrant 等。AIエンジニア完全ロードマップ もご参考に。
運用面の注意点
(1) シャード数の設計：プライマリ+レプリカ。(2) クラスタの監視：ノード CPU/メモリ/JVM ヒープ。(3) インデックス管理：日次 rolling/月次 alias。(4) バックアップ：snapshot を S3 等へ。(5) マネージドサービス：Elastic Cloud / AWS OpenSearch Service。バックアップ&DR も合わせて。
失敗しがちなパターン
(1) シャード過多：性能劣化。(2) 動的マッピングで型崩れ。(3) 大きい text フィールドにkeyword 自動付与：メモリ消費。(4) 削除多用：disk 使用率増。(5) JVM ヒープ過大：32GB 超で逆効果。対策は、(1)シャード戦略の検証、(2)マッピング明示、(3)keyword 不要は ignore_above、(4)Lifecycle Policy、(5)JVM は <32GB、です。