itman

Рейтинг
64
Регистрация
26.05.2001
!Иван FXS:
(unsigned long) ... 65535

???

хе-ха, пардон заглючило. работать надо меньше.

!Иван FXS:
Ээээээээээээ ...

- приведите хотя бы одно - то самое, самое большое.

Количество простых чисел pi(n) ~ n/ln(n) для 65535 получаем порядка шести тысяч. Все-таки не несколько десяткво.

Пардон, просвятите насчет баяна. Мне очень интересно, возможно, на далекое будущее.

да уж вы очень сильно под гугл аппалайенс копаете :-) они вон ведь какие деньги берут за решение на 100 тысяч документов :-)

Zute:
OFFSET есть начиная с версии 4.0.6
http://dev.mysql.com/doc/refman/4.1/en/news-4-0-6.html

У меня стоит 4.0.23a и не работает :-) Ну да это мелочь, я же говорю, которую я поправил в первый же день.

У меня там две гораздо большие проблемы: сжиранием деомном stored (может это был какой-то локальный временный глюк) 100% процессорного времени и неправильная группировка результатов поиска. Когда я разберусь что и почем, то подведу счет глюкам. Но общее впечателние как от продукта сырого. Впрочем, надо быть честным, например аналогичной разборки многосёрча от компиляции и до установки я не делал. Вполне возможно, что и там полно таких же проблем.

Под Линуксом, но это, похоже, не важно.

Короче, Вы правы асболютли, просто у меня пока руки не дошли. Но большинство багов с операционкой явно не связаны :-) Так, например, датапарк не работает с mysql v 4. А потому што в mysql 4 нет еще пока ключевого слова OFFSET. Фигня, конечно, компйлер и исходник всегда под рукой :-)

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

Особенно меня поразил тот факт, что урл вида https://searchengines.guru/ (без слеша на конце), считается датапарксёрчем ошибочным. Это, собственное, не мешает ему его проиндексировать. Тем не менее группировка с другими страницами того же сайта не происходит.

Правда, надо отдать должное в кешемоде ищет довольно-таки быстро.

pelvis:
Я не говорил, что запись или чтение по отдельности нереальны.
Я сказал, что индексирование на такой машине с хорошим в последствии результатом невозможна.
Читайте внимательнее, прежде чем швыряться словами.

Я, кстати, знаю как индексировать такие большие объемы... Реально даже в два раза большие, за счет только очень небольшого, реально практически незаметного ухудшения какчества. Так что это не совсем правда про невозможность достижения результата. Почему бы тогда и другим не уметь делать тоже самое? :-)

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

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

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

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

Всего: 444