Поисковик для локальной сети

где и как тестировались заявленные на сайте цифры Я привык быстренько все прикидывать в голове и получаю картину:

Дано: скорость индексации 30 ГБ/час. Средний html документ составляет 30 КБ. При заявленной скорости однопоточный индексатор производит индекс 300 документов в секунду т.е. на индексацию одного документа уходит 3 миллисекунды. Вы меня извините, но в среднем только на доступ к любой информации на диске (будь то файл или "сырое" устройство) уходит 7-10 миллисекунд вне зависимости от ОС - это время seek головки считывания (простая физика). А тут надо еще прочитать данные, создать порцию индекса, добавить к ранее полученной (ведь не все же 30 гигов сидят в памяти) и записать на носитель. Не открывая Ваше ноу-хау, на пальцах - как такое возможно? Или может цифры обозначают что-то иное и я не правильно понял?

Другой вопрос: а зачем расхваливать скорость индексирования, если юзеры поисковика будут видеть только скорость поиска ?

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

На самом деле, это достаточно важная (хоть и не главная) характеристика SE для потенциальных владельцев. При прочих равных условиях я бы предпочел поисковик, который при добавлении к N гигабайт данных еще 30 ГБ через час будет искать по всей моей коллекции. Но меня надо в этом убедить. Возможно, просто автор предложения ошибся конфой, но в любом случае, без аргументации вряд ли что-то можно продать :)

Кстати, насчет 7 мс я тоже в корне не согласен. Это только время позиционирования головки. В случае последовательного считывания-записи на диск все совсем по-другому. Чисто теоретически можно строить индекс со скоростью сравнимой со скоростью записи на диск. Особенно если один винт на чтение работает, а второй на запись.

Сначала строим N инвертированных индексов в памяти записываем на диск. Потом за один проход их читаем с одного диска и сливая пишем на другой диск. Опять-таки, если читать каждый раз большими кусками по несколько мегабайт все будет работать со скоростью чтения-записи. Считанные куски естественно сливаем в памяти, записываем на диск.

Разбор документа тоже можно делать довольно быстро. Если парсер, конечно, не тормозит. Другое дело, что достижение такой высокой скорости на практике дело весьма трудоемкое, требующее высококвалифицированных программистов и быстро работающего парсера.

itman, Собственно я и спросил, где и как проводилось тестирование :) Я могу заявить и значительно большие цифры. Другой вопрос, что мы тестируем: количество и мощность наших Крэй-ев или что-то, что можно пощупать в реальной жизни. А реальность именно такая, что 30ГБ данных - это миллион документов, а не абстрактный массив нулей и единиц, который читается последовательно и с интерливами и кэшем и прочим :) Не согласны?

Я вот недавно тестировал: 3.5 документов (по тексту примерно в два раза меньше, чем средний вебовский документов, или примерно как два млн средних HTMLей) со специальным добавочным индексом, размер которого превышает исходный раз в пять-шесть индексируются часов 20. На слабеньком гигагерцовм пне с 512к ОЗУ и ОДНИМ IDE диском. Собственно поделим это число на пять, получаем 4 часа без дополнительного индекса. Или два часа на млн стандартных вебовских документов. Похожие цифры получаются? Как раз была реализована стратегия параллельного слияния нескольких индексов.

Ну и потом, даже если господин Леом где-то проколося в ошибках измерения раза так в 2-3. То даже с такой поравкой скорость индексирования более чем удовлетворительная.

Ну и небольшая поправочка: индексы, даже промежуточные были сжатыми, алгоритм распаковки подбирался быстрый, собственно это был VBC (variable byte coding). Он отличается тем, что распаковывает-упаковывает заметно быстрее, чем идет запись на диск. Возможно, что за счет этого достигается определенный доп выигрыш.

При каких прочий ? Про скорость поиска-то ни гугу :)

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