ビデオ検索について一言

今日、この素晴らしい春の日に、ビデオ検索だけでなく、技術的なことについても書きたいと思います。

ロードされたDjangoプロジェクトでのSphinxsearchの動作の実装。

おそらく、ビジネスタスクを設定することから始める価値があります。

• タイトル、説明、その他のテキストデータで関連動画を検索する必要があります
• 各動画について、 関連動画を探す必要があります
• 適切な場所で適切なリクエストを発行する際に、 適切なビデオを表示する必要があります。

非機能要件：

• dofigビューとビデオの説明の継続的な更新を含むDjangoプロジェクト
• ライブラリ内の検索エンジンでの作業のカプセル化と、サイト上の他のライブラリとの互換性（まず、Django REST Framework）

Rutubeでsphinxsearchがどのように使用されているか、そしてこのストーリーはどうなるか

ビデオの関連性と数学について

インターネットでの検索について話す場合、通常はテキスト情報を検索することを意味します。 ビデオの場合、すべてがはるかに悪いです。 通常、人とは非常に具体的な視覚的イメージを意味し、リクエストのテキストに変換します。 サイトに動画をアップロードしている他の人は、動画の内容を動画のタイトルと説明に翻訳しました。「test」、「sdfsdf」、または「111」でなければ良いでしょう。 いずれにせよ、最小限のテキスト情報のみが存在し、編集スタッフとパートナーユーザーが添付するメタデータもあります。 あなたが検索プログラマである場合、「なぜ検索されないのですか？Rp？」という質問は夜にあなたを悩ませます。特別なテストユーティリティは、これらの質問に答えるのに役立ちます。

これは、検索クエリによって、インデックスにあるすべてのフィールドを持つビデオだけでなく、各ドキュメントのすべての特性の値を持つランカーからの情報も返すページです。 このために、 PACKEDFACTORS()



、 SNIPPETS()



およびCALL KEYWORDS



要求されます。 通常、このページのデータは、 無関係と呼ばれるものを数学的に実証するのに十分です（ここでは、プログラマだけが数学的な意味で理解し、残りはすべて霊的な意味で理解できる魔法の言葉です！）...上記の関連 。

Djangoバックエンド検索ベース

Sphinxsearchはmysqlクライアントをサポートしているので、Djangoのバックエンドを使用して必要な検索クエリを作成し、結果をDjangoモデルとして返しませんか？ 誰もがこれを行うことをお勧めしませんが、それは本当にそれほど怖いではありません。 そして、まだ怖い、または単に興味がない人のために、次のセクションにすぐに進むことをお勧めします。

いつものように、githubには便利なものがあります。 たとえば、同じdjango-sphinx-dbは 、djangoモデルから直接エンジンを開始するのに役立ちました。 Django-1.8では、データベースバックエンド実装のプライベート部分が大幅に変更されたため、 django-sphinx-db



移植が問題になりました。 その結果、 django-sphinxsearchプロジェクトが登場しました。これは、開発側からの注意が少し欠けていますが、 すでに本番環境で使用されています。 ちなみに、ここにバックエンドサポートの難しさの例があります。Djangoの新しいバージョンがリリースされ、すべてがバラバラになります。なぜなら、「私の内臓は私が望むものを変える」からです。 ですから、最初から始めなければなりません。

次のようになります。

1. PEP-0249互換のデータベースコネクタを探しています。 MySQL-python、psycopg、python_monetdb-Djangoのねじ込み先によって異なります。
2. 精神的に最も近いバックエンドが取得され、継承されます。 sphinxsearchの場合、これはMySQL、別名django.db.backends.mysql
   
   
   
   です。
3. 最も難しいのは、バックエンドが記述されているデータベースと互換性のあるコードSQLCompiler
   
   
   
   生成するようにSQLCompiler
   
   
   
   に教えることです。 これは、引用符の使用、スキーマを指定せずにテーブル名を指定する機能、LIMIT / OFFSET構文などに適用されます。 ここで、 SQLCompiler.as_sql
   
   
   
   から文字列を収集するSQLCompiler.as_sql
   
   
   
   メソッドがほぼ100行のモノリスであるという事実について、Django開発者に別の「妖精」を言いたいと思います。 その結果、 LIMIT OFFSET
   
   
   
   をLIMIT start, end
   
   
   
   に変更するには、基本クラスメソッドを呼び出した結果を定期的にLIMIT start, end
   
   
   
   があります。
