Вышел SearchInform 2.0.

Ну Вы ответили, что пользователь управляет стоп-словами, а как он ими "управил" в тестовом примере, Вы не написали. Сейчас понятно. Стоп-слова, или очень частотные слова на самом деле, нужны в индексе. И как ни странно для того, чтобы быстро отвечать на тяжелые фразовые запросы "to be or not to be". Потому как если выбрать все документы со словом be (отнюдь не низкочастотным), то проверить наличие в них фразы можно только подняв текст документов (или их преобразованную версию). Поскольку документов со словом be очень много (практически каждый первый, если be еще и стеммится), каждый требует рандом акссесса к диску. Резюмируя все это, можно предположить, что запрос вполне может по дисковой активности вылиться на 5-10 минут (фактически по 0.05 мс на каждый найденный документ, а если их миллион, то операция займет больше часа). А если слова to, or, not есть в индексе, то хоть операция считывания соответствующих инвертированных списков и пересечения со списком be тяжелая, но списки можно считывать последовательно и гораздо быстрее. Думаю, что в минуту можно уложиться :-)

Так, все-таки, какой объем стоп-словаря Вы использовали в тесте? Не влияет ли это в Вашей системе на скорость индексирования?

Простите за отвлечение, но однажды я встретил систему, где объем стоп-словаря был в тысячи слов. Разработчик объяснял это примерно также, как Вы (думаю, это просто совпадение). Кроме того, он утверждал, что для поиска глаголы вообще не нужны (не считая предлогов, союзов и пр. "мусора").

Ну я авообще то ответил уже на это -- что ждостаточно скачать SearchInform и зайти в менеджер стоп слов и там все видно

Ну вот еще если уж так лень закачал список и отдельно www.searchinform.com/tmp/tsearch.stp

Минута это результат неприемлимый для промышленной системы :)

Вот провел тест.

База документов :

Размер документов 132,26 gb

Всего документов 2,888,202

Уникальных слов 18,912,257

Размер чистого текста 77,57 gb

Размер индекса 16,29 gb

Время индексации 6:28

В среднем гб в час 20,45

Далее все время в секундах -- они на скринах внизу

1) Поиск по слову Device == www.searchinform.com/tmp/device.gif

Найдено 870.748 документов

Время 2.188

2) Поиск по слову connected == http://www.searchinform.com/tmp/connected.gif

Найдено документов 1.034.702

Время 2.375

3) поиск по фразе http://www.searchinform.com/tmp/device_connected1.gif

Поиск по фразе device connected где порядок слов не важен и максимальное число других слов между заданными =10

Результат = 199.975 документов

Время = 7.439

Надеюсь что тесты показываю скорость работы на очень частотных словах?

Причем вместе с ростом базы время отработки поискового запроса ухудшается незначительно.

Почему то все зациклились на обычных инвертированных спискакх -- там да нереально достичь не индекса в 20% ни быстрых ответов при поиске......

А SearchInform именно из за своих технологий и стал реально на сеголня самой быстрой поисковой системой в мире :) Если кто то готов сказать что есть более быстрая система и предоставить тесты, то я буду очень рад. Мы не скрываем результатов своих тестов и более того даем всем желающим самостоятельно проверить правдивость наших слов.

Ничего я не болтун . В среднем скорость записи позволит за час записать такой объем. Это без учета фрагментации и разборки под индекс.

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

Как раз вы болтун и я отвечаю за свои слова. Вы же не тестили SearchInform верно ?

Скоррость записи чего -- 16 гиг индекса не возможна за 6 часов?

Или скорость чтения 100 гиг за 6 часов нереальна?

Не смешите меня и сообщество.

Я вот могу сказать что именно на этом тестовом компе тестировалось не в индексировании а просто так скорость чтения 12 гиг из 400 файлов и их же записи в один файл. Так вот занимает это ровно 30 минут.

Соотсветственно в час порядка 50 гиг легко винт выдержит.

Если не верите -- возьмите студента он вам за 10 баксов напишет такую тестовую прожку и запустите это на винте 160 гиг 7200 оборотом (ну у меня конкретно samsung)............

Жду ваших аргументов если вы не болтун. Правда вы еще и на предыдущий вопрос не ответили про какую запись речь идет что она за 6 часов невозможна........

Пелвис, почему же невозможно-то? 10метров в секунду 36 гигов в час. То есть на запись индекса уходит меньше часа, на чтение этих 130 гигов четыре часа, но поскольку диски разные это может идти параллельно. Само время обработки по сравнению со временем чтения с диска можно сделать маленьким.

Leom Нет, такие слова нельзя считать очень частотными, хотя скорость поиска хорошая, не буду скрывать. Не знаю, как насчет качества поиска, а производительность ну очень замечательная.

Теперь по поводу инвертированных индексов? Ну почему же нельзя добиться такого объема и скорости. Двадцать процентов для приведенного Вами списка слов и координатного индекса без морфологической информации это абсолютно реальная цифра. И ищет инвертированный индекс очень быстро. Вот смотрите миллион документов по 2-3 вхождения слова в документ. В среднем по паре байт на кодирование одного вхождения в сжатом ИФ. Получаем 6 мегабайтный инв. список. Считывается и распаковывается на Вашей железке < 1 sec. Тайтлы у Вас, очевидно, лежат в памяти, иначе б все тормозило дико. Время поиска даже меньше Вашего :-) или примерно такое же. А Вы вот сразу кидаетесь фразами про "тормознутость" ИФ.

PS: и, кстати, тяжело Вам будет найти студента за 10 баксов. нормальную такую дорожку написать - это покумекать надо. просто я это все проходил уже и знаю, как статистику собрать, как правильно генерировать словарь, чтобы с ростом коллекции новые слова появлялись, похожие на нормальные русские или англйиские слова. потом там надо покумекать, как эффективно организовать статистику по парам следования слов. пар-то дофига, все память не влезет, а при генерации документов эту статистику надо подымать. видимо, надо ее как-то покоцать, чтобы пары только для довольно частотных слов, скажем для первых 5 тысяч, а все остальные слова разбить на группы тоже по 5 тысяч и статистику брать уже для группы.

Окей, тут вариант один.

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

И при этом превратить Ваши гигабайты в коммерческую информацию. ( а именно: покупатель - тестирование - результат - продукт, который имеет сколь нибудь успешное место на рынке)

А я тогда подумаю, стоит ли мне вообще оправдываться за мой скепсис.

То есть слово которое встречается практически в каждом втором документе не частотное? Чего то я тогда не понимаю -- проясните пожалуйста.

Мы вообще то ищем в том числе и с морфологие. И все тесты я приводил когда морфология включена. А без морфологии будет намного быстрей.

Тайтлы в памяти не лежат -- но винда же кэширует файлы.

Инвертированный список в чистом виже уж поверьте по фразовому поиску ищет намного медленней. Мы же месли можно так сказать используем сильно модифицированный инвертированный список ив этом вся изюминка.

То есть строго формально если говорить то путь для фразового поиска только один хранить инфу

слово-документ-позиция

Но важно же сие грамотно хранить -- и на этом в том числе строится быстродействие.

И есть еще ряд вещей которые позволяют просто не делать лишней работы основываясб на имеющейся в индексе инфе.