パーソナライズされた書籍検索サービスを紹介させてください。 従来の検索とは異なり、ここでシステムは、ユーザーからリクエストを受信すると、それらを何度も検索します。 新しい一致が見つかるたびに、システムはユーザーに通知を送信します。 したがって、ユーザーが必要なすべての書籍を見つけて検索クエリを削除するまで、これが繰り返されます。
個人検索のアイデア
私は個人検索のアイデアの発見者ではないと考えています。 それにもかかわらず、私はこれについて簡単に説明します。 したがって、興味深いサイト（たとえば、私のような書籍の販売と交換に関するサイト）にアクセスしたとします。 ここでは、ユーザーが定期的に新しい本を追加していることがわかります。 そして、私たちが必要とするものが現れようとしていることを期待して、常にサイトに行くだけです。それはなんとなく不便です...はい、私たちは忙しい人です、私たちはそれを忘れることができます...
したがって、アイデアはすぐに生まれます-すべての「汚い仕事」を検索ロボットの肩に降ろしたらどうなりますか？ 魅力的ですね！ 私たちが彼に伝えた本を検索して、そのような本が実際に登場したときにだけわざわざ知らせてください。
考えてみると、同じアプローチを適用できる多くのケースを見つけることができます。 たとえば、適切な求人が都市に現れたという通知。 必要な薬が薬局に運ばれたこと（あなたは決して知らない、慢性疾患の人、薬は終了している）。 面白いガジェット/ビデオカード/ハードドライブがあったこと...それは簡単なことのようですが、あなたはあなたの時間を費やす必要があります。 定期的に。 そして、情報がまだ数十のサイトに散在している場合はどうでしょうか？ 一般的に、不便です。
個人のブック検索
しかし、本に戻って。 書籍は、書籍が検索クエリに一致するかどうかを簡単に判断できるという点で便利です。 たとえば、「ルキヤネンコ」は常にルキヤネンコの本であり、「ベースボードの背後にいる私を苦しめる」はまさにそのような本であり、他にはありません。 したがって、すべての作業の95％は検索アルゴリズム自体ですぐに実行できますが、残りの5％はエディターに残ります。 対処方法-一部の検索クエリはあいまいに見え、無関係な一致の大きなストリームを提供します。 手でそれらを除草しなければなりません。
それにもかかわらず、そのような単純なモデルでさえ、数はかなり良いです：約3000の着信書籍と約200の検索クエリから、約300の一致する書籍が見つかりました。 つまり、実際には、追加時の10分の1ごとに既に潜在的な買い手がいます（時には一度に数人）。
最後に、少し技術的な秘密を開きます。著者が検索クエリに入力されると、システムは直接バージョンだけでなく、同義語も検索します（たとえば、「Lukyanenko」=「Sergey Lukyanenko」=「Lukyanenko、Sergey」=「Lukyanenko S」） 。 シノニムはデータベースに保存され、可能な限り補充されます。また、サイト上の広告からの資金提供も可能です:-)
サービス拡張
最初は、個人検索はサイトの登録ユーザーに対してのみ可能でした。 最後に、約3か月の慣らし運転の後、この機会を一般のゲストに開放することが決定されました。 これで、誰でも本の検索クエリをサイトに残すことができます。
しかし、これはまだ最もおいしいわけではありません。 先日、私たちのサイトの本だけでなく、LiveJournalコミュニティの本も検索範囲を広げることができました。 約30のrssフィード（アクティブな書籍コミュニティ）がシステムに接続されていました。 次に、スクリプトはコンテンツをダウンロードし、メッセージ内で検索語を検索します。 関連性については、現在の日付から20日以内のメッセージのみが分析されます。 最初の起動で、ユーザーの検索クエリに適した約50冊の本がすぐに発見されました。これも非常に良い指標です。
すでにアルゴリズムは「湿っています」が、計画では、rssフィードを介して自分の本を表示する他の本プロジェクトを接続することが可能になります。 さらに、後で「個人検索エリア」を導入する予定です-「私の都市」、「私の都市および最も近い都市」、「すべての都市」。 結局のところ、誰かが珍しい本を探していて、海外からでも注文する準備ができており、誰かが彼らの街のベストセラーであることが起こります。
性能
パフォーマンスは別の問題です。 このアルゴリズムはリソースを大量に消費するため、データベースのローカルコピーで実行する必要があります（便利なことに、バックアップが作成され、すぐに検索が実行されます）。
典型的な数字：ブックテーブルの合計サイズは約1万1千レコードで、200〜300レコードごとに検索が開始されます。 リクエストの数は約200です。スクリプトは私のマシンで約1分間実行されます。 それほど面倒ではありませんが、サービスが増加するにつれて、最適化について考える必要があります（現在は、テーブル間の関係が多数あるため、長い間考えているようです）。 ただし、比較のために、LJからダウンロードしたトピックのテーブルで同じ200のクエリを実行した場合、約7秒しかかかりませんでした。 ただし、テーブルは1つしかなく、約70エントリです。 一般的に、実験は継続されます。