0

保存された検索とは何ですか?

保存は、ユーザーが高度な検索で目的の結果を見つけられず、[マイ検索基準の下部を保存] を押すだけのメカニズムです。検索基準を保存し、対応するデータが Web サイトに投稿されると、ユーザーに「ユーザー、アイテム( s) あなたが探していた存在が今ここに来て、それを訪れてください」.

保存された検索は、複雑な検索オプションを持つサイト、またはユーザーが検索結果の動的なセットを再訪問または共有したいサイトに役立ちます。

高度な検索があり、新しい検索を実装する必要はありません。必要なのは、保存された検索メカニズムを実現するための優れたパフォーマンス シナリオです。

ユーザーが 1 日あたり約 120,000 の投稿を Web サイトに投稿する Web サイトがあり、SAVED SEARCH シナリオ ( https://www.gumtree.com/のようなもの) を実装しようとしています。これは、高度な検索を使用しているユーザーを意味しますが、目的のコンテンツが見つからず、検索条件を保存したいだけで、ウェブサイトに結果がある場合は通知でお知らせします。

ウェブサイトでは Elastic search と Mysql を使用しています。私たちはまだ何も実装しておらず、高レートの日付を処理できる良い解決策を見つけるためにそれについて考えているだけです.**問題は作業の規模です.1日に多くの投稿があり、ユーザーはこの機能を頻繁に使用していると思われるため、この規模の作業を簡単に高パフォーマンスで処理できる適切なシナリオを探しています。

提案された解決策ですが、最善ではありません

  • 簡単な解決策の 1 つは、保存された検索を Elastic のsaved-search-index に保存してから、すべての保存された検索項目について posts-index-Elastic から結果を取得する cron ジョブを実行し、結果があれば RabbitMq にレコードをプッシュして、同等のユーザーに通知します。

  • ユーザーがウェブサイトにアイテムを投稿すると、Elastic のsaved-search-index に存在するsaved-searches でアイテムをチェックし、一致する場合はRabbitMq にレコードを入れます(この方法の主な問題は、巨大なウェブサイトに挿入されたすべての投稿の保存された検索の数)。

私の大きな関心事は規模とパフォーマンスです。この問題についての経験とアイデアを私と共有していただければ幸いです。

スケールについての私の見積もり

  • 保存済み検索の有効期限は 3 か月です
  • 1 日あたり少なくとも 200,000 件の保存済み検索
  • つまり、9,000,000 のアクティブなレコードがあります。

あなたが私とあなたの心を共有してくれれば、私は感謝します

*参考までに** - キュー ジョブ用に RabbitMQ もあります - ES サーバーは 64GB RAM で十分です

4

4 に答える 4

0

この回答は、「保存された検索」の意味を真に理解することなく書かれました。関連する問題の議論としてここに残しますが、「保存された検索」ソリューションとしてではありません。 -- リック・ジェームス

「クエリ」のみを保存している場合、問題はありません。クエリと「結果セット」の両方を保存していると仮定します...

1 秒あたり 1 つの「保存された検索」? 240万行?必要に応じて検索を再実行してください。システムは、その小さな負荷を処理できる必要があります。

データが変化しているため、結果セットはすぐに古くなりますか? いつですか?つまり、結果セットの保存はかなり迅速にパージする必要があります。確かに、データは 1 か月待つことができるほど静的ではありません。多分1時間?

実際に結果セットを保存して再生できるようにするには、(1) コードの複雑さ、(2) キャッシュ、I/O などのオーバーヘッドなどを伴います。

ユーザーが同じ検索を参照する平均回数は? 先ほど述べたオーバーヘッドのため、オーバーヘッドを正当化するには、平均回数を 2 回以上にする必要があると思います。

結論...これは「時期尚早の最適化」のようなにおいがします。私はお勧め

  1. 結果セットを保存せずにサイトを構築します。
  2. ストレステストをして、いつ壊れるかを確認します。
  3. 遅い部分の最適化に取り組みます。

RabbitMQ に関しては -- 「キューに入れずに実行してください」。キューイングとキューイング解除のコストは、(1) ユーザーの待ち時間の増加、および (2) システムのオーバーヘッドの増加です。(中規模での)メリットは最小限です。

スケーリングの問題が発生した場合は、考慮してください

  • クライアントをデータベースから離れた別のサーバーに移動します。これにより、ある程度のスケーリングが得られますが、2 倍にはなりません。もっと遠くへ…
  • レプリケーションを使用します: 1 つのマスター + 多数の読み取り専用スレーブ -- そしてスレーブでクエリを実行します。これにより、データベースで事実上無制限のスケーリングが可能になります。
  • 複数の Web サーバーを用意します。この部分では実質的に無制限のスケーリングを行います。
于 2017-10-08T16:47:29.850 に答える