検索APIとApache Solr検索

Drupal 6でApache Solr Searchモジュールを使用しており、Drupal 7インストール用のSearch APIを探しています。ここでいくつかの議論を見ましたが、どちらかを選択する理由を探しています。

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

2015年時点で、Search APIとApache Solr Searchモジュールを数字で比較できます。

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

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

第二に、これらのモジュールのアーキテクチャの違いに起因するコミュニティによって2回解決される問題を回避するために、現在これらの2つのプロジェクト間で次のような共同の取り組みが行われています。

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

^{出典：AcquiaのDrupal 8のSearch＆Solrのバトルプラン}

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

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

Search API

APIの概要：

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

• エンティティAPIに大きく基づいています

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

拡張機能：

• Search APIオートコンプリート
• 添付ファイル
• 保存された検索
• ロケーション
• プリティファセットパス
• スライダー（検索API範囲）
• などなど。

基本構造：

インデックス機能：

• 異なるデータソース
• 1つのデータソース：エンティティ

• エンティティAPIに基づく：

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

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

Search APIビュー：

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

• デフォルトでは、エンティティのロードを介して取得されたデータ

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

Search APIレシピ：

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

• 追加するためのフック

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

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

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

アパッチソル

拡張機能：

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

Apachesolrレシピ：

• オープンソースのエンタープライズ検索プラットフォーム
• Apache Foundation
• 全文検索、強調表示、ファセット検索、クラスタリング、豊富なドキュメント処理
• 分散型
• レプリケーション/スケーラブル
• Java
• XML / JSONなどのREST HTTPと回答
• リレーショナルではない

出典：Search API vs Apachesolrスライドショー

こちらもご覧ください：

• コアDrupal検索モジュールはいつ使用する価値がありますか？
• コア検索モジュールよりもApache Solrを使用する利点は何ですか？

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

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

Search APIはインデックスを作成し、そのためにたくさんのすばらしいものを作成します。ただし、Search APIは、検索するデータのIDのみを取得します。これは、ID以外のデータを読み込むにはentity_loadが必要になり、データベースまたは適切なキャッシュレイヤーにヒットすることを意味します。検索が多いサイトの場合、これは最も最適化されたソリューションではない可能性があります。

これは、Drupalcon chicagoで、ApacheSolr統合モジュールについて説明した素晴らしいプレゼンテーションです。検索APIへの言及については、16分です。

あなたは本当に両方を試して、情報に基づいた決定をしなければならないと思います。ただし、apachesolrにはまだDrupal 8のベータ版がないことを強く考慮してください。

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

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

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