Elasticsearchはデータを永続的に保存できます。主要データベースにするかは、書き込みが失敗したり並行したりしても、どの業務ルールを守る必要があるかから判断します。
注文システムでは、商品を探すことと購入を確定することは別の仕事です。前者には検索の関連性、後者には支払いと在庫変更の正しさが重要です。
購入に注文レコードの作成と在庫の減算が必要だとします。片方だけが成功した場合にどうするかを、業務として定義しなければなりません。
[Create order] ---- must coordinate ---- [Reduce stock]
| |
success failure?
ElasticsearchのBulk APIは複数のドキュメント操作をまとめて送りますが、ある項目が成功して別の項目が失敗することがあります。全操作が成功するか、すべて取り消すかというトランザクションにはなりません。アプリケーションは個々の結果を確認する必要があります。Bulk API。
複数レコードを原子的に変更する要件なら、トランザクション対応データベースのほうが通常は直接的な土台になります。この調整を自作すると、失敗のパターンと復旧作業が増えます。
楽観的並行制御は、読み取ったバージョン以降にドキュメントが変更されていないか確認します。古い状態に基づく更新を拒否し、あるクライアントが別のクライアントの処理を知らずに上書きすることを防げます。並行制御。
保護の対象は更新するドキュメントです。在庫と注文のドキュメントを自動で連携させたり、リレーショナルな外部キーを提供したり、任意の業務フィールドにまたがる一意性を保証したりするものではありません。
保存先を選ぶ前に、アプリケーションが必要とするルールを書き出します。「検索エンジン」「データベース」という名前ではなく、具体的な条件で判断できます。
書き込みの成功と検索結果への反映は別の出来事です。
[Write accepted] -> [Refresh] -> [Search can see the change]
リフレッシュによって最近の変更が検索に見えるようになります。そのため、ドキュメントIDによるリアルタイム取得と検索クエリは異なります。refresh=wait_forは検索で見えるまで待てますが、複数ドキュメントのトランザクションを作るわけではありません。リフレッシュの動作。
商品検索画面なら、短い反映遅延を許容できるかもしれません。最終的な支払いや権限の判断では、必要な整合性を明確にし、それを提供する情報源を読みます。また、リフレッシュとデータの永続性も別の問題です。
| 要件 | 検討する方向 | 理由 |
|---|---|---|
| 注文と関連レコードを原子的に変更する | トランザクション対応の主要データベース | 正しさのルールは正本のレコードの近くで守る必要がある。 |
| 柔軟な全文検索が必要 | 検索用コピーとしてElasticsearchを使う | 検索データを独立して整形、再構築できる。 |
| 独立したドキュメントで整合性要件も適合する | Elasticsearchを主要ストアにできる場合がある | 2つ目のデータベースを置くなら明確な目的が必要。 |
注文システムでよくある構成は次のとおりです。
[Transactional DB] -> [CDC / outbox] -> [Indexer] -> [Elasticsearch]
authoritative data search copy
CDCはコミット済みの変更を取得します。outboxは業務更新と同じトランザクションでイベントを記録し、別プロセスがインデックスに届けます。互いに独立した2回のアプリケーション書き込みが、常に両方成功することに依存せずに済みます。
それでも、インデックス更新には安定したID、バージョン管理、削除、再試行、遅延監視が必要です。元データからの再構築をテストします。そうしないと、検索用コピーが不整合な2つ目の正本になりかねません。
どの役割でも、バックアップを計画し復元を試します。レプリカは可用性に役立ちますが、バックアップの代わりではありません。実際の構成で許容するデータ損失と復旧時間を定義します。
注文の例なら、業務ルールを支えるデータベースにトランザクションのレコードを置き、検索要件が必要性を示したらElasticsearchを追加します。独立した検索中心のドキュメントなら、Elasticsearch単独で保存、整合性、復旧の要件を満たすか評価します。
**要点：**負荷が必要とする保証で選び、失敗と復旧の動作を検証します。検索速度は判断の一部にすぎません。
ジュニアからシニアまで、詳細な回答付きのIT面接質問ライブラリ。
寄付する