SOLRは基本的に、ApacheLuceneインデックスを照会するためのRESTインターフェースを実装するApacheTomcatコンテナーです。はい、WebサーバーでJavaアプリケーションを実行できる必要があります。これは、ホスティングプロバイダーと協力して解決するための問題です。
Webアプリを使用するクライアントは、Javaを実行する必要はありません。 PHPアプリは、SOLRサービスに対してRESTクエリを実行し、結果をHTMLでフォーマットすることができます。クライアントにはHTML出力のみが表示されます。データがJavaで実装されたサービスからのものであることを知る必要はありません。
Zend_Search_Lucene は、ApacheLuceneと同じように機能するはずの純粋なPHP実装です。 Zendソリューションは、同じインデックスファイル形式も使用します。したがって、ストレージに関しては、それらは等しくなければなりません。
私はJavaLuceneを使用してStackOverflowデータダンプのインデックスを作成しました（2009年10月）。約1ギガのテキストデータを含む150万行にインデックスを付けました。 Luceneインデックスは1323MBでしたが、同じデータのMySQLFULLTEXTインデックスはわずか466MBでした。
SQLの使用LIKE フルテキストのインデックス作成ソリューションの代わりの述語は、従来のインデックスを使用できないため、もちろんスペースを必要としません。しかし、LIKEを使用した私のテストでは Java Luceneよりも約200倍遅く、同じデータのMySQL FULLTEXTインデックスよりも約40％遅くなりました。
MySQLを使用したフルテキストインデックスソリューションに関する最近のプレゼンテーションを参照してください：
http://www.slideshare.net/billkarwin / Practice-full-text-search-with-my-sql
JavaLuceneテクノロジーのパフォーマンスとスケーラビリティーに匹敵することができないのは当然のことです。言語としてのPHPの利点は、実行時の効率ではなく、開発の効率を向上させることです。
更新： Zend_Search_Luceneを使用してインデックスを作成してみました 。 PHPを使用した場合のインデックスの作成はJavaLuceneテクノロジーを使用した場合よりもはるかに遅いため、インデックスを作成したのは10,000ドキュメントのみでした。これには約15分かかり、コレクション全体のインデックス作成には約36時間かかります。これを、私のテストで7分以内に150万のドキュメントの完全なコレクションにインデックスを付けたJavaLuceneと比較してください。
Zend_Search_Luceneで作成したインデックスのサイズ 8.75MBです。この150倍を外挿すると、完全なインデックスは1312.5MBになると推定されます。したがって、Zend_Search_Lucene JavaLuceneによって生成されたインデックスとほぼ同じサイズのインデックスを作成します。これは予想どおりです。