Эксперименты и их результаты
Эксперименты, описываемые в этой статье, основывались на выполнении нескольких несложных аналитических задач на кластере из ста узлов с использованием двух параллельных СУБД категории sharing-nothing (применялись СУБД Vertica и некоторая СУБД с традиционным построчным хранением данных, именуемая в статье СУБД-X) и реализации MapReduce от Hadoop. Очень интересно, как авторы обосновывают свой выбор для экспериментов относительно небольшого кластера, тогда как сторонники MapReduce обычно говорят об абсолютных преимуществах этой технологии при использовании кластеров с тысячами узлов.
Как утверждается в статье, такая масштабная аппаратура не требуется современным высокоэффективным параллельным СУБД даже при поддержке предельных в настоящее время по объему петабайтных баз данных. Например, в конфигурации СУБД Teradata, применяемой в eBay, 72 узлов (в каждом узле два четырехъядерных процессора, 32 гигабайта основной памяти и 104 300-гигабайтных диска) оказывается достаточно для управления реляционными данными объемом около 2,4 петабайт. Так что с самого начала статьи, по сути дела, утверждается, что сверхвысокая масштабируемость параллельных СУБД в действительности не требуется (заметьте, как это перекликается с тезисом Клермонтского отчета о невозможности должного масштабирования современных СУБД в облачной инфраструктуре).
При том, что авторы статьи уделили тщательное внимание программированию тестовых аналитических задач для среды MapReduce, на кластере из 100 узлов СУБД-X показала среднюю производительность, большую соответствующего варианта для MapReduce в 3,2 раза, а СУБД Vertica оказалась в 2,3 раза быстрее СУБД-X. Авторы предполагают, что те же относительные соотношения сохранились бы и на кластере с 1000 узлами, хотя такое оборудование просто не требуется для поддержки параллельными системами баз данных актуальных сегодня баз данных петабайтного масштаба.
