blixt php
1.0.0
Представляйте различные типы в пределах индекса, таких как пользователь, продукт и т. Д.
Представляет стеблы слов, уникальные для всего индекса. (Например, запуск - это стебель слов, бегущих, запуска, и т. Д.). Обратная частота документов рассчитывается и сохраняется в соответствии с словом, чтобы обеспечить общеиндексный IDF, который можно использовать для выполнения поисков без схемы по индексу.
Термин представляет существование слова в определенной схеме. То есть, если в схеме пользователя появляется слово «запуск», и оно также появляется в схеме продукта, то в этой схеме будет два термина записи для этого слова. Обратная частота документов также сохраняется вдоль термина, чтобы предоставить специфическую схему IDF, который позволяет поиск по конкретной схеме (эти поиски не будут влиять на значения IDF в масштабе индекса для слов).
Столбец - это доступное поле в схеме. В столбце хранятся правила о том, хранятся ли данные, которые он представляет, индексируется ли он, и его вес, который можно использовать для определения приоритетов столбцов в запросах (например, заголовок продукта может иметь больший вес, чем описание)
Документ представляет собой фактическую сущность в индексе, это элемент, который фактически проиндексирован и будет сформировать основу результатов для запросов.
Поле является атрибутом документа, который соответствует столбцу. Столбцы, документы и поля действуют как типичная база данных. Столбец похож на столбец таблицы, документ похож на строку или запись, а поле - ячейка или запись.
Включение представляет существование термина (специфическое слово схемы) в поле в документе. Возникновение - это уникальное представление термина и поля. Вдоль возникновения мы также храним частоту, которая представляет количество раз, когда термин появляется в поле (что используется для расчета баллов позже при поиске).
Позиции представляют, что фактические позиции терминов в областях. Если слово «запустить» (или его стебли) появится 3 раза в поле, будет 3 записи позиции, каждая из которых отмечает положение этого возникновения в соответствующем поле.
Представьте, что у нас есть схема «пользователя» в нашем индексе. Эта схема определяет 2 столбца для каждого экземпляра пользователя, «Имя» и «О». Каждый столбец хранится и индексируется, и у них оба есть вес 1. У нас есть 2 пользователя, которые можно добавить в индекс, [Ключ: 1, имя: «Джо Блоггс», «О»: «Джо любит Джейн»] и [Ключ: 2, имя: «Джейн Доу», о: «Джейн любит вечеринки»]. В итоге мы получим следующую структуру:
| идентификатор | имя |
|---|---|
| 1 | пользователь |
| идентификатор | имя | хранится | индексирован | масса |
|---|---|---|---|---|
| 1 | имя | 1 | 1 | 1 |
| 2 | о | 1 | 1 | 1 |
| идентификатор | слово |
|---|---|
| 1 | Джо |
| 2 | блог |
| 3 | нравиться |
| 4 | Джейн |
| 5 | доу |
| 6 | любовь |
| 7 | к |
| 8 | вечеринка |
| идентификатор | 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 |
| идентификатор | schema_id | ключ |
|---|---|---|
| 1 | 1 | 1 |
| 2 | 1 | 2 |
| идентификатор | document_id | column_id | ценить |
|---|---|---|---|
| 1 | 1 | 1 | Джо Блоггс |
| 2 | 1 | 2 | Джо любит Джейн |
| 3 | 2 | 1 | Джейн Доу |
| 4 | 2 | 2 | Джейн любит вечеринки |
| идентификатор | 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 |
| идентификатор | ocdustrence_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 добавит запись документа и начнет обрабатывать поля документа. Каждое поле разделяется на токены (в большинстве случаев токен - это слово), а затем каждый токен установлен (то есть нахождение корня слова, например, с помощью английского/портера ствола слова «запустить» - это стебель слов «бег», «бегун», «бегает» и т. Д.)
Затем для каждого из токенов добавляются записи Word, если нет соответствующих записей, а затем схемы создаются соответствующим образом. Общее количество документов для термина «записи» обновляются, чтобы отразить добавление нового документа.
Записи о происшествиях создаются для каждого уникального члена и комбинации поля, указывающих, что указанный термин происходит в конкретном поле. Частота (количество раз, когда термин произошел в поле), хранится вдоль записи возникновения. Позиционные данные также хранятся в отношении каждой записи возникновения, представляющей каждую позицию в поле, что произошел термин.
Поддерживаются следующие типы запросов:
+ , что делает необходимый термин (и) или a ~ , что заставляет термин удалить документ из рассмотрения (нет). Этот тип запроса составляет основу всех других запросов. Поиск начинается с разделения поисковой фразы на отдельные слова (токенизация), а затем превращая каждое слово в его корневую форму (Stemming). Затем индекс запрашивается, чтобы найти записи Word, соответствующие терминам. Используя слово «Записи» и схему, которую мы спрашиваем, затем извлекаются термины. Если какой -либо из терминов поиска, в котором прикреплен к нему оператор + , отсутствует в записях термина, то пустой набор результатов возвращается.
Затем выполняется запрос, чтобы найти поля, которые содержат условия запроса (независимо от оператора), и документы, связанные с этими полями, возвращаются (с их полями, происшествиями и позициями, все загруженные соответственно). Затем каждый документ анализируется и принимается или отклоняется, если документ не содержит требуемый термин ( + ) или содержит удаленный термин ( ~ ), он отклоняется, все остальные документы принимаются. Набор принятых документов затем возвращается в качестве результатов.
Следующие типы запросов должны быть поддержаны позже:
Один термин: аналогично многоспешнному запросу, документы оцениваются по одному термину.
Полный запрос фразы: аналогично многоспешнному запросу, но разрешены только документы, которые содержат каждый термин в правильном порядке.
Он также предназначен для реализации анализа запросов, чтобы входной строку поиска могла быть преобразована в правильный тип запроса перед выполнением поиска.
Это улучшения, которые предназначены для будущего.
Реализуйте агностический кэш хранения (Redis, Memcached, файловая система и т. Д.), Который мы можем использовать для повышения производительности поиска. В этом проекте есть ряд вариантов использования:
ПРИМЕЧАНИЕ. Чтобы реализовать некоторые из вышеперечисленных функций, нам потенциально потребуется использовать уникальный идентификатор сеанса для передачи обратно и получения от пользователя, чтобы убедиться, что кэшированные поиски действительны только для этого пользователя и остановить эти кэшированные объекты. Это определенно тот случай, когда кэширует полный набор результатов поиска, чтобы позволить пользователю провести страницу. Также может стоить кэширования версий, которые не считаются специфичными для сеанса, чтобы многие пользователи ищут то же самое, чтобы быстро увидеть те же результаты поиска.
Во время процесса индексации мы можем использовать дополнительную таблицу для хранения картирования терминов с документами, которые сообщат нам, в каких документах появляется заданный термин. Это позволит нам пропустить большую часть процесса попыток определить идентификаторы документов -кандидатов, просто забив список документов, которые появляются, чтобы разрешить нам быстро генерировать (или в случае запрещенных терминов, уменьшить количество идентификации кандидатов кандидата.
