Положим есть очень большое файловое хранилище. Разнородное. ~50 TB. Считаем что оно только для чтения.
В нем файлы различных типов. И мы умеем извлекать из них текст.
Собственно вопрос: как организовать индекс по какому будет идти поиск, что бы он имел минимальный размер?
Хотя бы укладывался в 5% объема текста файлов. Понятно что рядом с индексом нужно хранить пути к файлам где этот текст содержится.
BE>Собственно вопрос: как организовать индекс по какому будет идти поиск, что бы он имел минимальный размер?
Это называется inverted index. Концептуально представляет из себя таблицу: токен->список документов, позиций в них где встречается токен, прочие данные.
Как эту таблицу хранить и как в ней искать — везде свои реализации, зависящие от того какие запросы, и как ранжировать рзультаты.
Используются обычно хэштаблицы, bloom фильтры (и другие нечеткие фильтры), B-деревья, skiplists или просто готовые key-value движки.
BE>Хотя бы укладывался в 5% объема текста файлов. Понятно что рядом с индексом нужно хранить пути к файлам где этот текст содержится.
Мне кажется что 5% это нереально. хорошо если 30% выйдет, а в некоторых случаях полнотекстовый индекс превосходит по объему сами данные
BE>Что читать по теме?
Почитать про Inverted Indexes (FullText Indexes) в СУБД , а также посмотреть как это реализовано в опенсорсных движках — lucene, elastic search итд
BE>Спасибо.
Здравствуйте, gandjustas, Вы писали:
BE>>Хотя бы укладывался в 5% объема текста файлов. Понятно что рядом с индексом нужно хранить пути к файлам где этот текст содержится. G>Мне кажется что 5% это нереально. хорошо если 30% выйдет, а в некоторых случаях полнотекстовый индекс превосходит по объему сами данные
А как тогда поисковики свой индекс хранят? Не всё же они себе сохраняют.
BE>>Что читать по теме? G>Почитать про Inverted Indexes (FullText Indexes) в СУБД , а также посмотреть как это реализовано в опенсорсных движках — lucene, elastic search итд
Спасибо, почитаю. Я и хочу это в Elastic складывать.
Здравствуйте, BlackEric, Вы писали:
BE>Здравствуйте, gandjustas, Вы писали:
BE>>>Хотя бы укладывался в 5% объема текста файлов. Понятно что рядом с индексом нужно хранить пути к файлам где этот текст содержится. G>>Мне кажется что 5% это нереально. хорошо если 30% выйдет, а в некоторых случаях полнотекстовый индекс превосходит по объему сами данные
BE>А как тогда поисковики свой индекс хранят? Не всё же они себе сохраняют.
Ты удивишься...
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, BlackEric, Вы писали:
BE>>Собственно вопрос: как организовать индекс по какому будет идти поиск, что бы он имел минимальный размер? G>Это называется inverted index. Концептуально представляет из себя таблицу: токен->список документов, позиций в них где встречается токен, прочие данные.
G>Как эту таблицу хранить и как в ней искать — везде свои реализации, зависящие от того какие запросы, и как ранжировать рзультаты. G>Используются обычно хэштаблицы, bloom фильтры (и другие нечеткие фильтры), B-деревья, skiplists или просто готовые key-value движки.
BE>>Хотя бы укладывался в 5% объема текста файлов. Понятно что рядом с индексом нужно хранить пути к файлам где этот текст содержится. G>Мне кажется что 5% это нереально. хорошо если 30% выйдет, а в некоторых случаях полнотекстовый индекс превосходит по объему сами данные
BE>>Что читать по теме? G>Почитать про Inverted Indexes (FullText Indexes) в СУБД , а также посмотреть как это реализовано в опенсорсных движках — lucene, elastic search итд
BE>>Спасибо.
Я на заре своей карьеры как-то эту штуку в ручную делал.
Здравствуйте, gandjustas, Вы писали:
BE>>Хотя бы укладывался в 5% объема текста файлов. Понятно что рядом с индексом нужно хранить пути к файлам где этот текст содержится. G>Мне кажется что 5% это нереально. хорошо если 30% выйдет, а в некоторых случаях полнотекстовый индекс превосходит по объему сами данные
Это почему нереально, если это от данных зависит? Мож там 10 слов повторяются на 5Т?
