в этой статье, можно сделать
На основе результатов, представленных в этой статье, можно сделать ряд интересных выводов. Во-первых, в масштабе выполненных экспериментов обе параллельные системы продемонстрировали существенное превосходство в производительности над Hadoop при выполнении ряда тестовых задач анализа данных большого объема. В среднем для всех пяти задач на кластере из 100 узлов СУБД-X оказалась в 3.2 раза быстрее MR, а Vertica – в 2.3 раза быстрее СУБД-X. Хотя авторы не могут проверить это утверждение, они полагают, что те же относительные показатели производительности сохранились бы и на кластере с 1000 узлов (самая крупная конфигурация Teradata на кластере с менее чем 100 узлами управляет данными объемом более четырех петабайт). Эти цифры можно истолковать так, что параллельные системы баз данных, обеспечивающие то же самое время отклика при использовании меньшего числа процессоров, безусловно, будут потреблять намного меньше энергии; модель MapReduce на кластере с несколькими тысячами узлов является решением грубой силы, растрачивающим огромные объемы энергии. Хотя ходят слухи, что версия MR от Google быстрее версии Hadoop, у авторов статьи не было доступа к этому коду, и поэтому они не могли его протестировать. Однако они сомневаются, что эти две версии MR показали бы существенную разницу в производительности, поскольку MR вынуждает всегда начинать выполнение запроса с просмотра всего входного файла.
Это преимущество в производительности, свойственное обеим системам баз данных, является результатом применения ряда технологий, разработанных в последние 25 лет, включая (1) индексы в виде B-деревьев, ускоряющие выполнение операций выборки, (2) новые механизмы хранения данных (например, поколоночное хранение), (3) эффективные методы сжатия данных с возможностью выполнять операции прямо над сжатыми данными, (4) сложные параллельные алгоритмы для выполнения запросов над большими объемами реляционных данных. В случае применения поколоночных систем баз данных, подобных Vertica, с диска считываются только те столбцы, которые требуются для выполнения запроса.
Кроме того, поколоночное хранение позволяет добиться лучших показателей сжатия данных (в Vertica они сжимаются примерно в 2.0 раза, в СУБД-X – в 1.8 раз, а в Hadoop – в 1.25 раз). Это тоже способствует сокращению объема дискового ввода-вывода при выполнении запросов.
Хотя авторы не были удивлены относительным превосходством в производительности двух параллельных систем баз данных, на них произвела впечатление простота установки Hadoop и использования этой системы по сравнению с системами баз данных. Процесс инсталляции Vertica тоже был несложным, но чувствительным к некоторым системным параметрам. С другой стороны, СУБД-X было трудно сконфигурировать должным образом, и потребовалась неоднократная помощь от представителей компании-поставщика для получения правильно работающей конфигурации. В целом, установка и конфигурирование такого зрелого продукта, как СУБД-X, произвели на авторов неутешительное впечатление. Учитывая безусловное стоимостное преимущество Hadoop, можно понять, почему эта система так быстро привлекла к себе крупное сообщество пользователей.
Еще одной областью, в которой во время тестирования систем баз данных были обнаружены недостатки, является расширяемость. Идее расширения СУБД определяемыми пользователями типами и функциями уже 25 лет [16]. Тем не менее, ни одна из тестируемых параллельных систем не смогла хорошо справиться с задачей агрегации с применением UDF, заставив авторов искаться обходные пути при обнаружении ограничений (например, в Vertica) или ошибок (например, в СУБД-X).
Хотя системы баз данных устойчивы к разнообразным программным сбоям, нет никаких сомнений, что MR лучше справляется с минимизацией потерь уже выполненной работы при возникновении аппаратных сбоев. Однако эта возможность потенциально сопровождается крупным ухудшением производительности из-за расходов на материализацию промежуточных файлов между фазами Map и Reduce. Пока неясно, насколько существенно это ухудшение. К сожалению, для должного исследования этого вопроса требуется реализация в одной среде стратегий с материализацией и без нее, а такая работа не предусматривалась в исследованиях, которым посвящена данная статья.
Несмотря на очевидное преимущество Hadoop в этой области, не совсем ясно, насколько существенна устойчивость систем к аппаратным сбоям при их реальном практическом использовании. Кроме того, если для системы MR требуется 1000 узлов для достижения производительности параллельной системы баз данных, работающей на ста узлах, то для первой системы вероятность отказа узла при обработке запроса в десять раз больше, чем для второй. Тем не менее, от улучшенной устойчивости не отказался бы ни один пользователь баз данных.
Многие люди считают, что SQL поначалу трудно использовать. Частично это связано с тем, что при решении проблем с использованием SQL требуется несколько иной стиль мышления, и с тем, что SQL превратился в сложный язык, который существенно отличается от исходной разработки, выполненной Доном Чемберлином (Don Chamberlin) в 1970-х гг. Хотя большинство языков со временем усложняется, SQL особенно плох, поскольку многие его средства разрабатывались конкурирующими компаниями-поставщиками СУБД, каждая из которых стремилась включить в язык собственные проприетарные расширения.
Несмотря на свои недостатки, SQL по-прежнему является мощным инструментом. Рассмотрим запрос для генерации списка служащих, упорядоченного по заработной плате, причем для каждого служащего должен указываться еще и уровень его зарплаты (уровень зарплаты служащих, получающих максимальную зарплату, равен единице). На SQL этот запрос можно сформулировать следующим образом:
SELECT Emp.name, Emp.salary, RANK() OVER (ORDER BY Emp.salary) FROM Employees AS Emp
При параллельном выполнении этого запроса требуется полностью упорядочить всех служащих, после чего выполняется вторая фаза, на которой в каждом узле значения уровня для содержащихся в нем записей корректируются счетчиками числа записей со всех узлов «слева» от данного (т.е. тех узлов, в которых значения зарплаты строго меньше). Хотя MR-программа могла бы параллельно выполнить эту сортировку, не так просто подстроить этот запрос под парадигму MR группировки по агрегации.
RANK – это лишь одна из многих мощных аналитических функций, поддерживаемых в современных параллельных системах баз данных. Например, и в Teradata, и в Oracle поддерживается развитый набор функций, таких как функции над окнами упорядоченных записей.
Два архитектурных различия, похоже, сохранятся в течение длительного времени. MR следует парадигме «схема потом» или даже «вообще без схемы». Но это отсутствие схемы влечет ряд важных последствий. Прежде всего, это означает неизбежность разбора записей во время выполнения, в том время как СУБД производят разбор во время загрузки данных. Это различие делает менее полезным сжатие данных в среде MR и служит частичным источником различия в производительности между двумя классами систем. Во-вторых, схема требуется для поддержки информации, важной для оптимизации декларативных запросов, включая информацию о существующих индексах, разделении таблиц, мощности таблиц, а также гистограммы, представляющие распределения значений в столбцах.
По мнению авторов, для обоих видов систем можно еще многое сделать. Наиболее важны появление над базисным уровнем MR интерфейсов более высокого уровня, таких как Pig [15] и Hive [2], а также разработка инструментов, близких по духу к MR, но более выразительных, таких как Dryad [13] и Scope [5]. Это упростит кодирование сложных задач в MR-подобных системах и устранит одно из больших преимуществ SQL-ориентированных систем – меньшие трудозатраты на кодирование задач. Что касается параллельных систем баз данных, как коммерческих, так и с открытыми исходными текстами, авторы полагают, что в них будет существенно усовершенствован параллелизм функций, определяемых пользователями. Таким образом, API обеих классов систем, очевидно, сближаются. Первыми признаками этого являются решения по интеграции SQL и MR от компаний Greenplum и Asterdata.
