Как правильно организовать базу?

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

Я не противоречу себе, я дополняю себя. Да ни одна база не потянет. И я за свои слова отвечаю, потому что плавал не раз. Ну если даже и сотни мегабайт там вытягивается, то сколько по времени это занимает? Минуту? 10 секунд? А если параллельно апдейт на таблицу запустить, то надо думать, что MyISAM насмерть заблокируется. Ни одна база с приемлемой производительностью не потянет. Потянет тысяч триста страниц per node с нагрузкой 20-30 запросов в минуту. Сравните со статическим индексом в несколько миллионов записей и то же нагрузкой. А если еще памяти гигов шесть поставить, то потянет и 20-30 запросов в секунду :-) А мускулу эти шесть гигов будут как мертвому припарки, там все равно индекс очень большой получится.

Дак как же всётаки учесть рассояние м/у словами?

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

есть подозрение, что такой хитрый запрос написать не удастся. скорее всего придется просто считывать все и пересекать в памяти.

Хорошо. Тогда сделаю пока без учета расстояния между словами.

Здравтсвуйте! Компании требуется администратор db2. Готовы сделать знающему специалисту достойное предложение.

e-mail: khan095@mail.ru (Людмила).

не знаю насчет "SQL" и "100 раз", но с BerkeleyDB и аккуратной блочной упаковкой достигали всего лишь двойной деградации.

Это тоже немало конечно, в случае с каким-нибудь Google каких-то 120 тысяч серверов. :)

Илья, я могу очень много рассказать про скорость индексации и прочая, но пока просто ограничусь указанием на несколько забавных мест в статье, ссылку на которую ты опубликовал. Вкратце хочу сказать, что авторы просто безбожно курят, когда дело касается конкретных цифр и дат. Итак обрати внимание на Figure 7 и таблицу 3. Но еще лучше сначала почитать раздел 4.2:

Внизу идет сноска, что 321 миллион это без учета повторяющихся постингов терминов внутри документа. Еще в таблице 3 для этих 2 млн документов указан средний размер input (HTML) в 16 гигов. Ага все замечательно. Исходя из среднего размера слова в 5.5 символов (для англ. языка) получаем, что чистый текст этой коллекции был никак не меньше (5.5 + 1) * 321 mln byte 1.8 гигов. Реально, наверное, было 2-4 гига текста. Возможно, что и больше, все зависит от повторяемости слов в документы 321 mln это все-таки без повторений.

Теперь посмотрим, сколько места может занимать single payload файл. В нем хранится слово ключевое 5.5 байт и еще два поля (номер документа, номер слова) по два байта минимум, а реальн, наверное, 2 + 3. еще сколько-нибудь занимает служебная информация (миниумум байт, а то и целый указатель) итого получаем примерно 10-12 байт на запись, что уже в два раза больше чистого текста. Теперь вспомни, что Беркли собственно строит динамические индексы и процентов пятьдесят места на страницах резервирует под будущие обновления, итого получаем трехкратный размер текста.

Потом снова смотрим в фигу 7 и натурально видим фигу, потому как размер всех списков анонсирован 3.5 гига вместо 6 гигов по самым скромным подсчетам. Уже разница в два раза!!! Может авторы выкинули стоп-слова? Но они про это нигде не пишут.

Далее в таблице 7 пунктиром указан размер индекса для так называемых full list. Он равен 1.5 гига. Несложно понять, что в не зависимости от того какой там PctUsed и PctFree в беркли, сжатый таким образом файл с точностью до резервируемого пространства < 50% текста, а single payload > 200% текста. Итого разница должна быть как минимум в 4 раза, а она чуть больше двух.

А вот еще очень важный логический момент: Авторы сравнивают скорость выборки mixed-list и full-list, но full-list лежит в индексе. А это значит, что скорее всего он побит на страницы, которые распиханы физически в разные уголки винчестера. То есть скорость поиска последовательно записанного на диск пост-листа может быть заметно выше. Авторы не приводят соответсвующих сравнений, но зато пишут:

Откуда, блин, такая уверенность в efficiency. Фантазеры, блин, а не ресерчеры. У меня вот лично есть абсолютно обратный экспириенс. Хотя я точных цифр не помню, но в свое время пришлось уйти от схемы full list и насколько я помню случился приличный выигрыш в производительности.

В любом случае, пока нет этих самых цифр про эффишенси по BDB vs plain binary file, это все несерьезно.

Короче, Илья, статья твоя халтура и полная лажа

И кстати, по поводу разницы в 100 раз: если упакованный инвертированный индекс весь влезает в кеш, а неупакованный список этих самых single payload в несколько раз больше размера оперативной памяти, то как раз эти самые 100 раз и получишь, уж никак не меньше.