Logo Море(!) аналитической информации!
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware
VPS/VDS серверы. 30 локаций на выбор

Серверы VPS/VDS с большим диском

Хорошие условия для реселлеров

4VPS.SU - VPS в 17-ти странах

2Gbit/s безлимит

Современное железо!

Бесплатный конструктор сайтов и Landing Page

Хостинг с DDoS защитой от 2.5$ + Бесплатный SSL и Домен

SSD VPS в Нидерландах под различные задачи от 2.6$

✅ Дешевый VPS-хостинг на AMD EPYC: 1vCore, 3GB DDR4, 15GB NVMe всего за €3,50!

🔥 Anti-DDoS защита 12 Тбит/с!

2010 г.

HadoopDB: архитектурный гибрид технологий MapReduce и СУБД для аналитических рабочих нагрузок

Азза Абузейд, Камил Байда-Павликовски, Дэниэль Абади, Ави Зильбершац, Александр Разин
Перевод: Сергей Кузнецов

Назад Содержание Вперёд

6. Тестовые испытания

В этом разделе мы оцениваем систему HadoopDB, сравниваем ее с реализацией MapReduce и двумя реализациями параллельных систем баз данных, используя тестовый набор, впервые представленный в [23]4. Этот тестовый набор состоит из пяти задач. Первая из них взята прямо из исходной статьи про MapReduce [8], авторы которой называют ее характерным представителем распространенных задач MR. Следующие четыре задачи являются аналитическими запросами, представляющими характерную рабочую нагрузку анализа структурированных данных, на поддержку которой ориентируется HadoopDB.

Мы проводили свои эксперименты на "крупных" экземплярах Amazon EC2 (зона us-east-1b). В каждом экземпляре имелось 7,5 гигабайт основной памяти, 4 вычислительных блока EC2 (2 виртуальных ядра), 850 гигабайт дисковой памяти (2 × 420 гигабайт плюс 10-гигабайтный корневой раздел). В качестве операционной системы использовалась 64-битная Linux Fedora 8.

Поначалу производительность дискового ввода-вывода в узлах EC2 была довольно низкой (25 мегабайт в секунду). Впоследствии мы инициализировали в каждом узле некоторое дополнительное дисковое пространство, чтобы это исходное замедление не сказывалось на скорости записи промежуточных файлов и результатов задач. После инициализации этого дискового пространства последующие операции записи выполнялись гораздо быстрее (86 мегабайт в секунду). Скорость сети составляла примерно 100-110 мегабайт в секунду. Каждая задача выполнялась по три раза, и фиксировались средние результаты. Окончательные результаты запросов, выполняемых в параллельных системах баз данных, отправлялись из команды shell в файл через программный канал (pipe). Hadoop и HadoopDB сохраняли результаты в HDFS. В этом разделе мы приводим результаты только тех прогонов, в которых все узлы были доступными, работали корректно, и во время выполнения тестов отсутствовали одновременно выполняемые задачи (в разд. 7 мы отказываемся от этих требований). Для каждой задачи производительность измерялась на кластерах из 10, 50 и 100 узлов.

6.1. Испытываемые системы
В наших экспериментах сравнивалась производительность Hadoop, HadoopDB (с PostgreSQL5 в качестве основой СУБД) и две коммерческие параллельные СУБД.
6.1.1. Hadoop
Hadoop – это версия с открытыми кодами среды MapReduce, реализованная под непосредственным влиянием идей исходной статьи про MapReduce и используемая сегодня в десятках компаний для выполнения анализа данных [1]. В описываемых в данной статье экспериментах мы использовали систему Hadoop версии 0.19.1, выполняемую в среде Java 1.6.0. Мы устанавливали систему с несколькими изменениями в конфигурационных установках, используемых по умолчанию. Данные в HDFS сохранялись в блоках размером 256 мегабайт вместо размера в 64 мегабайта, принимаемого по умолчанию. Каждый исполнитель MR работал с кучей максимального размера в 1024 мегабайта. В каждом узле допускалось одновременное выполнение двух экземпляров Map и одного экземпляра Reduce. Мы также расширили буферное пространство для операций чтения-записи файлов и увеличили буфер сортировок до 200 мегабайт (со ста параллельными потоками для слияния). В дополнение к этому, мы изменили число параллельных пересылок, выполняемых функцией Reduce на фазе "перетасовки" (shuffle), и число рабочих потоков управления для каждого HTTP-сервера компонента TaskTracker до 50. Эти настройки соответствуют принципам организации высокопроизводительных кластеров Hadoop [13]. Кроме того, мы допустили повторное использование JVM (Java Virtual Machine).

Для каждого прогона мы сохраняли все входные данные и результаты в HDFS без репликации (в разд. 7 мы добавляем репликацию). После прогона тестов на кластере конкретного размера мы удаляли во всех узлах каталоги данных, заново форматировали и загружали HDFS, чтобы обеспечить равномерное распределение данных между всеми узлами.

