coreseek/sphinxドキュメントの概要

1.これらは、charset_typeおよびcharset_tableのオプションでインデックスごとに個別に構成することができる.charset_typeは、文書の符号化がシングルバイト(SBCS)であるかUTF−8であるかを指定する.Coreseekでcharset_を通過するとdictpathは中国語辞書を設定して中国語分詞モードを起動した後、UTF-8で符号化できるだけでなく、GBKおよびBIG 5の符号化も使用できる(コンパイルが必要な場合はiconvサポートを提供する).しかし、内部実装では、UTF-8符号化に予め変換する処理を行っている.charset_tableは、アルファベットクラス文字からそれらの大文字と小文字の変換バージョンへの対応するテーブルを指定し、このテーブルに現れない文字は非アルファベットクラス文字とみなされ、インデックスの作成と検索時に作詞の分割子として扱われる.
Coreseekでは、中国語の分詞を有効にすると、MMSegに内蔵されたコードテーブル(MMSegのプログラムにハードコーディングされた)が使用されるため、charset_tableは分詞を有効にすると失効します.
2.PHP APIは、履歴上、結果セットの行を文書ID順にhashするため、PHP APIでMVA属性のパケット化操作を行う際にSetArrayResult()を使用する必要がある.
3.外部記憶方式を採用する場合、searchdは常にRAM内に.spaファイルのコピーを保持する(このファイルはすべてのドキュメントのすべてのドキュメント情報を含む).これは、ディスクへのランダムアクセスが遅すぎるため、パフォーマンスを向上させるためです.逆に、インラインストレージには追加のRAMは必要ありませんが、インデックスファイルのボリュームが大幅に増加します.すべての属性値は、ドキュメントIDが表示される各箇所でコピーされ、ドキュメントIDが表示される回数は、ドキュメント内の異なるキーワードの数であることに注意してください.インラインストレージは、小さなプロパティセット、膨大なテキストデータセット、および制限されたRAMがある場合にのみ考慮可能である.ほとんどの場合、外部ストレージはインデックスの作成と取得の効率を大幅に向上させることができます.
検索時に外部記憶方式で生成されるメモリ要件は(1+属性総数)*文書総数*4バイトであり,つまり,2つの属性と1つのタイムスタンプを持つ1千万件の文書では(1+2+1)*10 M*4=160 MBのRAMが消費される.これは、検索ごとのデーモンプロセス(PER DAEMON)が消費する量であり、クエリーごとではなく、searchdが起動時に160 MBのメモリを割り当て、データを読み込み、異なるクエリー間でデータを保持するだけである.サブプロセスは、これらのデータを追加的にコピーしません.
4.
SQLベースのすべてのドライバについて、インデックスを作成する手順は次のとおりです.
データベースに接続する;
事前クエリー(セクション11.1.11「sql_query_pre:インデックスデータ取得前のクエリー」を参照)を実行して、MySQL接続のエンコードなど、必要な初期設定をすべて完了します.
メインクエリーを実行します(セクション11.1.12「sql_query:インデックス対象データクエリーの取得」を参照).返されるデータはインデックスされます.
必要なすべてのクリーンアップを完了するために、ポスト・クエリー(セクション11.1.30「sql_query_post:データ取得後クエリー」を参照)を実行します.
データベースへの接続を閉じます.
フレーズをソートする(または、インデックスタイプに関連する後処理を学究する).
データベースへの接続を再確立します.
インデックス後クエリーを実行します(セクション11.1.31「sql_query_post_index:データインデックス後クエリー」を参照).最終的なすべてのクリーンアップの後続作業を完了します.
データベースへの接続を再度閉じる.
5.
インデックス・システムでは、プライマリ・クエリーによってすべてのドキュメント情報を取得する必要があります.単純な実装では、テーブル全体のデータをメモリに読み込むことですが、テーブル全体がロックされ、他の操作がブロックされる可能性があります(例えば、MyISAM形式のINSERT操作)、クエリー結果を格納するために多くのメモリが浪費されるなどの問題があるでしょう.これを回避するために、CoreSeek/Sphinxはセグメントクエリと呼ばれる技術をサポートする.まず、CoreSeek/Sphinxは、データベースからドキュメントIDの最小値と最大値を取り出し、最大値と最小値で定義された自然数区間をいくつかに分け、一度にデータを取得し、インデックスを作成します.次に例を示します.
例3.1.範囲クエリーの使用例

# in sphinx.conf

sql_query_range	= SELECT MIN(id),MAX(id) FROM documents
sql_range_step = 1000
sql_query = SELECT * FROM documents WHERE id>=$start AND id<=$end

このテーブル(documents)において、フィールドIDの最小値と最大値がそれぞれ1と2345である場合、sql_queryは3回実行されます.$startを1に置換し、 $endを1000に置換する. $startを1001に置換し、 $endを2000に置換する. $startを2001に置換、 $endを2345に置換.
これは、2000行のみのテーブルでは、パーティション・クエリーが読み込み全体とあまり変わらないことは明らかですが、テーブルの規模が千万レベル(特にMyISAM形式のテーブル)に拡大すると、パーティション・セグメント・クエリーが役立ちます.6.既存の2つのインデックスをマージすると、すべてのデータを再インデックスするよりも効率的になります.また、このようにする必要がある場合があります(たとえば、プライマリ・インデックス+インクリメンタル・インデックス・パーティション・モードでは、プライマリ・インデックスとインクリメンタル・インデックスを単純に再インデックスするのではなく、プライマリ・インデックスに対応するデータをマージする必要があります).
基本的なコマンド構文は次のとおりです.

indexer --merge DSTINDEX SRCINDEX [--rotate]

SRCINDEXのコンテンツはDSTINDEXに統合されるため、DSTINDEXインデックスのみが変更されます.DSTINDEXがすでにsearchdによってサービスを提供している場合、--rotateパラメータは必須である.当初設計された使用パターンは,少量の更新をSRCINDEXからDSTINDEXに統合することであった.したがって、属性がマージされると、重複するドキュメントIDが表示されると、SRCINDEXの属性値が優先されます(DSTINDEXの値は上書きされます).ただし、「古い」キーワードはこの過程で自動的に削除されないことに注意してください.例えば、DSTINDEXには「old」というキーワードが文書123に関連付けられているのに対し、SRCINDEXには同じ文書にキーワード「new」が関連付けられているので、マージ後に両方のキーワードで文書123を見つけることができる.ドキュメントをDSTINDEXから削除するための明示的な条件を指定できます.この場合、関連するスイッチは--merge-dst-rangeです.

indexer --merge main delta --merge-dst-range deleted 0 0

このスイッチを使用すると、マージ中にターゲットインデックスをフィルタできます.フィルタは、すべてのフィルタ条件を満たすドキュメントのみが最終的なマージ後のインデックスに表示される複数あります.上記の例では、フィルタは「deleted」が0の条件のみを通過させ、削除された(「deleted」)とマークされたすべてのレコードを除去する(UpdateAttributes()を呼び出してドキュメントのプロパティを設定することができる).
7..RTリアルタイムインデックス定義

index rt
{
	type = rt
	path = /usr/local/sphinx/data/rt
	rt_field = title
	rt_field = content
	rt_attr_uint = gid
}

RTインデックスは現在も開発が続いている(バージョン1.10-betaから).そのため、接頭辞/接頭辞インデックス、MVAプロパティなど、特定の機能が欠けている可能性があります.しかし、従来のインデックス機能と検索機能はすべて実装され、内部テストが行われています.実際の運用環境(最も重要でない部分ではない)にはRTインデックスが使用されており、より良い効果が得られています.8.