Подбор СУБД

Обновлять частями, конечно. Распределенный индекс, каждая часть которого собирается на своей машине.

Словарь словоформ - это преимущественно статическая структура. Насколько я знаю, у Яндекса и Рамблера в словаре всего-то 100-150 тысяч слов.

А Вы собираетесь запускать второй Google? :)

Щас-с... только лыжи в угол поставлю... (с) :)

Годиков, эдак, через пять, когда подрасту маленько и сменю косички на что-нибудь посолидней :D

А вообще, за все советы огромное спасибо! Значит, вы однозначно не советуете пользоваться никакими СУБД вообще?

С них все, естественно, начинают, но быстро спрыгивают.

Я бы посоветовал почитать классическую теорию по информационно-поисковым системам касательно инвертированных файлов и алгоритмов ранжирования, и попробовать по их мотивам написать что-нибудь свое.

P.S. Вижу, Вы тоже из Украины? :)

Vyacheslav Tikhonov,

Спасибо. И все же неуверена...

Ну, полагаю, к ip у вас доступ есть... :) А дальше все просто...

Попытаюсь высказать свое некоторое видиние проблемы.

На мой взгляд релляционная база данных безусловно нужна!

Почему?

Потому что в поисковой системе безусловно будут и другие компоненты кроме поискового индекса. В зависимости от области применения такой системы, разной будет и сложность таких компонентов.Все реализовывать с помощью собственноручно сделанных способов долговременного хранения информации по крайней мере не разумно.А насчет накладных рассходов, то они по моим иследованиям достаточно малы(в подавляющем большинстве баз данных есть механизмы прекомпиляции запросов к выше преведенному примеру).

Какую БД выбрать? Я остановился на MySQL. Я сравнивал его и с ораклом и с постгрессом и с файрбердом. Почему? Он мне показался наиболее управляемым, простым и быстрым. В случае с ораклом, я столкнулся с ситуациями когда у меня что то где то начинало очень медленно работать, и что бы выяснить причину уходило много времени.

В конечном итоге я пришел к схеме, в которой документы, и различные их атрибуты(источник, язык) находились в базе данных, а поисковый индекс был сделан в виде инвертированного файла с использованием BerkeleyDB.

MySQL может работать с разными таблицами:

MyISAM

MERGE

HEAP

InnoDB

BDB или BerkeleyDB

Например, что касается таблиц InnoDB:

"В настоящий момент (октябрь 2001 года) таблицы InnoDB применяются на нескольких больших сайтах баз данных, для которых важна высокая производительность. Так, таблицы InnoDB используются на популярном сайте новостей Slashdot.org. Формат InnoDB применяется для хранения более 1Тб данных компании Mytrix, Inc; можно привести пример еще одного сайта, где при помощи при помощи InnoDB обрабатывается средняя нагрузка объемом в 800 вставок/обновлений в секунду."

(взято с с http://dev.mysql.com/doc/mysql/ru/InnoDB_overview.html)

BVod, trink

Вопрос, не в том, выдержит ли. Выдерживает по 2 Гб и больше. Вопрос в скорости.

Я тоже пользуюсь InnoDB-типом (в системе самой простой статистики по сайтам). И, кстатисть, остановила выбор на мускуле. Потому просто, что проще и быстр (хотя, со всеми прикрученными фичами заметно замедлился относительно 3-тих версий):) (уже упоминала, что лентяйка известная). После выходных доставлю еще пару СУБД (возможно, среди них будет еще и postgres).

Нужно потестировать хотя бы бегло, не впадая в глубины настроек, возможно, попробовать еще что-нибудь распределить (не факт, что СУБД быстро работающая на одной машине, будет быстрей остальных с кластеризованной БД).

Если кому интересно и мне не станет лень (:D ), потом расскажу. А пока просьба делиться несомненно богатым опытом.

К примеру: На 30 млн записей MySQL - задумался на 10 мин при простейшем select count.

В связи с такими неудобствами, оказалось проще взять готовые алгоритмы и слегка их модифицировать.

Не удержался. Так как я достаточно плотно использую MySQL именно как базу для поисковика, то скажу, что таблица в 2Гигабайта - работает легко, нужные запросы выдаются очень быстро. Если до этого правильно спланировать индекс(ы). Или: сделать правильную сортировку, сгенерировать быструю таблицу(без возможности править), разнести таблицу по HDD, разнести таблицу по серверам, поработать с параметрами всевозможных кешей, оптимизировать типы данных и т.д. и т.п. (нужное подчеркнуть).

Поконкретнее можно ? Какие типы столбцов в таблице, какой точно запрос был после многоточия: SELECT COUNT(*) FROM table_name WHERE ... ?