web-dev-qa-db-ja.com

Search APIとApache Solr Search

私は Apache Solr Search モジュールをDrupal 6で使用しており、 Search API for a Drupal 7 install。私はいくつかの議論を見ました ここ しかし、どちらか一方を選択する理由を探しています。

どちらか一方を選択する理由はありますか？もしそうなら、なぜ、なぜそうでないのですか？ Search APIには複雑性の問題やパフォーマンスの問題がある可能性があると聞いています。これは本当ですか？

search
33
hross

2015年の時点で、検索APIとApache Solr検索モジュールを数値で比較できます。

                   | Apache Solr Search  | Search API
Posted in:         | 2007                | 2010
Downloads:         | >2k                 | >20k
Reported installs: | >21k                | >64k
Total bugs:        | >1200               | >600
Active bugs:       | >200                | >170
Commits:           | >1.3k               | >1.5k

これは明確な選択を示します。 Search APIは3年後に開発され、競合他社を利用することに成功しました。

さらに、Search APIは非常に異なる、より柔軟なアーキテクチャを提供し、より積極的に維持されています。さらに重要なことは、Apachesolrにはまだない最新の Drupal 8 とSolr 5.xがすでにサポートされていることです。

Search APIは新しく始まり、Viewsサポートを含む構成でより柔軟になりました（Apachesolrの場合は、追加のモジュールが必要です）。その機能を拡張するモジュールもたくさんあります。

次に、これらのモジュールのアーキテクチャーの違いによりコミュニティーによって2度解決される問題を回避するために、現在、以下のようなこれら2つのプロジェクトの間にいくつかの結合された取り組みがあります。

  • Facet API （フィルターとも呼ばれる）を介してファセットブロックを表示する一般的な方法を作成します。
  • 共通のスキーマとsolrconfig.xml構成ファイル
  • 両方のメンテナが協力して、Apache Solr検索モジュールから検索APIに接続クラスを移行しました。

出典： 検索＆SolrのバトルプランDrupal 8 Acquiaで

同じ環境で両方のモジュールを使用することはお勧めしません。

差異の詳細な技術分析については、以下の詳細を確認してください。

検索API

APIの概要：

  • 検索を簡単に作成するためのフレームワーク
  • データソースとバックエンド実装からの要約
  • 拡張機能を備えた大規模なエコシステム。バックエンド
  • ファセットAPIの統合

  • Entity APIに大きく基づいています

    • メタデータを提供します
    • インデックスとサーバー構成に使用

拡張機能：

  • Search APIオートコンプリート
  • 付属品
  • 保存された検索
  • ロケーション
  • Pretty Facets Paths
  • スライダー（検索API範囲）
  • などなど。

基本的な構造：

Basic Structure of Search API Solr module

インデックス機能：

  • さまざまなデータソース
  • 1つのデータソース：エンティティ

  • Entity APIに基づく：

    • 各プロパティにはインデックスを付けることができます
    • 関連するエンティティのプロパティにインデックスを付けることができます

インデックスの構成方法-フィールド：

How to configure your index - fields in Search API Solr

検索APIビュー：

  • フルビューのサポート
  • エンティティのプロパティを表示する
  • インデックス付きフィールドをフィルター、引数、または並べ替えとして使用する
  • Entity APIのビュー統合に基づくほとんどのコード

  • デフォルト：エンティティの読み込みによって取得されたデータ

    • バイパス可能（サーバーの「Solrからデータを取得」設定）
  • 代替：Search APIページ

Search APIレシピ：

  • インデックスとサーバーのCRUDフック

  • 追加用のフック

    • データソース
    • バックエンド
    • データ変更
    • プロセッサー

  • アイテムのインデックス作成時に発生するフック

  • 検索の実行時に発生するフック

Apachesolr

拡張機能：

  • 添付ファイル（メディアサポートなし、他のエンティティへの添付ファイルのカスタムコーディング）
  • 場所（Apachesolr geo、Apachesolrの場所）

Apachesolrレシピ：

  • オープンソースのエンタープライズ検索プラットフォーム
  • Apache Foundation
  • 全文検索、ハイライト、ファセット検索、クラスタリング、豊富なドキュメント処理
  • 分散
  • レプリケーション/スケーラブル
  • Java
  • REST HTTPおよびXML/JSONなどの応答
  • 関係なし

出典： 検索API対Apachesolrスライドショー

以下も参照してください。

19
kenorb

私は両方を使用してみましたが、私はこれを言うことができます：それはあなたの状況に依存します。

現在、ApacheSolr統合モジュールの安定した7リリースでは、ノードのインデックス作成のみが可能です。したがって、インデックスを作成する必要がある非ノードエンティティがある場合は、まだ進行中の multientity パッチを使用する必要があります。 ApacheSolrインテグレーションは、適切に設定されている場合、コンテンツの多くの異なるデータを保存できます。

Search APIはインデックスエンティティを実行し、そのためにすばらしいものをたくさん書いています。ただし、Search APIは検索しているデータのIDのみをフェッチします。つまり、ID以外のデータをロードするには、entity_loadが必要であり、データベースや、配置したキャッシングレイヤーにアクセスする必要があります。検索が多いサイトの場合、これは最も最適化されたソリューションではない可能性があります。

ここ は、ApacheSolr統合モジュールについてdrupalconシカゴで行われた素晴らしいプレゼンテーションです。検索APIについて言及する16分目です。

24
LSU_JBob

私はあなたが本当に両方を試みて、情報に基づいた決定をしなければならないと思います。ただし、apachesolrにはまだDrupal 8.のベータ版がありません。

Search APIでは、同じSearchAPIインデックスのエンティティを組み合わせることはできません。したがって、プロファイル、ユーザー、ノードは異なるインデックス上にあります。マルチインデックス検索を可能にするモジュールがあり、それは私のニーズをカバーしていませんが、YMMVをカバーしています。同じインデックスに多くのコンテンツタイプと多くのフィールドがある場合、インデックスの定義が非常に扱いにくくなる可能性があります。 （NB IndexAPI D8レポートは、マルチインデックス検索をサポートしています）

Apachesolrではコンテンツごとにフィールドを編集できますが、これは簡単かもしれませんが、関連するコンテンツをドキュメントに追加する機能はありません。実際には、フィールドコレクション、参照、およびその他の情報を含むカスタムコードを記述する必要があります田畑。 Apachesolr D7は、ビューを使用しない限りajaxをサポートしませんが、ビューを使用するとファセットが失われます。とはいえ、フックにコーディングしておけば、インデックスに格納されている情報を変更するのは簡単です。

エンティティIDを検索し、それぞれを個別にレンダリングする（両方のモジュールで使用可能）という考えは、パフォーマンスの悪夢のように思えますが、エンティティの表示をキャッシュする場合は、solr応答からのレンダリングよりも効率的です。

2
dmcg