しばらく前から、Hyper Estraierを全文検索エンジンとして、その上にアプリケーションを作ってみているのですが、その過程で感じたことなど。

[ 嬉しいこと・感心すること ]

(1)  作者の平林さんが優秀かつ仕事が素早い。
Version Upの頻度やMLでの回答の速さは感心するほかありません。もちろん、アイディアや知識も豊富だということにも、ホント感心します。
今日もMLに出した質問に対して、30分後には回答を返してくれていました。
属性条件(例えばタイトルとか、普通のキーワードとは別に管理されている特定の属性についての条件です)をつけた検索で検索結果件数が変動する現象は、性能とのトレードオフで、キーワード検索で絞り込まれた候補文書全ての属性を照合するのではなく、照合結果が要求された件数に達すると残りの合致件数は予測しているそうです。そんなことまでやってるのですよ、Hyper Estraierは。それとも全文検索エンジンでは、普通のことなのでしょうか？ 因みに、Googleでも同様の現象があるそうです。ということも平林さんの回答で初めて知りました。
なんだか、自分の無知さ加減が恥ずかしくなります。

(2) INDEXを分散させることができる。メタ検索ができる。
細かい点はともかく、INDEXの分散はとても分かり易い特徴で、また、スケーラビリティへの期待を抱かせられるところです。
単に、スケールのためだけでなく、Indexing対象の性質や分類などでINDEXを分別する仕組みをアプリケーションで考慮できるので、色々なことを画策できそうな気にもなります。
しかも、INDEXの分散、メタ検索を利用するために、Hyper Estraier側でHTTPプロトコルのネットワークサービスを装備してくれていて、尚且つシンプルなノードAPIという便利な利用方法が提供されています。

[ 悲しいこと・困ったこと ]

(1) 自分の無知さと仕事の遅さを再確認させられる。
何だか、自分でアプリケーション作っていても、その内、Hyper Estraierに同等以上の機能が実装されるような気もしますし。

(2) ノードAPIのメタ検索の性能的な不安を払拭できない。
さて、これが目下、微妙に気掛かりなところです。
検索結果が大量となるようなことはよくありがちです。何千件、何万件の結果がある検索の場合、当然、全件についての詳細な情報を取得するのは性能的に厳しいことですし、第一、せっかく取得しても利用者が人間の場合にはそんな大量の情報は利用できないので、無駄です。なので、普通は、せいぜい数十件分を1ページ分としてとりあえず返すことになります。でも、利用者が他のページも見たいと思った場合には、対象ページに遷移する必要があります。そうすると、そのページ分の数十件分の情報をまた取得する必要があります。
例えば1ページ当たり10件ずつ表示するとすれば、1ページ目は1件目から10件目の情報を、2ページ目は11件目から20件目の情報を、100ページ目は991件目から1000件目の情報を取得すればいい訳です。
ところが、これまでノードAPIでは、検索結果のn件目からm件分の情報を貰うということができなかったのでした。ですが、最新リリースの1.1.3では、skipパラメータというものが導入されて、このような要望が叶えられました！嬉しいことです。
ところがところが、メタ検索では、最終的なスコア順が個々のノードでの検索では決定できないので、n件目からという限定した検索はできないらしいのです。そう言われれば、確かにそうなのですが...でも、そうなると、メタ検索では、100ページ目の情報を得るためには、991件目からの10件分ではなく、1件目から1000件分の情報を取得する他ないことになるので、ちょっと、不安になる訳です。
多分、snippetを作成したりする処理はコストが大きいのではないかと思うので、ノードAPIで、文書IDとURIだけを返す検索メソッドを提供して貰って、1ページ分だけを改めてアプリケーションからノードAPIへ依頼するとかの方法が必要なのかもしれないとも思ったり。

あれ？ もしかして、メタ検索内で既に、候補取得のためのミニマルな検索(文書IDのみの結果)＋最終結果のための一般の検索(snippetなども含めた結果)という方法で実装されていりするのかもしれません。
早速、明日、動作確認してみねば。それより、MLで聞いた方が早いのかなあ!?