1

この機能は次のように動作します。

  • Web サイトにはユーザーがいて、ユーザーは任意の数の検索を保存できます (たとえば、NY の求人、PHP の求人など)。多くのパラメーターが関係しているため、これをインデックス化することは事実上不可能です (私は MySQL を使用しています)。
  • 毎日多くの新しい求人がウェブサイトに掲載されます
  • 24 時間ごとに、過去 24 時間以内に投稿された求人を取得し、それらを既存の求人検索と照合してから、一致する求人についてユーザーに電子メールで送信します。

ここでの問題は、トラフィックの多い Web サイトであり、楽観的なケース (新しい求人がほとんど掲載されていない) であっても、この検索クエリを実行するのに 10 分かかることです。この問題に対する古典的な解決策はありますか? 検索が集中する場所で Sphinx を使用してきましたが、ここでは適用できません。Sphinx はすべての結果を返すわけではなく、最終的にはそれらを切り捨ててしまうからです。今のところ、私ができる最善の方法は、search.matched_job_ids 列を用意し、求人が投稿されるたびに既存のすべての検索と照合し、一致した検索の Matched_job_ids 列に求人 ID を記録することです。一日の終わりに、ユーザーにメールを送信し、列を切り捨てます。これにより技術的にパフォーマンスが向上することはありませんが、1 つの大きなクエリではなく多数の小さな検索クエリを実行することで、時間の経過とともに負荷が分散されます。

4

1 に答える 1

1

各ジョブは、ジョブ範囲、ジョブ名、給与などのパラメーターの数で記述できます。各パラメータには事前定義された値のセットがあります -

  1. 職種 - IT、医療、産業...
  2. 職種名 - プログラマー、テスター、ドライバー...
  3. 1 か月あたり 10 ～ 50 千、50 ～ 100...
  4. フレックスタイム、フルタイム、フリーランス...

保存された検索をエンコードしましょう。すべてのパラメーター (ジョブ名だと思います) の値の最大数は、数値システムのベースです。パラメータ数 - 桁数。

BIGINT = 2^64-1 = 18 446 744 073 709 551 616 = 20 digits. 通常の 10 ベースのシステムでは、20-1 (first digit is fixed) = 19それぞれ 10 個の値を持つパラメーターを記述できます。ジョブ名などのパラメータを記述するには 10 個の値では不十分なため、30 ～ 60 ベースのシステムを使用する必要があります。もちろんパラメータの総数を減らすことにつながりますが、12～15個のパラメータで記述できるジョブもあると思います。

savedSearches(code,mail)(code,mail) に索引付けされたテーブルを作成します。インデックス タイプ - 主キー。

投稿された新しい仕事:

1) プログラムでエンコードします。
2) select mail from savedSearhes where code=calculatedCode. メールはカバーされたインデックスにあります - 選択は十分に速くなければなりません.
3) 選択したメールに新しいジョブを送信します。

重要な注意- 1 つのパラメーター - 投稿されたジョブのホスト会社には、値が多すぎる可能性があります。ユーザーは通常会社を気にしないため、savedSearhes テーブルではなく、個別に保存する必要があると思います。彼は給与やスキルなどを気にします。

たとえば、プログラマーの位置だけでなく、テスター、チーム リーダーなど、ユーザーが固定パラメーターではないものを検索したい場合は、単一のエンコードされた数値ではなく、間隔を検索する必要があります。

私の考えは単なる仮定であり、さらなる調査のための基礎です））

于 2013-08-16T10:24:33.470 に答える