Vyacheslav Tikhonov,
Спасибо, мои подозрения оправдались.
Хочется спросить у народа: кто-нибудь работал с Postgress? Я не собираюсь пока ничего говорить об этой СУБД поскольку работала с ней крайне мало.
И правда :)
Ы-ым... ява - штука не та, наверняка... на сях быстрей. Ну, и скриптовые языки - тоже не то :) Хотя, кого-то и могут соблазнить обилием нужных функций.
Maxim Golubev,
Ни в коем случае не собиралась с вами спорить... собственно спорить мне рановато... :)
Аргументы о мощностях - несколько не те: с ними-то уж точно не поспоришь, поскольку первым делом, начиная думать о SE, смотрела, кто на чем работает...
У меня, например, нет 10-ти серверов :) А между тем, скорость Совы - оставляет желать лучшего, притом, что не думаю, что ресурс этой SE сравним с тем же Google или Яндексом. И мне кажется, что если отказаться в некоторых местах от скоростей SQL-запросов, эту скорость можно и увеличить.
Вот я и вернулась....
Пять дней назад :) с ребятами Оракл и MySQL сравнивали. *выпили много пива, но до драки не дошло*. Собственно, ничего грандиозно нового не поведаю. На сложных запросах оба долго думают. MySQL - чуть дольше. Но! Опять же, все зависит от настроек оптимизации, как напомнил нам trink. За один день ничего нового мы не настроим. Также - имеется немалая зависимость от железа.
Что же касается сложных запросов - индекс здесь действительно отдыхает.
Индекс полезен, насколько я знаю теорию (еще крутится в голове универская теория индексации инфы, позиционирования поиска и построения b-деревьев), в прямолинейных запросах, потому что деревья данных сами по себе строятся по индексу, это и ежику ясно :) Если вы используете дополнительные функции и запрос усложняете, правильный подбор индекса не играет роли.
Сравните скорость поиска Совы с остальными поисковиками.... Не знаю, на чем она работает, но вопрос для меня уже в некотором роде разъяснился.
В узких местах СУБД - любая! - будет работу лишь замедлять. С инвертированным индексом работать быстрей. Некоторые, может, решат, что это варварство, но я же не предлагаю не использовать СУБД вообще! Но, насколько я уже успела убедиться, работа с простыми типизированными файлами в самом "загруженном" месте индексации и поиска будет куда быстрей.
Насчет же человеко-часов: никто не спорит, что ребята долго трудились и придумали нечто феноменальное, чего нам за месяц не повторить :) Однако, опять же, дело в том, что имеющиеся СУБД не заточены исключительно под SE.Они умны, сложны, безопасны, надежны - да. Но этого не всегда хватает :)
Ayavryk,
Помогает через раз...
!Иван FXS,
второй путь представляется мне более ресурсоемким. а вообще, я как новичок в этой области, советовать ничего не берусь.
Кстати, поверхностно: простая схема "слово-id"- не учитывает словоформ.
Посмотрите, и правда, как построен словаь у Андрея Коваленко (кстати, почему "имени Коваленко"?). У Коваленко есть демо-версия. Посмотрите. Потестите.
Выражу свое понимание.
Прямой индекс - это индексация по ключу. Как в любой БД. "инвертированный", если я могу тут правильно выразиться - это просто список, сгенерированный из прямого. Обычно это какой-то типизированный файл (ну, или кучка файлов :) ), а что в том файле записано - уже волеизъявление программера (не обязательно ведь то, что было записано в прямом индексе, что-то добавляетcя, видоизменяется и т. д.). По понятным причинам, работать с таким файлом - гораздо быстрее, чем с выборками из таблиц.
Посмотрите примерно тут (не знаю, давали ли уже эту ссылку):
http://old.company.yandex.ru/articles/article10.html
После пары дней рассуждений и пары бутылок пива я все-таки думаю, что прямой индекс следует хранить в любом случае. С ним легче производить переиндексацию (потому что все рано или поздно приходится переиндексировать) в инвертированный индекс.
