Сжатие
Почти во всех параллельных СУБД (включая СУБД-X Vertica) допускается опциональное сжатие хранимых данных. Нередко при сжатии данных удается сократить требуемый объем памяти в 6-10 раз. Внутреннее представление данных в Vertica в высшей степени оптимизировано для сжатия данных, и обработчик запросов работает напрямую со сжатыми данными (т.е. по мере возможности избегает распаковки данных при их обработке). Как правило, поскольку аналитические задачи над большими наборами данных часто тормозятся вводом-выводом, жертвование циклами ЦП (требуемыми для распаковки входных данных) в пользу пропускной способности ввода-вывода (сжатие данных позволяет считывать меньше данных с диска) является правильной стратегией и приводит к более быстрому выполнению задач. В ситуациях, в которых обработчик запросов может оперировать прямо со сжатыми данными, часто вообще не требуются никакие компромиссы, и сжатие, очевидно, всегда приносит пользу.
В системе Hadoop и распределенной файловой системе, на которую Hadoop опирается, поддерживается сжатие входных данных на уровне блоков и на уровне записей. Однако авторы обнаружили, что ни тот, ни другой метод не повышает производительность Hadoop, а в некоторых случаях даже замедляет выполнения программ. Кроме того, при использовании сжатия со стороны пользователей требуется больше усилий по изменению кода или подготовке входных данных. Следует также заметить, что сжатие данных не использовалось и в исходном тестовом наборе .
Чтобы использовать в Hadoop сжатие на уровне блоков, сначала требуется разбить файлы данных на несколько более мелких файлов в локальной файловой системе каждого узла, а затем сжать каждый файл с использованием инструмента gzip. Сжатие данных таким способом сокращает каждый набор данных на 20-25% от его исходного размера. Затем эти сжатые файлы копируются в HDFS ровно так же, как если бы они были плоскими текстовыми файлами. Hadoop автоматически определяет, когда файлы являются сжатыми, и автоматически распаковывает их «на лету», когда они передаются экземплярам Map, так что для использования сжатых данных не приходится изменять MR-программы. Несмотря на большее время загрузки (если включать в него время на разбиение и сжатие файлов), Hadoop, использующий сжатие на уровне блоков, замедляет выполнение большинства задач на несколько секунд, а задачи, для которых требуются в основном ресурсы процессора, выполнялись на 50% дольше.
Авторы также пытались выполнять тестовые задачи с использованием сжатия на уровне записей. Для этого требовалось (1) написать собственный класс tuple с использованием Hadoop API, (2) модифицировать программу загрузки данных, чтобы она сжимала записи и сериализовала получаемые кортежи, и (3) произвести рефакторинг всех тестовых задач. Вначале имелась надежда, что это позволит повысить производительность задач с высокими требованиями к ресурсам ЦП, поскольку задачам Map и Reduce больше не требовалось расщеплять поля по разделителю. Однако было установлено, что этот подход обеспечивает производительность, еще более низкую, чем сжатие на уровне блоков, сжимая данные только на 10%.
