主なものから始めましょう、計画された主要な変更の短いリスト：
- 新しいFTインデックス形式：インデックス作成の高速化、検索の高速化、サイズの縮小。
- 新しい属性形式：さようなら、すべての愚かな歴史的制限。
- スレッドへの完全な移行：さようなら、workersディレクティブ、hello、スレッドプール。
- RTインデックスへの完全な移行：インデクサーは残りますが、タイプディレクティブはあまりありません。
- RTインデックスのオンライン複製：地獄の手動クラスターを徐々に自動クラスターに置き換えます。
- 元のドキュメントの保存：さようなら、補助インデックスの概念、こんにちは世界、今私たちはベースのようなものです。
- ネイティブ属性インデックス：キーワードを使用したエミュレーションは何らかの形で機能しますが、インデックスを使用することは可能です。
- RESTインターフェース：ボットのAPI、それ自体のSQL、人々のREST。
もちろん、2つの大きな内部変更は、すべての側面（フルテキスト部分と属性部分の両方）からの新しいインデックス形式に加えて、厳密にスレッド化された作業モデルと厳密にRTインデックスへの強制移行です。 なぜこれがすべてなのか？
2001年以来、古いFTインデックス形式は概念的に拡張されており、考えるのは怖いです。 もちろん、その中で、いくつかの変更と最適化が定期的に行われたわけではないため、老人はまだ鮮明でした。 ただし、2001年以降、ここには根本的な概念的な変更はありませんでした。 外部docidのvarintエンコードされたデルタの束を保持していたので、それを保存します。 さらに、かなり低レベルのブリックであるため、インデックス形式はデータストレージ自体に影響するだけでなく、内部アーキテクチャの多くの部分にも影響を及ぼします。それらは外部に流れます。要件は、外部DocIDの提供、ドキュメントの重複による頭痛、奇妙な瞬間パフォーマンス、それだけです。
今日、私たちはより良いことができます。
新しい形式では、「魔法の」外部の一意の属性DocIDはなく、ドキュメントの内部番号付けは外部から解放されます。 この1つの変更により、多くのことが可能になります。突然、インデックスに重複したIDを入力することも、数値IDをまったく必要としないこともできます。 突然、必要に応じて、インデックスドキュメントのサブセットに対して、大量のIDリストではなくコンパクトなビットマスクを作成できます。 突然、PFD、Group Varintなどのあらゆる種類のグループコーデックを使用して、実際にフルテキストインデックスデータをはるかに効率的に圧縮できます。 突然、インデックス作成時に退屈な並べ替えの段階が不要になり、インデックスをほぼ増分で作成できます。 などなど。 インデックスは最大1.5倍小さくなり、2〜3倍高速に構築されます。理論的には、少なくとも個々のクエリで最大2〜3倍高速に検索することもできます。 すべての側面から利益を得る。
後者は、次の小さな革命を引き起こします。 新しいインクリメンタルインデックスアルゴリズム（大まかに言って、メモリ内の既存のアンダーインデックスに1エントリを「追加」）が、ディスクインデックスの現在の既存のバッチインデックスよりも2〜3倍高速であることが判明したため、ディスクインデックスとRTインデックスを区別する必要があるのはなぜですか？ 素晴らしい、ディスクインデックスでダウン、typeディレクティブでダウン。 これからは、すべてのインデックスをRTにでき、パフォーマンスを損なうことなく、むしろ加速しても、これを行う必要があります。 （内部では、もちろん、個々のインデックスセグメントを実装するためのディスク/ RAMベースのオプションがあります。ディスクとメモリはTTXでまだ異なっており、これを覚えることはできません。しかし、これは既に開発者にとって「効率的に行う方法」ですが、外部からは明らかな頭痛の種ですユーザーの機能の違いはありません。）
興味深いことに、インデクサーユーティリティは、原則として消えません。 データベースからデータをアップロードし、検索にロードするためのETLツールは依然として有用です。 ただし、以前はディスクインデックスを作成していましたが、現在はRTインデックスを作成します（デーモンへの直接読み込み、またはインデックス付けされたばかりのデータパケットを既存のインデックスに「接着」するため、これはポイントではありません）。
フルテキストパーツの形式は依然として大きく変化しているため、属性を格納する形式を変更する必要があると同時に、そのように歩きましょう（互換性を破る、そのように破る）!!! 現在、1つのドキュメントの可変長のすべての列（文字列、MVA、JSON、および将来追加される場合は他のトリッキーなタイプ）は1つの大きなBLOBに格納され、このBLOBへのポインターも格納されます。 （以前、各タイプには個別のファイルがあり、列には個別のポインターがありました。）同時に、愚かな青少年エラー「4 GBですべての人に十分なはずです」が解消され、さらにすべてを統一的に更新、削除などができます。 合計で、固定長の属性は以前と同じように保存され（内部番号への切り替えによるものであり、それらへのアクセスははるかに高速です）、可変長の属性はわずかに少ないメモリを消費します（一度に8バイト、各4バイトではなく）サイズに制限があります。 さらに、その他のマイナーな改善：たとえば、この形式では正直なNULLがサポートされるようになりました。 または、現在、キー圧縮はJSONデータ内で行われます。
RTに切り替えると、fork / preforkがさらに難しくなるだけでなく、不可能になります。 ただし、ここでは一度、これらの気の利いた妥協のない「迅速かつ優れた」ソリューションがあります：スレッドプール（2.3で既に利用可能）は、検索速度（可能な限り迅速に）の観点から可能な限り活発に動作し、並列処理の基本モデルは1つはマルチスレッドですが、マルチプロセスではありません（よく見ます）。 クラッシュが1つのスレッドのみに影響する場合も、一般的には理想的ですが、人生で理想的には起こりません。 したがって、クラッシュの痛みを軽減するために、開始時に必要なデータの大部分はmmap（）ですが、コピーされないため、大きなインデックスでも開始（および再起動）が非常に面倒になりました。
スレッドに加えて、RTを強制するため、レプリケーションは非常に必要になります。 少なくとも何らかの形でファイル形式で前後にコピーできるディスクインデックスの拒否を宣言すると、RTには少なくともいくつかのツールが必要であることを意味します。 もちろん、ホットバックアップ/復元を実行できますが、それは退屈です。 RTインデックスのオンライン複製は、はるかに興味深いものです。 ええ、そうです。 1つのマスター、N個の動的レプリカ、初期スナップショットの自動転送、着信変更の複製、マスターの再選択、これらすべて。 次のステップは、クラスターを構築および管理するためのあらゆる種類のツールですが、最初にレプリケーションを非常にうまく回復させます。
「フルテキストインデックスだけ」を複製し、元のドキュメントを保持するようにするのは小さく、定期的に尋ねるだけでなく、あらゆる種類の奇妙なものを含むブロブを保存できるようにするために必要なスニペットを高速化し、さらにdocidから分離されたインデックス形式を使用すると、すべてをスマートに実装できます まあ、私たちもdocstoreをやっています。 属性だけでなく、インデックス付きドキュメントのフィールド、および添付されたメタ情報のディスクストレージ（現在のところ、これはスニペットのドキュメントレベルのインデックスのみです）。 コードの小さなステップであり、機能に最適です。Sphinxでは、フルテキストインデックスを追加できるだけでなく、ベースとして完全に使用することもできます。 奇妙だが、ベース。
キーワードだけでなくデータベース内にインデックスを作成しておくと便利です。そのため、属性ごとにインデックスを管理する必要があります。 さて、これは、WHERE MATCH（ 'the who'）AND author = 1234が「インデックスから」実行されるため、WHERE MATCH（ 'the who'）AND gender = 'm'が「検索から」実行されますが、両方とも自動的にこれは最適に実行されたため、呼び出しPHPスクリプトでは、SQLオプティマイザーの類似物とWHERE MATCH（ 'the who _author1234'）などのクエリジェネレーターを実装する必要がありました。 キーワードのクラウドで属性をエミュレートするのは愚かなことです。もちろん、可能な場合でも受け入れられているように見えますが、既にそうしている場合はとても大きいです!!!
最後に、SQLは流行遅れであり、どこからでも呼び出すのは便利ではないため、HTTP / RESTアクセスを追加する必要があります。 非常に基本的な初期実装はすでに2.3にあり、そこから拡張および深化していきます。 面白くもなく、退屈ですらありません。
これらすべてにより、Sphinx 3.0は離陸を試みます。
もちろん、記載されているものの多くはまだ開発中であり、最初のアルファ版に含まれない場合があります。 ただし、一般的な計画はまさにそのようなものであり、さらに、この計画の半分以上が既に実施されているとしましょう。 作業はかなり良いですが、引き返すには遅すぎます!!!
大きなポイントごとに、多くの技術的な詳細を含む大きな記事を書くことができるのは明らかですが、どこかから始める必要があります。 だから、私は今後の変更の短いレビューをしようとしました。 今週の土曜日のスフィンクスガジェット （もちろんモスクワ）の会議で 、3日間で同じことをもう少し説明します。 スフィンクスのガジェットはすぐに100万件の明確な質問があり、それらすべてをコメントに書いて答えようとする方法はありません。 可能な限り、ここ（および/またはサイトのブログ）で、今後のメガフィットに関する記事をもっと書いていきます。
一般的に、Sphinx 3.0が来ており、多くの変更が来ています。面白いと思います。
結局のところ、全世界で全文検索用のライブラリが1つだけ存在することはできません。 :-)