Обсуждение
Следует отметить, что хотя процентное замедление Vertica было больше, чем у Hadoop и HadoopDB, ее общее время выполнения запроса (даже при наличии отказа или медленного узла) значительно меньше, чем у этих систем. Кроме того, производительность Vertica в отсутствии сбоев на порядок выше, чем у Hadoop и HadoopDB (в основном, потому, что поколоночное хранение данных обеспечивает большой выигрыш при выполнении небольших запросов с агрегацией). Hadoop и HadoopDB могут показать такую же производительность, но на кластере, у которого число узлов на порядок больше. Следовательно, для Vertica сбои и замедление работы узлов менее вероятны, чем для Hadoop и HadoopDB. Кроме того, для поддержки 6,5-гигабайтной базы данных eBay (вероятно, крупнейшего в мире хранилища данных к июню 2009 г.) используется всего лишь 96-узловой кластер без совместно используемых ресурсов. В кластерах с числом узлов меньше 100 отказы узлов возникают достаточно редко.
Мы утверждаем, что в будущем станут распространенными производственные установки систем баз данных с использованием 1000-узловых кластеров, и будут не редки случаи использования 10000-узловых кластеров. Это предсказание основывается на трех наблюдаемых тенденциях. Во-первых, объем производственных данных растет быстрее, чем диктует закон Мура (см. разд. 1). Во-вторых, становится понятно, что из соображений и соотношения "цена-производительность", и (все более важного) соотношения "потребляемая энергия-производительность" использовать много дешевых, потребляющих мало энегии серверов выгоднее, чем использовать меньшее число "тяжеловесных" серверов [14]. В-третьих, как никогда ранее требуется выполнять анализ данных внутри СУБД, а не выталкивать данные для анализа во внешние системы. В перегруженных дисками архитектурах, подобных 96-узловой системе баз данных eBay, отсутствует вычислительная мощность, требуемая для поддержки аналитических рабочих нагрузок.
Поэтому в будущем нас ожидают тяжеловесные аналитические задания над базами данных, для выполнения которых понадобится больше времени и больше узлов. Вероятность отказа в этих приложениях следующего поколения будет гораздо больше, чем сегодня, и повторное выполнение всего задания после возникновения отказа будет неприемлемым (сбои могут стать настолько частыми, что долго работающие задания никогда не закончатся!). Поэтому, хотя Hadoop и HadoopDB расплачиваются падением производительности за планирование во время исполнения, рестарт на уровне блоков и частое сохранение состояния, накладные расходы на достижение стабильной отказоустойчивости станут неизбежными. Одной из особенностей системы HadoopDB является то, что она может переходить из одного конца этого спектра в другой конец. Поскольку основной единицей обработки является чанк, при снятии ограничений на размер чанка такие системы, подобно Vertica, смогут поддерживать рабочие нагрузки, для которых требуется высокая производительность и низкая отказоустойчивость, а при использовании более мелких чанков смогут обеспечивать высокий уровень отказоустойчивости (подобно Hadoop).
