この記事の途中に、以下の記事の引用を含んでいます。
Elasticsearch Was Never a Database
もはや当たり前!? 「Elasticsearch＝データベース」神話の誤解
近年、Elasticsearchを“データベース”のように扱う開発例をよく見かけるようになりました。
しかし、今回ご紹介するJames Blackwood-Sewell氏の記事「Elasticsearch Was Never a Database」は、その設計思想・技術的背景・運用面まで深く掘り下げたうえで、“Elasticsearchをシステム・オブ・レコード（信頼できる唯一のデータ保存先）にしてはいけない”という警鐘を鳴らしています。
Elasticsearchを安易に“本番DB”や唯一のデータストアとして使うことは、将来的に大きな落とし穴につながる。
この記事では、原文の主張を丁寧に解説しつつ、その意義や現場で陥りやすい「あるある」な罠、今後のアーキテクチャ選びへの示唆までを論じていきます。
記事は何を主張しているのか？──“データベース”の意味とElasticsearchの本質を明かす
まず筆者は、Elasticsearchが本来「検索API」であり「システム・オブ・レコード」＝DBとして設計されていない、と明言しています。引用しましょう：
Elasticsearch was never a database. It was built as a search engine API over Apache Lucene (an incredibly powerful full-text search library), but not as a system of record. […] Over the last decade, many teams have tried to stretch the search engine into being their primary database, usually with unexpected results.
つまり、Elasticsearchの本質はLuceneの検索能力をAPIで扱いやすくした「全文検索エンジン」です。
MySQLやPostgreSQLのような「正規のDB」とは責任範囲も本来の期待値も全く異なります。
にもかかわらず、現場では「もともとRDBの検索が遅いからElasticsearchをIndexとして導入」「やがてデータを本体DBではなくElasticsearchだけに入れ始める」という構図がよく見られる、と記事は指摘しています。
期待のギャップが生む“脆弱さ”──DBと検索エンジンの決定的な違い
ブラックウッド＝スウェル氏は、Elasticsearchと「本来のDB」の違いを具体的に列挙しています。
たとえば、
– RDBはトランザクションで一貫性を保証する（Atomicity, Consistency, Isolation, Durability…つまりACID保証）
– 一方のElasticsearchは、複数ドキュメントをまたぐトランザクションが存在しない（＝部分的な更新のみが成功する状況が生まれる）
– スキーマ変更時は、RDBはALTER TABLE一発。Elasticsearchはインデックスの再作成＋全データ同期が必要
– JOINやリッチな問い合わせが必要な場面でElasticsearchは“苦しい”
さらに、こうした違いは可用性・信頼性の面でも明確です。
The difference between an index and a database is how they recover. Databases use write-ahead or redo logs to guarantee that once a transaction is committed, all of its changes are durable and will replay cleanly after a crash. […] But, as we saw with transactions, that durability doesn’t extend beyond a single document.
つまり、RDBが「一部でも失敗したら元に戻す」仕組みを持つのに対し、Elasticsearchはあくまでも“個々のドキュメント”という粒度でしか信頼性を担保していません。大規模障害発生時には、意図せず部分的なデータ不整合が恒久的に残りうるのです。
サービス現場で起きている「Elasticsearch無理筋運用」あるある
実際の開発・運用現場では、Elasticsearchを誤用したことでどんな問題が起きているのでしょうか。
特に「検索からエンジン、やがて“唯一のストレージ”へ」は、失敗しやすい典型パターンです。
1) データ同期のコストと脆弱性
多くの現場は、まずRDBとElasticsearchの「二重管理」に苦しみ始めます（同期バッチ、Kafka/ChangeDataCapture、トラブル時のリカバリなど）。
最初は面倒、でも少なくともRDB側が最終的なMasterなのでリカバリ不能にはなりにくい。
しかし、「完全なリアルタイム同期は難しいから…」→「いっそElasticsearchだけを唯一のデータストアにしよう！」という“短絡的最適化”に走ると、二重構造の脆弱性よりもさらに恐ろしいリスクが爆誕します。
2) “部分コミット、壊れた一貫性、消えた保証”
例えばECサイトの注文〜在庫管理の例では
– 注文情報（order）と在庫（stock）を同時に更新したい
– RDBのトランザクションなら「両方成功or両方失敗」が守られる
– Elasticsearchだと「注文だけ書き込めたが在庫減らしは失敗」など“部分完了”が普通に起きうる
これを後からリトライやバッチで「なかったこと」にしようにも、構成が複雑化し、データ不一致はじわじわ蓄積します。
3) “ALTER TABLE”が「全データコピー」という地獄
運用が長期化するとスキーマ変更（ex: int→float, フィールド追加やリネーム）が必ず発生。
RDBなら超簡単ですが、Elasticsearchだと
– 新しいインデックス作成
– 既存データを全コピー
– 古いの削除
という「重い・危険・コストが高い」手順が必要となることが記事でも指摘されています。
4) JOIN不可/困難による実装爆発
「集計や関連データの取得もElasticsearchで…」と望んだ瞬間、JOINの不在・制約が開発効率を著しく阻害。SQLで一発のことも、アプリケーション側で複雑なロジックを強いられるという“コストの転嫁”が地味に効いてきます。
Elasticsearch「だけ」運用の本当のコストとは──複雑性と運用リスクの爆発
記事では“Elasticsearchを唯一ストレージにすることで総運用コストや複雑さが悪化する”と述べています。
実際にもエンジニアの負担や事故発生時のリスクはRDBベースより高く、「システム・オブ・レコード候補としてElasticsearchしかなかった時代」に比べ、今は他の選択肢が続々登場しています。
一方でElastic社自身も「Elasticsearchを唯一のデータ保存先にしないように」という趣旨のガイダンスを公式に出し続けており、本記事の主張と軸は完全に一致します。
もちろん、Elasticsearchの特徴である「スケーラビリティ」「全文検索性能」「高いインデキシング性能」は他のエンジンに比類ないものです。
しかし、それは「高速サーチのための二次的なインデックス」としてこそ最大限発揮される、という点が極めて重要です。
“正しい用途”でこそ活きる技術──今選ぶべきアーキテクチャと代替案
さて、Elasticsearchの“正しい役割”とは何でしょうか。
記事曰く：
Elasticsearch (and Apache Lucene under it) is an incredible achievement, bringing world-class search to developers everywhere. As long as you’re not trying to use it as a system of record, it does exactly what it was built for.
つまり、「全文検索インデックス」と割り切って使い、ビジネスデータの正本はRDBに持つのが安全な選択です。
加えて、市場には「OLTP＋全文検索」を一台で両立する新しい選択肢（記事ではParadeDB等）が少しずつ成熟し始めています。
たとえば「PostgreSQL上に全文検索機能を持たせ、変更データをETLなしでリアルタイムにクエリできる」など、従来の二重化運用・同期処理の辛さを抜本的に減らす設計思想のサービスも登場してきました。
これは現代のシステム設計において“テキスト検索はサーチエンジンで、トランザクションはRDBで”という旧来的な分業体制を柔軟に再考する契機となりえるでしょう。
まとめ：適材適所の選択がシステム全体の信頼性を守る
結局のところ、本記事の最大のメッセージは
「Elasticsearchを“データベース”として期待するな」
「検索エンジンとDBの違いを理解し、適切な技術選定を」
という一点に尽きると考えます。
トランザクション、一貫性、耐障害性、柔軟なクエリ、そして事故時のリカバリ能力。
ビジネスクリティカルなデータには、これらを本質的に満たしたシステムを“唯一のデータストア”に選ぶべきです。
Elasticsearchの高速検索に“主体”を任せたくなる心情は理解できますが、運用現場の事故は必ず起き、“人類の大半は失敗から学ぶしかない”というのも事実です。
本当に「安心して任せられるデータ保存先」を探すなら、クセの強い検索エンジンを無理に万能化しようとするより、“設計思想に合致した技術を適材適所で組み合わせる”という、極めて当たり前のIT設計原則に立ち返るべきタイミングなのかもしれません。
categories:[technology]
コメント