機能について
これらの30の機能のほとんどがかなり楽しいものであることは明らかです。 まあ、何らかの理由でサーバー上で急激にジャンプした状況でログを再生する機能、すべてのクラスターに広がるスニペットのサポート（各マシンにコピーされない）、256のテキストフィールド（32以外）のサポートなどを含む新しいフラグがあります.p。 しかし、ここでも、一般に比較的大きく重要であると考えるいくつかの部分があります。
MVA64属性の添付サポート。 「クラシック」MVAは多くの32ビット符号なし値であり、新しいMVA64はそれぞれ64ビット符号付き値です。 2つの明白なアプリケーションを思い出すことができます。a）CRC32がMVAの行から保存された場合、衝突の可能性を排除します。b）そこにあらゆる種類の追加データを保存します。 MVA64は、ディスクインデックスとRTインデックスの両方でサポートされています。
ところで、 MVA属性は index_exact_wordsと同様にRTインデックスでもサポートされるようになりました。 一般に、これまでRTになかったすべての機会を少しずつ行っています。
RTインデックスでdict =キーワードをサポートしました 。 これは、 現在RTインデックスでは、キーワードの先頭（単語*）による検索があることを意味します。 ディスクインデックスに存在するmin_prefix_len、min_infix_lenディレクティブは、可能なすべての部分文字列に事前にインデックスを付けていたため、具体的にはしないことを決定しました：これはどこでもインデックス付けの強いヒットですが、ディスクインデックスの場合、（比較的大きな）ディスク、およびRTの場合にもヒットします、常に欠けている貴重な記憶。 部分文字列を見つけるためのディスク要件を時々膨らませた場合、どういうわけか同意しましたが、メモリ要件はありません。 さて、dict = keywordの出現により、部分文字列の検索が可能になり、メモリはそのままになります。
別の興味深い新しいものはATTACH INDEXです。 データがいっぱいのディスクインデックスを取得し、新しい空のRTインデックスを決定し、ディスクをRTに変換できるようになりました。 その後、ディスクインデックスからのデータは消えますが、RTに表示され、通常どおり、そのRTで安全に作業できます。 大量のデータの迅速な初期インポートや、突然（pah-pah-pah）何かが起こった場合の迅速なRTリカバリには、非常に便利です。ほんの数個です。 物理的には、操作はファイルの名前を変更するだけなので、非常に高速です。 実際、現時点で実装されている機能（1回限りの変換）は、CONVERTを呼び出す方が適切です。 しかし、このことをさらに発展させ、このような空でないRTインデックスにビッグデータシャタムをインポートできるようにする予定です。 したがって、彼らは将来のために、すぐにATTACHキーワードを獲得しました。
UPDATEステートメントはWHEREでより完全な条件をサポートするようになりました 。 これで、UPDATE myindex SET deleted = 0 WHERE MATCH（ 'test'）などのクエリを作成することができます。 それら。 条件によって千のレコードを叩くことは、千倍簡単になりました。 IDによる列値の以前の更新と同様に、この新しいUPDATEも通常のインデックスとディスクインデックスの両方で機能します。
そして最後に、リストの最後の「大きな」機能は、 関連性を計算するための独自の数式を作成し、その場で設定する機能です（ 式ベースのランカー ） 。 以前のバージョンでは、WEIGHT（）を介して利用できる関連性を計算するためのオプションは、いくつかの以前に記述されたランカー（PROXIMITY_BM25、SPH04など）からの選択に本質的に要約されていました。 その後、WEIGHT（）を式に入れてドキュメントの他の属性に混ぜることは可能でしたが、WEIGHT（）自体の計算に影響を与え、そうでなければドキュメント全体ではなく個々のフィールドに対して計算されたあらゆる種類のランキング要因を組み合わせることができました不可能でした。 そして、多くの要因はありませんでした。
できるようになりました。 ランキング式は、少なくとも個々のリクエストごとに設定できます。 さらに、利用可能なランキング要素が大幅に大きくなりました。 新しい「スクリプト可能な」ランク付け機能を備えたすべてのランク付け機能が正常にエミュレートされます。 ドキュメントには例がありますが、ここに例を示します。
$client->SetRankingMode(SPH_RANK_EXPR, "sum(lcs*user_weight)*1000+bm25");
驚いたことに、予想よりずっと速く動作します。 実際、1,000,000のブログ投稿の小規模なテストコレクションで、数倍のスローダウンが予想されていましたが、1.1倍から1.3倍のスローダウンが見られます-これは、コンパイルされたC ++コードと比較されます。 かなりいいと思います。
開発計画について
2.0.xブランチは現在フリーズされており、そこには新機能はありません。バグ修正と、これらのバグ修正自体を含む通常のリリースのみです。 最も近いものは、1か月後に指定され、その後、1〜2か月の間隔で（十分な修正が蓄積される場合）、または蓄積されるたびに再度指定されます。
ここからのすべての新機能はトランクに追加され、次のバージョンは2.1.1です。 彼にとって、リリース日はまだ計画されていません。 しかし、多くの機能が既に活発に開発されているので、今からいじることができます。 dict =キーワードを使用して、単語の先頭（word *）だけでなく、部分文字列（* word *）の検索を既に実行しています。 おそらく（おそらく）、同じケースのワイルドカードもサポートします。 多数のエージェントを含むクラスターの興味深い改善に取り組んでおり、リクエストがそれらに並行して送信されるようになりました（現在、これはまだシリアル化されています）。 さらに、有名なライブラリをねじ込み、ロシアの形態のサポートを改善するという秘密の作業が進行中です。
リリースについて
機能に加え、機能に加えて、リリースのテスト、アセンブル、ロールアウトの内部プロセスを再び揺るがしました。 彼らは触れたようですので、次のバージョン2.0.3リリースは「準備ができたら」いつものようにダウンロードされません-しかし、1か月後、2011年12月中旬に電話で。上司がこのタグのないバージョンを断固として注文しない場合は、こちら彼は一ヶ月になります。
また、現在のタグが実際にはベータ版ではなく、rcであることも彼に伝えることができます。 つまり、リリース時点では、2.0.2-betaには重大で重大なバグは報告されていません。 従来のテスト機能については、「検索のみ」の場合、従来よりもそれぞれ安定している必要があります。 したがって、原則として、リリース候補と呼ばれる可能性がありますが、タグのセットを複雑にしないことにしました。
再びいくつかの新機能を追加しました。この場合、リリースタグは、内部テストに加えて、コミュニティの生きている人々によってバージョンがテストされるまで遅延されます。 そのため、新しいバージョンを試してみてください 。突然何かに遭遇した場合は、バグについて必ずご連絡ください 。
会議について
新しいものすべて、古いものの正しい使用についての詳細、そして近い将来、他の多くのものがまれなブログ投稿で読めるだけでなく、 ユーザー会議でライブで聞くことができることを願っています 。 まだ無料です（私は初めて何も教えませんでした!!!）が、モスクワではなく、 サンクトペテルブルク、12月4日（日 ）に変更を行います。 読者にできるだけ早く登録するように要求し、作家が内気にならないように要求し、レポートや稲妻についての提案を送ってください。
皆さん、こんにちは、新しいリリース、そしてできればカンファレンスでのライブミーティングに。