ここで述べたように、 Sphinx 2.0.1は最近リリースされました。 おそらく急いでリリースされました。 「完全に予想外に」（ほぼセッションまたは新年のように）、さらに、 初心者向けの本が出版され、新しいバージョンだけが説明されました。 「トランクについて」という本はまだ風変わりですので、すぐにバージョンを公開しなければなりませんでした。 1、2か月間、リリースの準備をしていたのは良いことです。バグを修正し、機能をあまり壊しませんでした。 ノートでは、最新バージョン2.0.1のあらゆる種類の革新と次のバージョンの計画について説明します。タックルを参照してください。

新機能

37個の新機能の中で最も注目に値する5つ（私の意見）は、このようになりました。

• インデックス作成中の文と段落の境界の検出;検索中のSENTENCE、PARAGRAPH演算子;
• インデックス作成中のドキュメント内の階層（！）ゾーンのサポート、検索時のZONE演算子。
• 部分文字列を検索する機能により、インデックス作成を大幅に高速化する新しいタイプの辞書（インデックス作成は5〜10倍速く、インデックスは小さくなります）。
• 文字列属性のサポートの改善：ORDER BY、GROUP BY、照合。
• 改善されたSphinxQL構文：魔法を取り除き、SQL'92に進みます。

文と段落の索引付けについて（index_sp = 1、SENTENCE、PARAGRAPH）

対応するテキスト単位に制限がある検索に必要：（mom SENTENCE soap SENTENCEフレーム）、（叔父PARAGRAPH dead）。 クエリ言語にいくつかの演算子が追加されました。 演算子の引数（SENTENCE、PARAGRAPHの左右）は、次の3つのいずれかです。単純なキーワード。 フレーズ（「風と共に去りぬ」文循環）; またはオペレーター自身（mom SENTENCE soap SENTENCEフレーム）。



技術的な理由から、任意の部分式をそこに置くのはかなり重要です。 クエリマッチャーの構造に興味がある人のために：クエリ計算ツリーのこれらの演算子は、サブツリーからキーワードのストリームを受け取り、このストリームをフィルタリングします。 したがって、1つの文または段落の出現をフィルタリングした後、一般的な場合、フィルタリングされた出現がまだ一致するかどうかを自信を持って言うことはできません。 何らかの方法で再度確認する必要がありますが、これは技術的に非常に困難です（突然誰かが作業パッチを送信し、すぐに給料を希望する場合）。 したがって、エントリがアトミックである必要があります（一致するかまったく存在しないか、フィルターが削除されます）。 そのため、単語またはフレーズのいずれかです。



文と段落の境界を区別するには、インデックスを作成するときに、それらを検出してインデックスに保存する必要があります。 このため、ディレクティブindex_sp = 1が付加されます。



段落の境界は、コードで規定されているブロック（ブロックレベル）HTMLタグの数と見なされます。 したがって、段落にインデックスを付けるには、HTMLストリッパー（html_strip = 1）、tkも有効にする必要があります。 HTMLはそこで処理されます。



文の境界はテキストに基づいて検出されます;それらの場合、ストリッパーはオプションです。 国境は常に疑問点と感嘆符と見なされますが、いくつかの例外はあります。 例外は、USAまたはそこにあるGoldman Sachs Srlなどの略語、John D. Doeなどの名前などによって処理されます。 もちろん、間違っているかもしれません。フィードバックを蓄積するにつれて、あらゆる種類の例外を追加します。 しかし、全体として、テストはうまく機能しました。

ゾーンのインデックス付けについて

人々は、ある種の内部構造を持つ文書の中にテキストを入れようとしますが、これはフィールドの単純な固定リストに収まりません。 典型的な例は単なる本です。章、セクション、サブセクション、アプリケーション、脚注などです。



そのため、2.0.1以降、このような任意の構造のサポートが（通常のフィールド内で）登場しました。 これはindex_zonesディレクティブに含まれており、HTMLストリッパーも使用するため、有効にする必要もあります。 ドキュメントのインデックスを作成するとき、選択したタグでマークされたすべてのゾーンの境界が保存されます。たとえば、各h1の開始と終了、または付録があります。 それぞれ検索する場合、検索をゾーンに制限できます：（ZONE：h1 hello world）。



