Turtle

 
 
 
   РАСШИРЕННЫЙ ПОИСК
   ПОИСК ПО ФРАГМЕНТУ
   ПОМОЩЬ
   ПРОСТАЯ ФОРМА
 
 СИНОНИМЫ   ВСЕ ФОРМЫ СЛОВ
 Добавить   Архитектура   Запросы сейчас   Цифры и факты   FAQ   Кнопка поиска   Сделать стартовой 

3.11 Борьба за компактность. Компрессия.

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

Мы провели некоторые исследования поведения различных доступных нам реализаций компрессоров данных. Эти исследования говорят о том, что в использовании методов компрессии для работы с поисковым индексом не все так однозначно. Так, например, скорость сжатия данных при помощи библиотеки функций GZIP (ZLIB_VERSION "1.1.4") составляет около 1MB в секунду, а скорость обратной операции извлечения данных составляет около 20MB в секунду на доступном нам реальном железе. Вспомним о том, какими объемами данных нам приходится оперировать для построения индекса. Реально для российской модели поиска, упомянутой в начале, это означает, что если мы производим обновление индекса, в котором информация хотя бы по половине поисковых терминов изменилась (суммарный объем половины данных индекса положим равным 250GB), то на разбор этой пачки мы потратим три с половиной часа, а на сбор новой пачки еще трое суток. А ведь это не самая важная операция обновления индекса.

Вспомним также о том, что мы поставили задачу: как можно быстрее обслужить поисковый запрос. Применительно к данным по частотным словам, такие задачи явно противоречат попытке экономии места за счет компрессии, т.к. скорость декомпрессии уступает скорости чтения с диска (или массива дисков). Если взять для рассмотрения "среднюю" корзину данных в 10МБ, то только на ее разбор потребуется полсекунды. При этом мы собираемся потратить на исполнение всего запроса несколько секунд, максимум.

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

Какие практические выводы мы сделали?

  1. Популярный пакет BZIP2 для данных задач использовать принципиально нельзя по причине плохих скоростных характеристик. По этим показателям он в 2-5 раз уступает GZIP, хоть и имеет некоторые преимущества в компактности.
  2. Компрессию в данных индекса использовать можно. Мы для себя выбрали функцию сжатия GZIP с уровнем 5. Программное обеспечение должно быть разработано таким образом, чтобы включение и выключение компрессии можно было бы производить конфигурационно, без полного перестроения индекса.
  3. Единицей для сжатия за одну операцию может являться "корзина" (или ее часть - см. выше). Существует некая критическая точка минимального размера данных для сжатия, ниже которой пытаться сжимать данные не имеет смысла (мы попусту тратим время без выигрыша дискового пространства).
  4. Существует вторая критическая точка размера данных "корзины", выше которой использование стандартных методов декомпрессии становится невозможным по причине того, что при поиске мы не сможем уложиться в заданный максимальный временной интервал.
  5. Для больших "корзин" можно использовать компрессоры, имеющие худшую степень сжатия, но лучшую скорость компрессии/декомпрессии (нами был выбран один из методов библиотеки LZO lzo-1.07.tar.gz).
В самом деле, никто не ставил задачу минимального времени отклика системы на поисковый запрос. Мы ставим задачу получения ответа на такой запрос в разумный интервал времени. Значит, компрессию данных применять можно, учитывая вышеизложенные соображения.

Оговорюсь в конце, что здесь мы говорили об исследованиях компрессии данных без потерь информативности и, исключительно, применительно к реальным двоичным данным нашего индекса "Turtle". Возможно, при проектировании другой поисковой системы с другой архитектурой результаты будут иными. С отчетом, содержащем таблицы замеров и графики, об исследовании методов компрессии, применительно к нашему случаю, можно познакомиться здесь.

<< 3.10. Индекс, подготовка данных для поиска | Содержание | 3.12. Построение и обновление индекса >>
Наверх Назад Turtle
 Черепаший Ранк.   Реклама на Turtle   Логотипы   Правовая информация   Конфиденциальность   Контакты 
    ©ЗАО "Группа компаний Стек". 2003-2007