Elasticsearchとリレーショナルデータベースの組み合わせ
ユーザーが製品を検索できるマーケットプレイスアプリケーションがあると想像してください（私たちは服に集中しています）。すべての製品には[〜＃〜] id [〜＃〜]、name（text）、description（text）、価格（数値）、サイズ（数値）、ブランド、状態など。
ユーザーは服を検索できます。現在、データはリレーショナルデータベース（PostgreSQL）に保存されています。名前と説明フィールド（テキストフィールドであるため）での検索に使用されるElasticsearchインスタンスが実行されています。
問題：すべてのパラメーターを使用して検索を絞り込むオプションをユーザーに提供したい-たとえば、ユーザーが特定のサイズ、条件、および説明を検索できるようにします。
私が見る方法は2つあります。
Elasticsearchとデータベース検索を組み合わせて実装する。これは、ある場所でデータをフィルタリングし、別の場所でフィルタリングされたデータを続行して、再度フィルタリングすることを意味します。
Advantage：全文検索にElasticsearchを使用し、特定の 'column-search'にデータベースを使用することは、どちらも得意です。両方の世界のベストを得るように。
欠点：検索を開始する場所を決定する方法は？もちろん、アイデアは、ほとんどのデータを削除できる場所から検索を開始して、2番目の検索がより小さなデータセットに対して実行されるようにすることです。
また、Elasticsearchインスタンスは確実にPostgreSQLとは別のマシン上にあるため、ネットワークのオーバーヘッドと応答時間の増加について話していることに注意してください。
Elasticsearchのみを使用します。テキスト検索を実行するPostgreSQLの機能を完全に認識していますが、これはElasticsearchほど強力ではなく、PostgreSQLが常に選択されたDBであるという保証はありません。
Advantage：すべての検索が1か所で行われます。中間結果などはありません。
欠点：述語に基づいてデータをフィルタリングする場合、Elasticsearchはリレーショナルデータベースと同じくらい強力です。サイズや価格などのフィールドについて話していることに注意してください-テキスト検索が重要ではありませんが、単純な
WHERE句は超高速です。
私が見逃している両方のアプローチの利点または欠点がありますか？どちらか一方に反対する、または反対する重要な何か？
ElasticSearchは、探している検索に十分効果的です。 ElasticSearchは、私が行ったベンチマーク（100ユーザー/秒、約3日間）を維持していました。ただし、永続性の観点からは、1つのステップを遅らせる必要があります。ノードの1つがダウンした場合、復旧にかなりの時間が必要であり、再びクラスタ構成（慎重な決定を行う）に依存します。十分なサイズのペイロード（2mb）を保持し、40以上のフィールドにインデックスを付け、9ノードのクラスターで4千万以上の注文を保存できます（ノード= 27、レプリケーション係数= 3）