4. 検索固有の機能を提供するQuerySetメソッドが追加されました。 たとえば、 SphinxQuerySet.match
   
   
   
   はself.match構造をSphinxQuerySet.match
   
   
   
   追加し、SphinxQL式の構築に必要なデータが含まれます。 一致フィールドは複製され、 SphinxWhereNode.make_atom
   
   
   
   で変更され、最後にSphinxWhereNode.make_atom
   
   
   
   使用されてクエリ文字列の一部を生成します。 複雑なことは何もありません。テストを書いて、手元に良いデバッガを用意するだけです。

検索結果ランキング

通常、検索結果は、検索クエリとの関連性によってソートされます。 それを数えるには？ たとえば、ドキュメントとクエリに同時に存在する単語の数を取得できます。 交差点の単語が多いほど、このクエリにより正確に結果が適合します。 一致する単語の数だけでなく、それらの順序も考慮することができます。 そして、各単語の「希少性」が考慮される場合、それは一般的にクールです。リクエストおよびドキュメント内の前置詞と接続詞の存在は、もはや問題に影響しません。 そのような特性を発明した多くの異なる、有用な、そしてそれほど多くはないので、一般的なケースでは、エンジンが考慮するすべての特性の値の加重和を使用するのが合理的です。

特定のドキュメントを検索クエリに関連付ける特性に加えて、クエリに関係なく、特定の属性を持つドキュメントに重みを追加することができます。 たとえば、高品質でロードされたビデオの出力を増やすため。 または、最近の動画や視聴回数の多い動画に重みを付けます。

リクエストに追加します

 SELECT weight() + a * view_count + b * age as my_weight, ... OPTION ranker=expr('...') ORDER BY my_weight DESC;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、発行のソート順は完全に管理されています。

そのため、簡単な方法で次のようになります

• ランキング式の一般的なビュー
• 個々のフィールドの重み（タイトル-説明の10倍重要）
• 個々の特性の重み
• 検索クエリと「一致する」結果に対する追加のボーナス

QuerySet.iterator（）

（編集者は、これらの「ねじれ」が十分でないことをほのめかしています）

検索クエリの調整だけでは不十分な場合は、結果を爪で「釘付け」できます。 一部のクエリでは、これは一般に重要な機能であるため、必要ではありませんが、検索結果を操作するメカニズムを実装する必要があります。

1. 編集者が検索結果に表示したい現在のリクエストの動画があるかどうかを探しています。 それらが占有されている位置を取得します。
2. 「ネイル」結果以外の検索をリクエストします。
3. QuerySet.iterator QuerySet.iterator()
   
   
   
   メソッドを変更して、「通常」状態のsphinxsearchからの結果を返し、一部の場所で同じ「釘付け」クリップを返すようにします（たとえば、「Real男の子。「コメントなし」。
4. 検索で無関係な結果が生成される場合、一般的に、たとえば、類似のクリップの代わりに、データベースから何か、たとえば同じシリーズのエピソードのリストを表示できます。 これを行うには、メインVideoモデルがSearchVideo検索結果のモデルとフィールドを一致させるだけで十分です。

技術的な制限

sphinxsearchでできないことについて少し説明します。 最も奇妙で、同時に説明不可能な「不可能」：1つまたは複数の文書を除いてすべての発行を発行することは不可能です。 フルスキャンだけを実行できますが、フルスキャンWHERE MATCH('~document_id')



〜document_id WHERE MATCH('~document_id')



は実行できません。 ソフトウェアは、非効率的に禁止しています。

制限には2つの制限があります。最初に、明示的にLIMITを指定しないSELECT *



、ほぼrepr(queryset)



ような20の結果を返します。 次に、100500番目の要素を見つけるには、クエリにOPTION max_matches=100500



を追加します。 エンジン内には部分的な並べ替えがあり、既定ではウィンドウサイズは1000です。その結果、より大きなオフセットを要求するとエラーになります。

属性を持つ数値演算には多くの奇妙な制限があります。 例えば、 SELECT



ではfloat_field <> 3.1415



記述できますが、 WHERE



では記述できません。 何ができるか、特にパーサー。 QuerySet.extra()



を介して戦います。

最も不快な「不可能」：最も不快な瞬間に検索がクラッシュしないという事実に頼ることはできません。 番号「13」を含むリクエストを受信した直後にsearchdが再起動する場合がありました。 これは、検索結果が主要なコンテンツではないページでは特に不快です。 ジェネレーターで管理しました。OperationalErrorを受け取った場合、静かに平和的に空の応答を返します。