ゾーンは任意の数にすることができます。 ゾーンは互いに任意にネストできます。 タグの長さのみが制限されており、約120バイトです。 行内のすべてのタグにインデックスが付けられるわけではありませんが、ディレクティブで明示的にのみ指定されます。 正確なタグまたはプレフィックスマスクのいずれかを指定できます。index_zones= h *、chapter、section、appendix。 演算子を検索するとき、フィールドに似たいくつかのゾーンを指定できます：（ZONE：（h1、appendix）hello world）。 これらの名前に制限はありません。 これらのゾーンでHTMLにインデックスを付けることができます。XMLにすることもできます。 XML要件とは異なり、ゾーンを重複させることは技術的には問題ありません（1つ2つ3つ4つ5つ6つ）。 ただし、各オープンゾーンを閉じることは明確に必要です。

新しい辞書について

開発の10年目に、ついに（ドラムロール）...キーワード自体が保存される辞書を台無しにしました。 以前は、ハッシュのみが保存されていました。 実際、検索には、単語自体はまだ必要ありません。ハッシュの置換はうまく機能します。 ただし、古いタイプの辞書（dict = crc）では、部分文字列を検索するために、これらすべての部分文字列に事前にインデックスを付ける必要がありました（ハッシュによる部分文字列の検索は面倒なので）。 ところで、可能性のあるすべての部分文字列のこのような事前インデックス付けは、検索時に可能な限り迅速に機能します。 ただし、インデックス作成時間とインデックスのサイズは大きく低下し、「通常の」インデックス作成よりも最大5〜10倍遅くなり、それに応じてインデックスが膨らみます。 インデックスが1〜3 GBの小さなインデックスの場合（世界のすべてのトレントよりも少し少ないインデックスを作成するには十分だと思われます）、これはまだ耐えられます。 100 GB以上のインデックスの場合、テキストはもうありません。 そのため、特定のクライアントとのネゴシエーションでは、このようなコレクションでは部分文字列の検索がほとんど必要ないことが判明しました。 さて、どこへ行くか、新しい辞書を添付しました。



インデックス設定のdict = keywordディレクティブに含まれています。 通常の（！）インデックス作成と比較すると、約1.3倍遅くなります（内部テストYMMVでは、これらすべてのこと）。 したがって、接頭辞またはさらに悪い場合は挿入記号を使用したインデックス作成と比較して、3倍以上の速さで飛行し、スペースを節約します。



ちなみに、明らかな理由により、デフォルトでメモリに完全にキャッシュされる辞書（.spiファイル）はかなり少なくなります。 したがって、メモリの消費も少なくなります。



インデックス作成速度のこのような地獄のような加速とディスク/メモリの節約のためには、もちろん、何かを支払わなければなりません。 理論的には、検索速度が低下するはずです。 これは、dict =キーワードを使用すると、アスタリスク付きの各キーワードが、指定されたマスクを使用して辞書内で見つかったすべての単語の大きく太いORに自動的に展開されるためです。 要求はより複雑であり、プロセッサとディスクの時間がより多く消費されます。 Vasyaマスクが一致する単語が多いほど、Vasyaの検索が長くなります。 ただし、実際には、新しい辞書がより速く出てくることが判明する場合があります。 これは、古いインデックスが間違いなくメモリに配置されておらず、すべての人がゆっくりとiowaitに座ってディスクを読み取り、ヘッドがガタガタ音を立て、キャッシュをマージしてから、syscall outhouseを終了し、新しいインデックスが配置される（または少なくともキャッシュの方がはるかに優れています）、新しい「低速」メモリリクエストは、古い「高速」ディスクリクエストよりも高速です。 10回は1回10回というよりも1回良い！



ちなみに、拡張の程度は、個別の新しい設定expansion_limitによって制御されます。 デフォルトでは、現在は0です。 制限はありません。 A *のようなリクエストを100万語のORmsに置き換えず、デーモンを殺して死にたくない場合は、妥当なexpansion_limitを設定することをお勧めします。 拡張に制限がある場合、最も一般的な単語の上位Nが使用されます。

文字列属性について

