Clever Geek Handbook

Ubuntu 12.04でのsolrのインストールとdjangoとの統合

画像画像



はじめに



ご存知のように、多くのサイト/ Webアプリケーションでは、何らかの方法で検索を実装する必要があります。 誰もが迅速かつ質の高い検索を望んでいます。 とりわけ、開発者は検索エンジンのインストールと使用が簡単であることを望んでいます。 djangoについて話しているので、検索の実装には多くの制限があります（ただし、24時間と期限はキャンセルされていません）。 apache solrのような強力な検索エンジンとして、できるだけ簡単にdjangoプロジェクトにインストールして統合する方法に関する小さなチュートリアルを紹介します。 私は猫の下で興味があるすべての人に尋ねます。







熊手



過去には、django-sphinxであまり快適な経験がありませんでした。 Sphinx自体は優れた検索エンジンであり、django-sphinxも素晴らしいライブラリですが、django 1.3の後は、このスタック全体を取得するためにタンバリンと少し踊らなければなりません。 しかし、これがすべて設定されて動作した後でも、プロジェクトのモデルとは関係のないクラウンインデックスと構成によって、プロジェクトとは別に、すべてがそこにあるという感じが残ります。 はい、そこには設定ジェネレータがありますが、1.4 +以下でそれを取得することはできませんでした。そして、各世代の後に、検索エンジン自体（searchd）の設定を編集する必要があるでしょう。 一般に、django-sphinxの検索は、さらに迅速かつ効率的に機能しますが、それを維持したり、プロジェクトに統合したりすることはあまり便利ではありません。



干し草の山で針を見つけた方法



これが新しいプロジェクトの番です。 そして再び、検索エンジンを選択するという疑問が生じました。 私たちはすぐにdjango-sphinxを拒否し、代替ソリューションを探し始めました。 最初に気づいたライブラリはdjango-haystackです。 これは、djangoに検索エンジンを統合するための最も人気のあるライブラリです。 APIを確認した後、停止しました。 提案されている検索エンジン（elasticsearch、solr、whoosh、xapian）との完全な統合が約束されました。 簡単な検査の後、次の決定が行われました。



  1. Whooshは、いくつかの小さな機能が不足していたため除外されましたが、その一部はプロジェクトに必要でした。 はい、そして彼らは彼が他の選択肢にスピードで負けていると言います。
  2. Xapianは、サードパーティのバックエンドを統合しようとして失敗したため追放されました。
  3. 2つのオプションがあります-elasticsearchとsolr。 javaとluceneの両方の機能はほぼ同じです。 「コインを投げる」と、solrを使用することになりました。






もっと熊手



この記事では、干し草の山ではなくsolrでの作業について主に説明していることをすぐに言わなければなりません。 干し草の山に関する情報は公式のドックで見つけることができます、それはよくレイアウトされており、ここでそれを複製しています。



ライブラリが選択され、検索エンジンが選択されました。 仕事に取り掛かる時です。 最初の間違いは、公式のubuntu 12.04担当者からのインストールでした。 公式のラップバージョンはsolr 1.4です。ただし、トラブルを避けるため、haystackのドキュメントではバージョン3.5以降を推奨しています。 私たちは自分でそれを置くことにしました。 一連の試行錯誤の後、開発者のLANとテストサーバーおよび戦闘サーバーの両方で正常に機能するソリューションを思い付きました。 アクションのシーケンスの例を次に示します。



  1. システムパッケージjreとjettyを配置します。 
    apt-get install openjdk-7-jre-headless jetty
  2. Pythonまたは： 
     pip install pysolr django-haystack
  3. solr自体のグローバルインストールのための「ダークマジック」： 
     #!/bin/sh #variables LIB_DIRECTORY="/opt/solr" CONF_DIRECTORY="/etc/solr" OLD_CONF_DIRECTORY="$LIB_DIRECTORY/example/solr/conf" #check if already installed if ( [ -d $LIB_DIRECTORY ] && [ -d $CONF_DIRECTORY ] ); then echo "solr is already installed" exit fi #install if not #download and unpack wget http://archive.apache.org/dist/lucene/solr/3.6.2/apache-solr-3.6.2.tgz tar -xvzf apache-solr-3.6.2.tgz #install mv apache-solr-3.6.2 $LIB_DIRECTORY mv $OLD_CONF_DIRECTORY $CONF_DIRECTORY ln -s $CONF_DIRECTORY $OLD_CONF_DIRECTORY #cleanup rm apache-solr-3.6.2.tgz echo "solr installed"






もちろん、solrを「グローバルに」インストールしたくない場合は、スクリプトを少し調整して他のフォルダーに入れることができます。追加のダンスなしで解凍した直後にsolrが動作します。残りと同じ。