負荷がかかっている

サイトに多くのデータがあり、それらが頻繁に変更される状況では、5分ごとにサイト全体を取得してインデックスを作成することはできません。 もっと賢くなければなりません。 検索で「犬を食べた」人にとって、このセクションはあまり面白くありません。なぜなら、物事はほとんどよく知られているからです。しかし、私はそれらを簡潔に要点まで説明します。

1. メイン+デルタ+キルリスト。 main-サイト全体を含むメインインデックスは1日に1回更新されます。 delta-メインインデックスの最後のインデックス作成以降に更新されたドキュメントのみが含まれます。 killlist- 前のインデックスから除外する必要があるドキュメントのリスト。

   
   
   
   
   
   
   

    #  IP   sql_query_pre = set @ip = substring_index(user(), '@', -1); #  delta-  KILL-  # ,    delta- + # ,     main  sql_query_killlist = select id from ... where ... and last_updated_ts > @last_index_ts
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

   
   
   
2. global_idf 複数のローカルインデックスがある場合、global_idf = 1パラメータを指定する価値があります。 そうでない場合、逆ドキュメント頻度はインデックスごとに個別に考慮されます。その結果、「デルタ」からの「まれな」単語が存在しないはずの結果を押し上げます。
3. いくつかの検索エンジン。 検索エンジンのインデックスファイルの複製については賢くならず、各サーバーが個別にデータベースのインデックスを作成します。 同期が取れていないデータが発生し、さらに安定したソリューションが発明されましたが、これまでのところ手が届きませんでした。 解決策：RT-index。ドキュメントの変更に関するメッセージを受信すると、すべての検索エンジンで同時に更新されます。 長所：インスタントインデックス作成、通常状態でのデータrassynchronの欠如。 短所：開始コードを送信する非常に複雑なメッセージ。 検索ドキュメントには、約15のデータベーステーブルからのデータが含まれており、各検索サーバーにメッセージハンドラが必要です。
4. サーバーの負荷。 もちろん、LoadをCPUの100％にしない方が良いですが、これが標準になっている場合は、理論的なクエリ実行時間を制限するmax_predicted_time
   
   
   
   オプションがあります。 関連性は低下しますが、問題の一部は削減できます。 「神はすべてを見る」ので、可能ですが、必要ではありません。 神は編集者であり、すべては、たとえば、ページ上の非常に奇妙な「類似した」ものの外観です。 一時的な過負荷にCONN_TIMEOUT
   
   
   
   は、Django接続にCONN_TIMEOUT
   
   
   
   を設定して、検索が他のすべての速度を低下させないようにするのが理にかなっています。
5. 同義語と例外リストの管理。 これをWebDAVで分解し、最も近いインデックス付けで（インデックスの回転中に）適用します。

RTインデックスの変更について

それでも、sphinxsearchはデータベースではありません。 ただし、その中のデータを変更する可能性があります。

• UPDATE
  
  
  
  では、固定長の属性をUPDATE
  
  
  
  できます。 ところで、オンディスクインデックスでも。
• それ以外の場合は、 REPLACE
  
  
  
  使用され、古いバージョンのドキュメントが削除され、最後に新しいバージョンが追加されます。
• したがって、Djangoのバックエンド開発者にとっての困難は、まず、 queryset.update(field=value)
  
  
  
  は数値属性に対してのみ機能し、 REPLACE
  
  
  
  は一括挿入としてフォーマットする必要があります。 第二に、 REPLACE
  
  
  
  構文はINSERT
  
  
  
  とさらに類似しています。 SQLInsertCompiler
  
  
  
  を使用してSQLInsertCompiler
  
  
  
  する必要がありSQLInsertCompiler
  
  
  
  。 一般的に、考えるべきことがあります。

生産で3年間sphinxsearchを使用した後、検索チーム全体が情熱的かつ心から彼を愛していました。 おそらく、これはすべての問題がとても奇妙で面白い唯一のプロジェクトです:)

• DSPH-146赤ちゃんと窓枠
• DSPH-115ハムスターが壊れています（検索結果）
• DSPH-129は、類似の動画から同じ動画を削除することに同意しました
• DSPH-118悪い類似、非常に悪い
• DSPH-131再び似たような、再び嫌な

Rutubeのsphinxsearchは、Kibana自転車のログを保存および処理するために使用されます-ちなみに、かなり高速に動作します。 時間があります-彼についてお話します。