すでに線があり、それらとはほとんど関係ありませんでした。 文字列属性にORDER BYおよびGROUP BYのサポートを追加しました。 （WHEREを添付することは残っていますが、単語検索がある場合、これは最も緊急の必要性ではありません。）SphinxAPIによるソートとグループ化も機能します。



文字列は数字ではなく、言語や大文字と小文字の区別の要件に応じて異なるため、 照合順序を添付する必要がありました。 指では、異なる文字列比較関数。 一連の照合を手動で実装するため、率直で怠zyで、紳士の最小限のセットを作成します：binary、utf8_general_ci、libc_ci、libc_cs。 最初の2つは、文字列をバイト単位で、またはUTF-8の「一般的な」（大文字と小文字を区別しない）規則に従って比較します。 2番目の2つは、libcとロケールを皮肉的に使用します。 ちなみに、デーモンの起動時にLOCALE = ru_RU.utf-8が1xで機能せず、すぐに使用できるロケールが2xで特にインストールされないことが多いことに驚いた。 さて、 collat​​ion_libc_localeディレクティブをアタッチして、デーモンの起動時にロケールを選択し、locale -aコマンドと他のあいまいなapt-get、yumを調べる必要がありました。

SphinxQLについて

以前のバージョンでは、SphinxQLは本質的に「古い」検索エンジンの上にある非常に軽量なラッパーであり、SphinxAPIからアクセスできました。 これにより、すべての種類の残留現象が存在しました。列id、重みは必ず結果セットに追加されました。 グループ化マジックカラムが追加されたとき@group、 count ; SELECTで明示的に要求された属性の順序に違反する可能性があります（クエリの属性はインデックスの属性に置き換えられました）。



このような現象は、SQL'92標準および常識と矛盾するため、クリーンにすることが決定されました。 要求は同じままですが、応答は異なります。追加のマジックカラムは追加されず、すべての種類のWEIGHT（）およびCOUNT（*）を明示的に要求する必要があります。 また、属性の順序は要求どおりに返され、インデックスの構築時にインデクサーによって選択されません。



しかし！ 突然（tm）動作を変更したり、既存のアプリケーションを破壊したりすることはできません。アプリケーションを更新する（そして突然すべてを変更して破壊する）機会を与える必要があります。 これにより、デフォルトで1（魔法の列で「古い方法で」応答を与える）である神秘的な指令compat_sphinxql_magicsが登場しましたが、明るい未来では常に0になるはずです（ANSI SQLが遺贈するように「新しい方法で」応答を与える）。



デーモンは、起動時に自身のデフォルト値に関する警告を宣誓します。 これは、進歩と歩調を合わせる必要性を象徴しており、そのために考えられています。



変更のリスト（非常に小さい）は、 SphinxQLの更新に関する特別なセクションのドキュメントにあります。原則として、すべてが非常に直感的である必要があります。 したがって、私たちの目標は古き良きSQLです。 SELECT * FROM ...が以前に記述されたところで、今度はSELECT *、WEIGHT（） `weight` FROM ...を記述しました。以前はGROUP BYのみを記述していましたが、COUNT（*）myaliasを明示的に記述し、アプリケーションを更新してmyalias列に移動しますなど

新しいパッケージ

手でコンパイルするのは退屈なので、さまざまなプラットフォーム用の公式バイナリパッケージを収集することを徐々に学習しています。 リリース2.0.1は、RH / Centos、Win32、MacOSで既にコンパイルされています。 計画とテスト（今後1〜2週間になることを望みます）には、まだUbuntu、Win64のパッケージがあります。 さらに、ファンタジーは失敗し、公式バイナリが必要な調査を実施する必要があります。

あらゆる種類の異なる新機能

「ヨーロッパを駆け抜ける」形式で、他の多くの興味深い可能性のある作品を調べます。



サーバー上にある大きなドキュメントからすばやくスニペットを構築する必要がある場合のために、スニペットのパッケージのマルチスレッドおよび分散構築を行いました。 これは、サーバー上のdist_threads、スニペットのリクエスト内のload_filesの存在に含まれており、これまでのところAPIを介してのみ機能します。



UDFをサポートしました。 Cで関数を記述し、その場でサーバーに接続し、式リーダーで使用できます（SELECTを参照）。 型システムは異なりますが、インターフェイスはMySQLに非常に似ています。 SphinxでMySQL UDFを再構築するのは非常に簡単な作業です。



