История изменений
Исправление shahid, (текущая версия) :
Много букв написал, хотя суть вопроса можно было выразить в 2,5 строчки.
В каком виде хранятся индексы?
В случае ES и SOLR - в формате файлов lucene. Lucene - это мощная библиотека для написания поисковых движков, а не реализация этого самого движка.
Скачай и запусти ES, создай индекс по мануалу у них на сайте и затем найди файлы индекса в файловой системе. И всё как бы станет понятно.
При шардинге индекса на деле создаются несколько «подиндексов» и поиск в них идёт параллельно, а результаты затем объединяются.
При наполнении индекса, в нём создаются «сегменты» — ещё более мелкие подиндексы, того же формата. Со временем, сегменты объединяются. Сегментация нужна, т.к. обновление целого индекса — ресурсоёмкая операция.
Так же следует помнить, что чем больше индексов (шард, сегментов - не важно), тем больше отжирается RAM, и тем быстрее идёт поиск в больших коллекциях. Но если индексов (сегментов, шард) слишком много, то это тоже тормозит поиск.
В случае ES, индекс — это виртуальная сущность, которая указывает на подиндексы (шарды), которые содержат подиндексы «сегменты», в которых уже идёт поиск. Lucene как раз отвечает за наполнение сегментов данными индексации. Таким образом, шарда, содержащая данные, содержит хотя бы один сегмент. А индекс содержит хотя бы одну шарду. Когда делаешь запрос — поиск идёт в сегментах шард.
Сфинкс написан на сях, и у него свой собственный формат. Часть метаданных об индексах у него хранится в конфигах, что делает его очень статичным и неудобным, если необходим динамический рост индексов на живой системе.
Каковы основные этапы оптимизации поисковых движков при линейном росте содержимого/нагрузок?
Да особо никаких. Они не тормозят, если не искать по стоп-словам, контроллировать шардинг индексов, и никогда не искать по wildcard'ам («вас* люб* машу*»). Затраты будут на запил орфографии и синонимов, фасетов и прочих потребностей энтерпрайза перекроют любое желание оптимизации. При росте нагрузки и для отказоустойчивости системы используется репликация шард.
Исправление shahid, :
Много букв написал, хотя суть вопроса можно было выразить в 2,5 строчки.
В каком виде хранятся индексы?
В случае ES и SOLR - в формате файлов lucene. Lucene - это мощная библиотека для написания поисковых движков, а не реализация этого самого движка.
Скачай и запусти ES, создай индекс по мануалу у них на сайте и затем найди файлы индекса в файловой системе. И всё как бы станет понятно.
При шардинге индекса на деле создаются несколько «подиндексов» и поиск в них идёт параллельно, а результаты затем объединяются.
При наполнении индекса, в нём создаются «сегменты» — ещё более мелкие подиндексы, того же формата. Со временем, сегменты объединяются. Сегментация нужна, т.к. обновление целого индекса — ресурсоёмкая операция.
Так же следует помнить, что чем больше индексов (шард, сегментов - не важно), тем больше отжирается RAM, и тем быстрее идёт поиск в больших коллекциях. Но если индексов (сегментов, шард) слишком много, то это тоже тормозит поиск.
В случае ES, индекс — это виртуальная сущность, которая указывает на подиндексы (шарды), которые содержат подиндексы «сегменты», в которых уже идёт поиск. Шарда, содержащая данные, содержит хотя бы один сегмент. А индекс содержит хотя бы одну шарду.
Сфинкс написан на сях, и у него свой собственный формат. Часть метаданных об индексах у него хранится в конфигах, что делает его очень статичным и неудобным, если необходим динамический рост индексов на живой системе.
Каковы основные этапы оптимизации поисковых движков при линейном росте содержимого/нагрузок?
Да особо никаких. Они не тормозят, если не искать по стоп-словам, контроллировать шардинг индексов, и никогда не искать по wildcard'ам («вас* люб* машу*»). Затраты будут на запил орфографии и синонимов, фасетов и прочих потребностей энтерпрайза перекроют любое желание оптимизации. При росте нагрузки и для отказоустойчивости системы используется репликация шард.
Исходная версия shahid, :
Много букв написал, хотя суть вопроса можно было выразить в 2,5 строчки.
В каком виде хранятся индексы?
В случае ES и SOLR - в формате файлов lucene. Lucene - это мощная библиотека для написания поисковых движков, а не реализация этого самого движка.
Скачай и запусти ES, создай индекс по мануалу у них на сайте и затем найди файлы индекса в файловой системе. И всё как бы станет понятно.
При шардинге индекса на деле создаются несколько «подиндексов» и поиск в них идёт параллельно, а результаты затем объединяются.
При наполнении индекса, в нём создаются «сегменты» — ещё более мелкие подиндексы, того же формата. Со временем, сегменты объединяются. Сегментация нужна, т.к. обновление целого индекса — ресурсоёмкая операция.
Так же следует помнить, что чем больше индексов (шард, сегментов - не важно), тем больше отжирается RAM, и тем медленее идёт поиск в больших коллекциях.
Сфинкс написан на сях, и у него свой собственный формат. Часть метаданных об индексах у него хранится в конфигах, что делает его очень статичным и неудобным, если необходим динамический рост индексов на живой системе.
Каковы основные этапы оптимизации поисковых движков при линейном росте содержимого/нагрузок?
Да особо никаких. Они не тормозят, если не искать по стоп-словам, контроллировать шардинг индексов, и никогда не искать по wildcard'ам («вас* люб* машу*»). Затраты будут на запил орфографии и синонимов, фасетов и прочих потребностей энтерпрайза перекроют любое желание оптимизации.