何がささやかな特性にもかかわらず、注目を集めて？
リアルタイムのインデックス作成の1.可能性。
2.文書の属性と検索での使用や結果をソート。
3.簡単な作業とコンパクトで明確なドキュメント（調査に数日かかりました。実際にはドックの対角線に沿って一見しただけで、製品のより詳細な調査を推進しました）。
Hyper Estraierに対する私の印象：
この検索エンジンはFalLabsペンに属し、その製品の1つは最近テスト済みです。 いくつかの興味深い機能の説明を含む短いユーザーズガイド（ラップトップで34画面、そのうちの3分の2が設定と構成の説明）が実験を誘いました。
個人的には、説明を勉強し、インストールに数分、最も簡単なオプションを見つけるために30分または1時間、3つのドキュメントのインデックスを作成し、結果を再生するのに約1日費やしました。
もう1日を費やして、すでに稼働しているデータのパフォーマンスを評価するためのインデックスを作成するプログラムと、クライアントサーバーアーキテクチャの調査とテストを行う1日を「ひざの上で」書きました。
デフォルトパラメータを使用した標準インストール：
$ ./configure
$ make
$インストールする
必要な可用性：
- libiconvを - のglibcの一部です。
-zlib-データ圧縮用
-QDBMは、組み込みデータベースである同じFalLabsの製品です。 上記と同じスキームによるインストール。
インデックス作成。
インデックスを作成するには、ドキュメントを「ドキュメントドラフト」という形式で送信する必要があります。これは、httpプロトコルの形式にイデオロギー的に近い独自の形式で、見出し/空白行/テキストです。
ヘッダは、「属性=値@」形式の属性を示します。 1行-1つの属性。
テキストはプレーンプレーンテキストです。 UTF-8エンコードファイル。
仕事。
1.最も単純なオプションはコマンドラインです。
estcmdユーティリティは、検索可能なインデックスを作成し、管理し、あなたが検索することができます。 -vhオプションを指定すると、検索結果は非常に読みやすく、スニペットとともにマルチパート形式で表示されます。 最初の行はブロック区切りです。 最初のブロックは、見出し、リクエストの結果-合計ドキュメント数、検索時間、各単語のドキュメント数などです。 この問題を解析することは簡単で楽しいです。
このオプションの場合、パッケージには単純なcgi-scriptが含まれています。ブラウザーを使用して、より馴染みのある方法で検索できます。
デザインでもっと美しいものが必要な場合は、便利なツールで出力を解析してください。
2.より複雑なオプションは、クライアントサーバーです。
彼は、検索エンジンでの作業マルチユーザのための希望しました。 さらに、最初のバージョンでは、データベースを開くのに時間がかかるたびに、この場合はこの操作を保存します。もちろん、最新の要求をキャッシュすると、繰り返し呼び出しの発行が大幅に高速化されます。
このオプションの検索へのインターフェース：
- C（ほんの一例のレコード）のためのAPI。
- Webインターフェイス - 単純な検索やデータベース管理;
-estcallコマンドラインユーティリティ-実際に同じhttpリクエストをサーバーに送信します。検索結果は前の段落で説明したものと同様です。
仕事のスピード。
テストは前回と同じサーバーで行われました-Opteron-2218、2.6GHz、8G OP、HDD 73G + 143G SAS。
この時点ですべての作業は、143ギガバイトのドライブのいずれかで行いました。
初期データ-1つのプロジェクトのフォーラムからの3224992の投稿で、総容量は約700 Mbです。
データのインデックス作成。 データは5000ファイルのバッチでダウンロードされ、utf-8に変換され、インデックス付けされました。
- 第1の実施形態では、コマンドライン - ほぼ分〜6時間。
-2番目のオプション-ファイルは個別にサーバーに供給されました-約10.5時間。
ゆっくり？ はい カメ - スフィンクスと比較すると。 ただし、インデックスの最初の入力では、時間が許容されます。 そして、多くの、私たちはこのような量のプロジェクトを持っている場合は？ しかし、新しい文書とインデックスの速度の現在の補充のために十分以上です。 LiveJournalのデータはLiveinternet.ruのメインページで見つかりませんでした現時点（11：47、01 / 03/2011）の日記によると、「過去1時間に4518件の投稿」と言われています。第二の実施形態（毎秒85点の位置）に記載の方法。 この検索エンジンはLiRuには適していませんが、同様のトラフィックを持つサイトはたくさんありますか？
ディスクリソース：
-最初のオプションで取得したインデックスは、ディスク上で約5.3 Gbかかります。
-2番目のオプションで取得されるインデックスは約6.3 Gbです。
なぜそう-理解しませんでした。 おそらくこれは、サーバーが複数のインデックスで同時に動作する可能性に何らかの形で依存しているため、内部名は「ノード」（ノード）です。
検索速度。
残念ながら、この問題について私が収集し、多かれ少なかれ詳細な統計は、これまでに失敗しました。 私が手配していなかった大規模な爆撃を要求。 主観的な感情を共有できます：
1.新しく構築されたインデックスの最初のクエリは、かなり長い時間（約1秒半）処理されました。
2.同じリクエストの繰り返し、および指定されたリクエストのページ間の移動-100分の1秒以内。
3.冗長な要求が長く処理されます。 たとえば、5ワードのリクエスト（最後のスパムメーリングの残りを探す）は、ページングに約0.17秒も費やしていました。
すべてのお問い合わせは、私は、Webインタフェース検索エンジンサーバを経由して作られました。
結論
- この検索エンジンのパワーは、大規模なメディア、LiveJournalレベルのブログなどを除いて、ほとんどのサイトで十分です。
- インストール、設定、およびそれらの作業は非常に簡単であり、高いスキルと個人を必要としません。
- 実際、Hyper Estraierを使用すると、テキストを描画できるドキュメントにインデックスを付けることができます。 他の形式の一部のパーサープログラムへのリンクは、ドキュメントに記載されています。 また、インデックスのWebページに独自のクローラ利用できます。
1日あたり1万から2万の投稿/コメントのトラフィックがあるフォーラムのグループで実行します。
PS。 私はすべての可能性のHyper Estraierに考えられてきました。 正しく理解すれば、複数のインデックスノードを同時に検索したり、マルチマシンバージョンの作品を検索したりできます。 そのため、エンジンの実際の「出力」は、私が達成できるものよりも大幅に高くなる可能性があります。 テストpomuchat仕事へのファンのために残った:)