新しいログ形式query_log_format = sphinxqlを作成しました。 すべての検索クエリ（APIとQLの両方）は、正しいSphinxQL構文に変換され、記述、記述されます。 通常のログとは異なり、フィルター、SELECT式、エラーなどを記録します。 デバッグとプロファイリングに便利です。 すべての非検索クエリ（スニペットなど）のロギングも完了します。



blend_modeディレクティブを作成して、ブレンドされた文字が含まれるシーケンスにいくつかの異なる方法でインデックスが付けられるようにしました。 （たとえば、「単語」@ sphinxsearch＃について、@ sphinxsearchの3つのバリアントすべて、sphinxsearch＃、@ sphinxsearch＃のインデックスを作成し、最後のものだけではありません。）



彼らは、スレッドを使用するモードで、悪魔が髪の毛で自分自身を持ち上げるように、ウォッチドッグを作成しました。 無効にすることができます。



id32インデックスのid64デーモンへのロードをサポートしました。 ここで準備して、常に--enable-id64を強制的に有効にします。



SphinxQLでは、複数クエリ、属性の更新、DESCRIBE、SHOW TABLES、DELETE ... WHERE id IN（...）、およびあらゆる種類のすてきなことをサポートしました。



形態= stem_enインデクセーションを1.3倍加速して、英語のステマーを数回最適化しました。



大きくて厚いファイルのスニペットを最適化し、ステマーとともに1.5倍、さらに2倍高速になりました。



もちろん、バグはアカウントなしで修正されました。

2.0.2で何を（いつ）待つか

年に一度リリースをリリースする悪意のある傾向と、トランクに住む残りの時間を逆転させたいと思います。 したがって、私たちはこの夏にフリップバカと詩人のバグ修正と小さな新機能を備えた2.0.2をリリースする予定です。 自動テストがあり、あらゆる種類のプラットフォームに対して自動アセンブリを行います。 今では、他の誰かが自動的にドキュメントを作成し、それから非常に簡単になります。



常に存在する「バグと速度」タスク（バグの導入と速度の除去）に加えて、RTの多くの機能（部分文字列、MVA、その他の検索のサポート）、検索の品質に関する秘密の作業などの短期計画があります。 。 「マイナー」の改善。 ちなみに、これはスムーズに失敗します。

耳の中で叫ぶ方法

Sphinxの機能は、通常4つの異なる方法で表示されます。 第一に、時々彼らは汚れた服と一握りの小麦から生まれますが、これは最近の数世紀では非常にまれです（エーテルとフロギストンの廃止後）。 第二に、時々私たちは座って考えます：しかし、私たちはそのような機能を作るべきですか？ もちろん、そうではありません。 私たちはより良く考え、何か他のことをします。 第三に、時々クライアントから来て、「機能が本当に欲しい、お金を払う準備ができている」と言われることがあります。 常にクライアントや説得力に打ち勝つことができるとは限らないため、固定する必要があります。 B-4x、時にはユーザーが取り込んで書く：まだ機能を実行していない理由。 まだ機能をまだ実行していない理由は本当ですか？ 私たちは座って、考えて、煙を吐きます。もちろん、私たちはそうしません。 しかし、私たちは計画通りに進み、それを後で行います！



ここで、表示する必要のある機能を得るために、これについてさらに、大声で、はっきりと、定期的に話す必要があります。 これには、バグトラッカーを2回使用できます。 まず、新しい機能のリクエストをそこに置く必要があります。 次に、既存のリクエストをサブスクライブする必要があります（バグの監視）。 バグトラッカーのメインページには、監視されていない上位のバグの目立たないリストがあります。 機能の重要性を判断するための別の優れた自動化された方法はないため、ここで確認します。したがって、バグ追跡システムの機能に「投票」するようお願いします。

合計

多くの機能を実行し、 2.0.1-betaをリリースしました 。 同時に、私たちは彼について初心者向けの本を書き、上級者向けの次の本について考えています。 最悪の敵（私たち自身）を倒し、次のリリースで多くのことをしたいのですが、すぐに変更します。 あらゆる方法で私たちを助けることができます 。 従来、 フィードバックやバグの特徴的なシャフトが見つかることを非常に期待しています 。



そのようなこと。