一般に、実行することはすでに可能であり、すべてが機能します： 

 cd /opt/solr/example/ && java -jar start.jar




しかし、私たちはそのようなすべてを残すことはできません。 構成、再インデックス付け、通常の起動はどうですか？ 順番に行きましょう。



構成



このコンテキストでは、2つの構成に関心があります。



  1. /etc/solr/schema.xml



    データスキーム自体と、データに直接関連するインデックス付けと検索のためのその他の情報。 この設定は、プロジェクトのインデックスを変更するたびに更新する必要があります。
  2. /etc/solr/solrconfig.xml



    自体の設定、つまり データに直接関連しないモジュール、ハンドラー、およびその他の設定。 この設定は、solrの追加機能が必要な場合に役立ちます。




構成のいずれかを更新した後、solrを再起動して変更を有効にする必要があります。 （実際、それはオプションであり、戦闘状態では明らかにより正確になるRELOADに制限できます。wiki.apache.org/ solr / CoreAdminを参照してください）

schema.xmlを生成するために、haystackは素晴らしいbuild_solr_schemaコマンドを提供します。 しかし、それは小さなマイナスを持っています-それを使用するとき、あなたは設定を置く場所を覚えておく必要があります、なぜなら 設定をコンソールまたはファイル（指定されている場合）に出力します。 自分のチーム（build_solr_schemaの完全なコピー）を作成し、ファイル名のデフォルト値（この場合は/etc/solr/schema.xml）を指定するだけで、少し修正できます。 したがって、このコマンドを実行するだけで設定が更新されるため、開発者の生活を少し簡略化しました。



インデックスの再作成



この場合、インデックスの関連性を維持するための2つのオプションがあります。



  1. 「クラシックバージョン」-N分ごとに完全なインデックス再作成。 頭に浮かぶこのアプローチの唯一の利点は、そのシンプルさです。 マイナス面がいくつかあります。大規模なデータベースでは時間がかかり、再インデックス付けの間にデータが無関係になる可能性があります。
  2. 「アトミック再インデックス付け」-post_save、post_deleteなどのシグナルによる各オブジェクトの再インデックス付け 主なプラスは、データベースのサイズに関係なく、明らかに速度です。 このアプローチでは、すべてのインデックス再作成コントロールがプロジェクトコードの完全なビュー内にあり、何らかのクラウンまたはせいぜいセロリタスクではないことが重要です。 ただし、いくつかの欠点があります。実装が正しくない場合のデータの無関係性と、インデックスの再作成で信号を呼び出す際のオーバーヘッド。 後者は、非同期タスク（この場合はセロリ）に入れることで排除されます。




2番目のオプションを選択し（両方を同時に選択することは禁止されていません）、実装にはモデルといくつかのタスクに単純な混合を使用しました。



ミックスイン 


 class RefreshIndexMixin(object): #index -   ,  PostIndex  CarIndex def update_index(self, index): current_app.send_task('project.tasks.update_index', args=[self, index]) def remove_index(self, index): current_app.send_task('project.tasks.remove_index', args=[self, index])




モデルでは、それぞれ、対応する信号でupdate_indexまたはremove_indexを呼び出すだけで十分です。



タスク 


 from celery import shared_task @shared_task def update_index(obj, index): index().update_object(obj) @shared_task def remove_index(obj, index): index().remove_object(obj)




通常の開始。



私たちはどこでもスーパーバイザーを使用しているので、この場合、私たちは長く考える必要はありませんでした。 LAN /テストサーバーの設定例を次に示します。 



 [program:solr] command=java -jar start.jar directory=/opt/solr/example/ stderr_logfile=/var/log/solr.error.log stdout_logfile=/var/log/solr.log autorestart=true


LAN /テストの理由 solrには「そのまま」独自の管理パネルが付属しているため、インデックス、設定などを確認したり、このデータを使用してあらゆる種類の操作を行ったりできます。 戦闘サーバーでは、このような機能を放棄する可能性が高いため、デフォルトポートのローカルホストでのみ起動コマンドを次に示します。 



 command=java -Djetty.host=127.0.0.1 -Djetty.port=8983 -jar start.jar




まとめ



一番下の行には何がありますか：







このバンドルを使用している間、すべての面で優れた方法で表示されています。 ユーザーと顧客は、サイトでの迅速かつ適切な検索に満足しています。 開発者にとって、そのようなjavaモンスターの存在はほとんど見えません。 インデックス、いくつかのmanage.pyコマンド、およびスーパーバイザーを介したsolrリロードのみが必要です。


More articles:


All Articles