blixt php
1.0.0
ユーザー、製品など、インデックス内のさまざまなタイプを表します。
インデックス全体に固有の単語の茎を表します。 （たとえば、実行されている単語のステム、ランナー、実行など）。逆のドキュメント頻度が計算され、単語に対して保存され、インデックスに対するスキーマのない検索を実行するために使用できるインデックス全体のIDFを提供します。
用語は、特定のスキーマ内の単語の存在を表します。つまり、「run」という語源「run」がユーザースキーマ内に表示され、製品スキーマにも表示される場合、その単語の2つの用語レコードがそのスキーマ内にあります。また、逆ドキュメントの頻度は、特定のスキーマに対して検索を可能にするスキーマ固有のIDFを提供するために用語に沿って保存されます（これらの検索は、単語のインデックス全体のIDF値の影響を受けません）。
列は、スキーマ内の利用可能なフィールドです。列は、それが表すデータがインデックス化されているかどうか、およびクエリの列の優先順位付けに使用できる重量であるかどうかについて、保存されているかどうかについてルールします（例：製品タイトルは説明よりも重量が多い場合があります）
ドキュメントはインデックス内の実際のエンティティを表します。これは実際にインデックスが付けられたアイテムであり、結果の基礎をクエリに形成します。
フィールドは、列に一致するドキュメントの属性です。列、ドキュメント、およびフィールドは、典型的なデータベースのように機能します。列はテーブル列のようなもので、ドキュメントは行やレコードのようなもので、フィールドはセルまたはエントリです。
発生は、ドキュメント内のフィールド内の用語（スキーマ固有の単語）の存在を表します。発生は、用語とフィールドのユニークな表現です。また、発生の代わりに、周波数も保存します。これは、フィールド内に用語が表示される回数を表します（検索時にスコアを計算するために使用されます）。
ポジションは、フィールド内の用語の実際の位置を表します。 「run」（またはその茎）という単語がフィールドに3回表示される場合、3つの位置レコードがあり、それぞれが対応するフィールド内のその発生の位置をマークします。
インデックスに「ユーザー」スキーマがあると想像してください。そのスキーマは、ユーザーインスタンス「名前」と「About」の2つの列を定義します。各列は保存およびインデックスの両方であり、どちらも1の重みです。インデックスに追加する2人のユーザーがあります[key：1、 "joe bloggs"、about "：" joe wike jane "]と[key：2、name：" jane doe "、about" jane loves to party "]。次の構造になります。
| id | 名前 |
|---|---|
| 1 | ユーザー |
| id | 名前 | 保存されています | インデックス付き | 重さ |
|---|---|---|---|---|
| 1 | 名前 | 1 | 1 | 1 |
| 2 | について | 1 | 1 | 1 |
| id | 言葉 |
|---|---|
| 1 | ジョー |
| 2 | blogg |
| 3 | のように |
| 4 | ジェーン |
| 5 | うーん |
| 6 | 愛 |
| 7 | に |
| 8 | パーティー |
| id | schema_id | word_id | document_count |
|---|---|---|---|
| 1 | 1 | 1 | 2 |
| 2 | 1 | 2 | 1 |
| 3 | 1 | 3 | 2 |
| 4 | 1 | 4 | 3 |
| 5 | 1 | 5 | 1 |
| 6 | 1 | 6 | 1 |
| 7 | 1 | 7 | 1 |
| 8 | 1 | 8 | 1 |
| id | schema_id | 鍵 |
|---|---|---|
| 1 | 1 | 1 |
| 2 | 1 | 2 |
| id | document_id | column_id | 価値 |
|---|---|---|---|
| 1 | 1 | 1 | Joe Bloggs |
| 2 | 1 | 2 | ジョーはジェーンが好きです |
| 3 | 2 | 1 | ジェーン・ドー |
| 4 | 2 | 2 | ジェーンはパーティーが好きです |
| id | field_id | Term_id | 頻度 |
|---|---|---|---|
| 1 | 1 | 1 | 1 |
| 2 | 1 | 2 | 1 |
| 3 | 2 | 1 | 1 |
| 4 | 2 | 3 | 1 |
| 5 | 2 | 4 | 1 |
| 6 | 3 | 4 | 1 |
| 7 | 3 | 5 | 1 |
| 8 | 4 | 4 | 1 |
| 9 | 4 | 3 | 1 |
| 10 | 4 | 7 | 1 |
| 11 | 4 | 8 | 1 |
| id | Occurrence_id | 位置 |
|---|---|---|
| 1 | 1 | 1 |
| 2 | 2 | 2 |
| 3 | 3 | 1 |
| 4 | 4 | 2 |
| 5 | 5 | 3 |
| 6 | 6 | 1 |
| 7 | 7 | 2 |
| 8 | 8 | 1 |
| 9 | 9 | 2 |
| 10 | 10 | 3 |
| 11 | 11 | 4 |
Blixtオブジェクトが作成されると、最初はすべての保存されたスキーマと列オブジェクトをメモリにロードします。これにより、BlixTはスキーマとそれに関連する列を迅速に検索して、インデックスリクエストを検証し、各列のis_indexedとis_stored制約をすばやく収集できます。
ドキュメントのインデックス作成が行われる前に、スキーマは列のセットで定義する必要があります。それぞれが、表現するフィールドを保存またはインデックス作成する必要があるかどうかを指定する独自のプロパティを備えています。スキーマが既に存在する場合、この部分はスキップできます。スキーマ定義が提供されておらず、そのようなスキーマが存在しない場合、例外がスローされます。
ドキュメントは、インデックス可能なドキュメントの形式で提供され、クライアントシステムが後で識別するために使用できるキーを指定します。インデックス可能なドキュメントには、一連のフィールドが含まれています。 Blixtがインデックス内の正しいスキーマにドキュメントを配置できるように、ドキュメントとともにスキーマ（またはタイプ）が提供されます。
Blixtは、最初にドキュメントの処理を開始し、そのスキーマの下にあるインデックスにまだ存在していないことを確認します。それが存在する場合、例外がスローされます。
Blixtはドキュメントレコードを追加し、ドキュメントのフィールドの処理を開始します。各フィールドはトークンに分割され（ほとんどの場合、トークンは単語です）、各トークンは茎になります（つまり、単語のルートを見つけます。たとえば、英語/ポーターのステムマーでは、「run」という単語は「実行中」、「ランナー」、「run」などです。
対応するレコードが既に存在しない場合、各トークンに単語レコードが追加され、それに応じてタームレコードがスキーマの下に作成されます。新しいドキュメントの追加を反映するために、「記録」という用語のドキュメントカウント合計が更新されます。
発生レコードは、一意の用語とフィールドの組み合わせごとに作成され、指定された用語が特定のフィールド内で発生することを示します。頻度（フィールド内でその用語が発生した回数）は、発生レコードと一緒に保存されます。位置データは、用語が発生したフィールド内の各位置を表す各発生レコードに対しても保存されます。
次のタイプのクエリがサポートされています。
~で直接a +で直接（または）除去します。このタイプのクエリは、他のすべてのクエリの基礎を形成します。検索は、検索フレーズを個別の単語（トークン化）に分割し、各単語をそのルート形式（ステム）に変えることから始まります。次に、インデックスが照会され、用語に一致する単語レコードを見つける。尋問している単語レコードとスキーマを使用して、用語レコードが抽出されます。 +演算子が添付されている検索用語のいずれかが用語レコードに存在しない場合、空の結果セットが返されます。
次に、クエリが実行され、クエリの条件（オペレーターに関係なく）を含むフィールドを見つけ、それらのフィールドに関連付けられたドキュメントが返されます（そのフィールド、発生、および位置はすべてそれに応じてロードされます）。次に、各ドキュメントが分析され、受け入れられるか拒否されます。ドキュメントに必要な用語（ + ）が含まれていない場合、または削除された用語（〜）が含まれている場合（ ~ ）、拒否されます。他のすべてのドキュメントは受け入れられます。その後、受け入れられたドキュメントのセットは、結果として返されます。
以下のタイプのクエリは、後でサポートされる予定です。
単一用語クエリ：複数期クエリと同様に、ドキュメントは単一の用語に対して採点されます。
フルフレーズクエリ：複数期クエリに似ていますが、すべての用語を正しい順序で含むドキュメントのみが許可されます。
また、検索を実行する前に入力検索文字列を正しいクエリタイプに変換できるように、クエリ解析を実装することも目的としています。
これらは、将来を目的とした改善です。
検索パフォーマンスを向上させるために使用できるストレージ不可欠なキャッシュ（Redis、Memcached、ファイルシステムなど）を実装します。このプロジェクトには、キャッシュには多くのユースケースがあります。
注：上記の機能のいくつかを実装するには、一意のセッション識別子を使用してユーザーから渡されて受信する必要があります。これは間違いなく、ユーザーがページングできるように一連の検索結果をキャッシュする場合です。また、同じことを検索している多くのユーザーが同じ検索結果を迅速に見ることができるようにセッション固有とは見なされないキャッシュバージョンの価値があります。
インデックス作成プロセス中に、追加のテーブルを使用して、用語のマッピングをドキュメントに保存することができます。これにより、特定の用語が表示されるドキュメントが表示されます。これにより、用語が表示されるドキュメントのリストを取得して候補者のリストを取得しようとすることで、候補の文書を迅速に発生させる（または抑制された用語を抑制し、候補者の数を減らすことができます）を決定しようとする多くのプロセスをスキップすることができます。
