Известны два способа проектирования — «сверху вниз» и «снизу вверх». Похоже я опять пытаюсь изобрести велосипед, пойти третьим путем — от середины.
Поскольку лично мне в данный момент более интересна «частная производная» поиска, а именно поиск по отдельному сайту (группе сайтов, сгруппированных в некий единый блок) — в этом направлении и пойду.
Помимо собственно поиска существует еще проблема обновления индекса. Например коллеги поставили себе поисковый движок <a href«www.sphinxsearch.com»>Sphinx. Одна из проблем, с которой они столкнулись — невозможность оперативного обновления основного индекса, что для сайта СМИ неприемлемо.
Выкручивались они с помощью поиска по нескольким индексам (Сфинкс это позволяет). В течении дня при постинге очередной статьи пересобирался индекс текущего дня. За неделю таких индексов накапливалось 7 штук и в выходные, когда нагрузка на сервер падала, пересобирался главный индекс с учетом накопленного. И так по кругу. Такая жесткость индекса была сделана ради ускорения процесса поиска. За все нужно платить.
Слышал, что разработчик Сфинкса уже решает (или даже решил) эту проблему. Индексы стало можно объединять, избегая перегенерации по исходным данным. Таким образом он показал (за что огромное спасибо) грабли, на какие можно наступить (одни из). Такая информация о технологических граблях, поджидающих при разработке, не менее ценна, чем все манускрипты по теории поиска. Ведь наибольшие трудности начинаются когда теорию пытаешься переложить на практику.
Уф! Много слов. Но если не здесь, то в комментариях мне все равно пришлось бы объяснять причины своих решения.
Базовый индекс я хочу разделить на три параллельных:
Главный индекс — он и есть главный.
Индекс сего дня — все обновления текущего дня.
После полуночи «сегодня» становится «вчера» и освобождает место для нового дня.
В течении суток выполняется объединение главного индекса и «вчерашнего», после чего вчерашний удаляется, а главный замещается результатом объединения.
Таким образом минимизируются затраты на поддержание актуальности индекса.
При работе в режиме обычного поисковика (когда данные обновляются по мере наступления очереди сайта на сканирование) «вчерашний» индекс не нужен, а «сегодняшний» формируется на основе свежих поступлений, потом считаем, что наступила полночь и действуем по тому-же алгоритму.
PS. Гугл уже работает над технологией мгновенной индексации обновлений содержимого сайтов — PubSubHubbub. Не думаю, что при получении очередной порции обновлений будет перестраиваться весь индекс, скорее всего новости будут копиться в некоем буферном индексе, доступном в параллель с главным. Подобные технологии поисковики уже давно могли обкатать на поиске по новостям. Теперь настало время распостранить их на весь контент.
Поскольку лично мне в данный момент более интересна «частная производная» поиска, а именно поиск по отдельному сайту (группе сайтов, сгруппированных в некий единый блок) — в этом направлении и пойду.
Помимо собственно поиска существует еще проблема обновления индекса. Например коллеги поставили себе поисковый движок <a href«www.sphinxsearch.com»>Sphinx. Одна из проблем, с которой они столкнулись — невозможность оперативного обновления основного индекса, что для сайта СМИ неприемлемо.
Выкручивались они с помощью поиска по нескольким индексам (Сфинкс это позволяет). В течении дня при постинге очередной статьи пересобирался индекс текущего дня. За неделю таких индексов накапливалось 7 штук и в выходные, когда нагрузка на сервер падала, пересобирался главный индекс с учетом накопленного. И так по кругу. Такая жесткость индекса была сделана ради ускорения процесса поиска. За все нужно платить.
Слышал, что разработчик Сфинкса уже решает (или даже решил) эту проблему. Индексы стало можно объединять, избегая перегенерации по исходным данным. Таким образом он показал (за что огромное спасибо) грабли, на какие можно наступить (одни из). Такая информация о технологических граблях, поджидающих при разработке, не менее ценна, чем все манускрипты по теории поиска. Ведь наибольшие трудности начинаются когда теорию пытаешься переложить на практику.
Уф! Много слов. Но если не здесь, то в комментариях мне все равно пришлось бы объяснять причины своих решения.
Базовый индекс я хочу разделить на три параллельных:
- главный индекс;
- индекс «вчера»
- индекс «сегодня»
Главный индекс — он и есть главный.
Индекс сего дня — все обновления текущего дня.
После полуночи «сегодня» становится «вчера» и освобождает место для нового дня.
В течении суток выполняется объединение главного индекса и «вчерашнего», после чего вчерашний удаляется, а главный замещается результатом объединения.
Таким образом минимизируются затраты на поддержание актуальности индекса.
При работе в режиме обычного поисковика (когда данные обновляются по мере наступления очереди сайта на сканирование) «вчерашний» индекс не нужен, а «сегодняшний» формируется на основе свежих поступлений, потом считаем, что наступила полночь и действуем по тому-же алгоритму.
PS. Гугл уже работает над технологией мгновенной индексации обновлений содержимого сайтов — PubSubHubbub. Не думаю, что при получении очередной порции обновлений будет перестраиваться весь индекс, скорее всего новости будут копиться в некоем буферном индексе, доступном в параллель с главным. Подобные технологии поисковики уже давно могли обкатать на поиске по новостям. Теперь настало время распостранить их на весь контент.
