Добавить Архитектура Запросы сейчас Цифры и факты FAQ Кнопка поиска Сделать стартовой |
3.11 Борьба за компактность. Компрессия.
Казалось бы, что здесь рассуждать? Так как мы строим высокотехнологичную систему, способную индексировать данные мировой паутины web-документов, то в целях экономии места в хранилище индекса также, как и при сохранении самих образов документов, следует использовать один из методов компрессии. Не торопитесь делать поспешные выводы.Мы провели некоторые исследования поведения различных доступных нам реализаций компрессоров данных. Эти исследования говорят о том, что в использовании методов компрессии для работы с поисковым индексом не все так однозначно. Так, например, скорость сжатия данных при помощи библиотеки функций GZIP (ZLIB_VERSION "1.1.4") составляет около 1MB в секунду, а скорость обратной операции извлечения данных составляет около 20MB в секунду на доступном нам реальном железе. Вспомним о том, какими объемами данных нам приходится оперировать для построения индекса. Реально для российской модели поиска, упомянутой в начале, это означает, что если мы производим обновление индекса, в котором информация хотя бы по половине поисковых терминов изменилась (суммарный объем половины данных индекса положим равным 250GB), то на разбор этой пачки мы потратим три с половиной часа, а на сбор новой пачки еще трое суток. А ведь это не самая важная операция обновления индекса.
Вспомним также о том, что мы поставили задачу: как можно быстрее обслужить поисковый запрос. Применительно к данным по частотным словам, такие задачи явно противоречат попытке экономии места за счет компрессии, т.к. скорость декомпрессии уступает скорости чтения с диска (или массива дисков). Если взять для рассмотрения "среднюю" корзину данных в 10МБ, то только на ее разбор потребуется полсекунды. При этом мы собираемся потратить на исполнение всего запроса несколько секунд, максимум.
Кроме того, на разных типах данных разные методы могут показывать различные временные и качественные показатели. Например, данные, полученные с помощью компьютерной генерации псевдослучайных чисел, вообще не поддаются сжатию, и понятно почему, они просто не содержат в себе регулярности. Впрочем, не все так печально. В любом случае, прежде чем принять решение об использовании компрессионных методов, следует попробовать эти методы на реальных данных индекса поисковой системы.
Какие практические выводы мы сделали?
В самом деле, никто не ставил задачу минимального времени отклика системы на поисковый запрос. Мы ставим задачу получения ответа на такой запрос в разумный интервал времени. Значит, компрессию данных применять можно, учитывая вышеизложенные соображения.
- Популярный пакет BZIP2 для данных задач использовать принципиально нельзя по причине плохих скоростных характеристик. По этим показателям он в 2-5 раз уступает GZIP, хоть и имеет некоторые преимущества в компактности.
- Компрессию в данных индекса использовать можно. Мы для себя выбрали функцию сжатия GZIP с уровнем 5. Программное обеспечение должно быть разработано таким образом, чтобы включение и выключение компрессии можно было бы производить конфигурационно, без полного перестроения индекса.
- Единицей для сжатия за одну операцию может являться "корзина" (или ее часть - см. выше). Существует некая критическая точка минимального размера данных для сжатия, ниже которой пытаться сжимать данные не имеет смысла (мы попусту тратим время без выигрыша дискового пространства).
- Существует вторая критическая точка размера данных "корзины", выше которой использование стандартных методов декомпрессии становится невозможным по причине того, что при поиске мы не сможем уложиться в заданный максимальный временной интервал.
- Для больших "корзин" можно использовать компрессоры, имеющие худшую степень сжатия, но лучшую скорость компрессии/декомпрессии (нами был выбран один из методов библиотеки LZO lzo-1.07.tar.gz).
Оговорюсь в конце, что здесь мы говорили об исследованиях компрессии данных без потерь информативности и, исключительно, применительно к реальным двоичным данным нашего индекса "Turtle". Возможно, при проектировании другой поисковой системы с другой архитектурой результаты будут иными. С отчетом, содержащем таблицы замеров и графики, об исследовании методов компрессии, применительно к нашему случаю, можно познакомиться здесь.
Черепаший Ранк. Реклама на Turtle Логотипы Правовая информация Конфиденциальность Контакты |
©ЗАО "Группа компаний Стек". 2003-2007 |