Мы представляем результаты как для Hadoop с кодированием вручную, так и для Hadoop с использованием Hive (т.е. планы Hadoop генерировались автоматически на основе SQL-интерфейса Hive). Эти результаты для Hadoop на диаграммах показаны путем разделения соответствующих столбцов на две части. В нижней части показано время, затраченное Hadoop при выполнении заданий, которые кодировались вручную, а верхняя часть демонстрирует дополнительные накладные расходы, затраченные на автоматическую генерацию плана системой Hive, а также на вызовы функций и динамическое разрешение типов данных через Java Reflection API при обработке каждого кортежа в задании, код которого получен путем использования Hive.

6.1.2. HadoopDB
Система Hadoop, используемая внутри HadoopDB, конфигурировалась точно так же, как описывалось в предыдущем пункте, за исключением того, что в узлах не допускалось одновременное выполнение нескольких задач map. Кроме того, в каждом рабочем узле инсталлировалась СУБД PostreSQL 8.2.5. Объем основной памяти, используемой для разделяемых буферов, был увеличен до 512 мегабайт, а объем рабочей памяти – до 1 гигабайта. Сжатие данных в PostreSQL не применялось.

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

6.1.3. Vertica
Vertica – это относительно новая параллельная система баз данных (первый выпуск вышел в 2005 г.) [3], основанная на исследовательском проекте C-Store [24]. Vertica является поколоночным хранилищем данных (column-store), т.е. каждый атрибут каждой таблицы хранится (и к нему обеспечивается доступ) по отдельности. Было показано, что этот метод позволяет повысить производительность системы на рабочих назрузках, содержащих, главным образом, запросы на выборку данных.

У системы Vertica имеется "облачная" редакция, которую мы и использовали в экспериментах, описываемых в этой статье. Vertica использовалась для сравнения производительности систем и в предыдущем исследовании [23] на том же тестовом наборе, поэтому мы конфигуривали эту систему таким же образом, как и раньше 6. Таким образом, у Vertica имелась следующая конфигурация. Все данные были сжаты, и Vertica работала прямо со сжатыми данными. Первичные индексы реализовывались путем сортировки таблиц по индексному атрибуту. Параметры конфигурирования Vertica, используемые по умолчанию, не изменялись.

6.1.4. СУБД-X
СУБД-X – это та же самая коммерческая система баз данных с хранением данных по строкам, которая использовалась для экспериментов в [23]. Поскольку ко времени представления этой статьи на конференцию VLDB облачной редакции этой СУБД не было, мы не могли экспериментировать с ней в среде EC2. Однако, поскольку наши эксперименты с СУБД Vertica в среде EC2 показали снижение ее производительности на 10-15% по сравнению с аналогичными экспериментами на Висконсинском кластере, описанными в [23]7, (этого следовало ожидать, поскольку известно, что уровень виртуализации приводит к образованию накладных расходов), в своих цифрах мы воспроизводим показатели СУБД-X из [23], считая их оценкой сверху производительности СУБД-X, если бы она работала в среде EC2.

4 Нам известно правило для авторов, запрещающее использовать ссылки на литературу в качестве имен существительных. Однако для экономиии места здесь мы используем [23] не как ссылку, а как сокращенную форму выражения "статья Павло и др. из трудов конференции SIGMOD 2009".

5 Сначала мы экспериментировали с MySQL (уровень хранения MyISAM). Однако мы обнаружили, что хотя простые сканирования таблиц выполнялись на 30% быстрее, более сложные запросы обрабатывались намного медленнее из-за отсутствия кластеризованных индексов и слабых алгоритмов соединения.

6 На самом деле, мы попросили того же человека, который пропускал запросы на Vertica в предыдущем исследовании, пропустить те же запросы в среде EC2.

7 В своих экспериментах мы использовали более позднюю версию Vertica, чем в [23]. Замедление в среде EC2 по-преднему сохранилось в пределах 10-15%.

Назад Содержание Вперёд

VPS в России, Европе и США

Бесплатная поддержка и администрирование

Оплата российскими и международными картами

🔥 VPS до 5.7 ГГц под любые задачи с AntiDDoS в 7 локациях

💸 Гифткод CITFORUM (250р на баланс) и попробуйте уже сейчас!

🛒 Скидка 15% на первый платеж (в течение 24ч)

Скидка до 20% на услуги дата-центра. Аренда серверной стойки. Colocation от 1U!

Миграция в облако #SotelCloud. Виртуальный сервер в облаке. Выбрать конфигурацию на сайте!

Виртуальная АТС для вашего бизнеса. Приветственные бонусы для новых клиентов!

Виртуальные VPS серверы в РФ и ЕС

Dedicated серверы в РФ и ЕС

По промокоду CITFORUM скидка 30% на заказ VPS\VDS

Новости мира IT:

Архив новостей

IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

Информация для рекламодателей PR-акции, размещение рекламы — adv@citforum.ru,
тел. +7 495 7861149
Пресс-релизы — pr@citforum.ru
Обратная связь
Информация для авторов
Rambler's Top100 TopList This Web server launched on February 24, 1997
Copyright © 1997-2000 CIT, © 2001-2019 CIT Forum
Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...