単一の VM 上で複数のクライアント電子商取引 Web アプリケーションが実行されており、各 Web アプリケーションは node.js express アプリケーションです。
Express Webアプリケーションは、APIを介してバックエンドと通信し、ページのコンテンツや製品リストなどを取得します。ただし、製品検索を高速化するために、現在はインメモリデータベースを使用しています（ロキ) に対してすべての検索が行われるようにしていますが、各クライアントの平均的な製品カタログは 80 項目程度しかないため、現時点ではこれで十分です。各クライアントの Web アプリ内で単純な cron を実行し、API 呼び出しを介して最新の製品リストでメモリ内データベースを更新しています。
これの欠点としては、2 ノード クラスターで各アプリケーションを実行するために PM2 を使用しているため、ノード間でメモリを共有できないため、インメモリ データベースを複製する必要があり、インメモリ データベースの同期を維持するために、IPC を使用してクラスター内のすべてのプロセスにメッセージを渡す必要があることが挙げられます。
より大きな製品カタログを備えたより大規模なクライアントを導入しているため、各子プロセスに対して重複したメモリ内データベースを保持することは望ましくありません。
当社のサービスでは、製品カタログはクライアントごとに大きくはありませんが、検索量は非常に多いため、80 個のアイテムを持つクライアントでも 1 日に 1,000 件の検索が行われることがあります。
いくつかの選択肢を思い浮かべましたが、どれが最善かはわかりませんでした。
オプション 1 - 単一のグローバル Elasticsearch クラスター
私は elasticsearch の使用について話し、検討し、すべてのクライアント Web アプリケーションを単一のグローバル elasticsearch クラスターにポイントして製品検索を実行します。この方法では、イベントを使用して elasticsearch データベースをリアルタイムで最新の状態に保つことができます。
しかし、スケールアップしたときにこれがどのように機能するかはわかりません。Elasticsearchがボトルネックになることは望んでいません。
オプション 2 - ローカル NoSQL データベース
2 番目のオプションは、インメモリ データベースとして lokijs の使用を単純に置き換え、各 VM に共有の NoSQL データベース (mongo など) を用意することです。すべての Web アプリはクエリにローカル データベースを使用しますが、各 Web アプリは引き続き独自のストアの製品カタログを更新する責任があります。その後、VM を追加すると、各 VM は、そこで実行されているすべてのアプリが使用できる独自のローカル データベースを持つことになります。
私たちはファセット検索を頻繁に使用しており、ファセットのカウントを取得するためにファセットの集計を使用しています。