blixt php
1.0.0
表示索引中的不同类型，例如用户，产品等。
代表单词词干，整个索引独有。 （例如，运行是运行，跑步者，运行等单词的词干）。计算逆文档频率并将其存储在单词上，以提供跨索引范围的IDF，可用于针对索引执行无模式的搜索。
一个术语表示特定模式中的单词存在。也就是说，如果词干单词“ run”出现在用户模式中，并且它也出现在产品架构中，则该架构中将有两个术语记录。术语还存储了一个反向文档频率，以提供特定模式的IDF，该IDF允许针对特定模式进行搜索（这些搜索不会受单词范围范围的IDF值的影响）。
列是模式中的可用字段。该列存储了有关其代表的数据是否存储的规则，是否索引和重量，可用于优先考虑查询中的列（例如，产品标题可能比描述的权重更多）
文档代表索引中的实际实体，这是实际索引的项目，将构成结果的基础。
字段是与列匹配的文档的属性。列，文档和字段的作用就像典型的数据库。列就像表列，文档就像一行或记录，字段是单元格或条目。
出现表示文档中字段中的术语（架构特定单词）的存在。出现是术语和字段的独特表示。在侧面发生的情况下，我们还存储了一个频率，该频率表示该术语出现在字段中的次数（用于稍后在搜索时计算得分）。
位置表示字段中术语的实际位置。如果“ run”（或其词干）在一个字段中出现3次，则将有3个位置记录，每个位置记录都标记了相应字段中发生的位置。
想象一下，我们的索引中有一个“用户”模式。该模式为每个用户实例，“名称”和“关于”定义了2列。每列既存储又索引，它们的权重为1。我们有2个用户可以添加到索引中，[键：1，名称：“ joe bloggs”，“关于”：“ Joe Like jane”]和[key：2，name：“ name：“ jane doe”，jane doe'，of：“ jane doe”，on of town of party party party party party party']。我们最终将以以下结构：
| ID | 姓名 |
|---|---|
| 1 | 用户 |
| ID | 姓名 | 存储 | 索引 | 重量 |
|---|---|---|---|---|
| 1 | 姓名 | 1 | 1 | 1 |
| 2 | 关于 | 1 | 1 | 1 |
| ID | 单词 |
|---|---|
| 1 | 乔 |
| 2 | 博客 |
| 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 | 出现_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将添加文档记录并开始处理文档字段。每个字段都被分为令牌（在大多数情况下，令牌是一个单词），然后每个令牌被茎（即找到单词的词根，例如使用英语/搬运工stemmer，“ run”一词是单词“运行”，“ runner”，“ runner”，“ runs”等）。
然后，如果没有相应的记录，则为每个令牌添加单词记录，然后在模式下在架构下创建术语记录。文档计数总数的总数已更新，以反映新文档的添加。
为每个唯一项和字段组合创建出现记录，表明指定的术语发生在特定字段中。频率（该术语中发生的术语数量）在发生记录的侧面存储。在每个发生记录的记录中，位置数据也存储，该记录代表了一个项的字段中的每个位置。
支持以下查询类型：
+直接使用该术语（and）或~ ，否则该短语中的所有术语均被视为可选（或），该术语使该术语从考虑（非）中删除文档。这种类型的查询构成了所有其他查询的基础。搜索首先将搜索短语分成单独的单词（令牌化），然后将每个单词变成其根部形式（stemming）。然后查询索引以查找与术语匹配的单词记录。使用我们正在询问的单词记录和架构，然后提取术语记录。如果在术语记录中不存在任何附上+运算符的搜索词，则返回一个空结果集。
然后执行查询以查找包含查询条款的字段（无论操作员如何），并返回与这些字段相关联的文档（并返回其字段，出现和位置，均应相应地加载）。然后，分析每个文档并接受或拒绝，如果文档不包含所需的术语（ + ）或包含删除项（ ~ ），则拒绝了所有其他文档。然后将一组接受的文档作为结果返回。
稍后将支持以下查询类型：
单个术语查询：类似于多任期查询，文档是根据单个项对文档进行评分的。
完整短语查询：类似于多期查询，但仅允许以正确顺序包含每个学期的文档。
它还旨在实现查询解析，以便在执行搜索之前可以将输入搜索字符串转换为正确的查询类型。
这些是旨在未来的改进。
我们可以用来提高搜索性能，以实现存储不可知的缓存（redis，memcached，文件系统等）。该项目中有许多用于缓存的用例：
注意：要实现上述某些功能，我们可能需要使用唯一的会话标识符来传递并从用户接收，以确保缓存搜索仅对该用户有效，并阻止清除这些缓存的对象。当缓存一组搜索结果以允许用户分页时，绝对是这种情况。这也可能是值得的缓存版本，这些版本不被认为是特定于会话的，以允许许多搜索相同内容的用户快速查看相同的搜索结果。
在索引过程中，我们可以使用额外的表格将术语映射到文档中，这将告诉我们给定术语出现哪些文档。这将使我们能够跳过许多试图通过仅抓住术语允许我们快速生成的文档列表来确定候选文档ID的过程（或在profient of Profient of Profient of Profient cormection cormectient cormections conternical norkes digess Ids Ids Ids中，）。
