HadoopDB архитектурный гибрид технологий



             

От переводчика: параллельная СУБД для бедных или путь в будущее?


Зародившаяся в недрах Google технология MapReduce не дает покоя сообществу баз данных. Действительно, обидно. С несравненно меньшими усилиями, чем те, которые были затрачены в течение десятилетий сотнями исследований на разработку архитектурных и технологических приемов построения параллельных СУБД (имеются в виду СУБД категории sharing nothing), в MapReduce удалось элегантно решить проблемы масштабируемости и отказоустойчивости.

Первая реакция авторитетных представителей сообщества баз данных состояла в (достаточно убедительных) попытках показать, что MapReduce не может конкурировать с параллельными СУБД по производительности. В статье Майкла Стоунбрейкера (Michael Stonebraker) и др. определялся тестовый набор и описывались результаты экспериментов, показывающие, что при решении простых, но типичных аналитических задач параллельные системы баз данных демонстрируют производительность, на порядок превышающую производительность Hadoop – свободно доступной реализации MapReduce.

Я много раз хвалил эту статью. Она действительно написана на основании очень качественного экспериментального материала, носит достаточно объективный характер. Но одна из основных идей этой статьи (хотя и не особенно подчеркиваемая в ее тексте) состоит в том, что масштабируемость и отказоустойчивость MapReduce при имеющихся сегодня и ожидаемых в обозримом будущем объемах аналитических данных просто не требуются. Крупнейшие на сегодняшний день аналитические базы данных петабайтного масштаба поддерживаются параллельными СУБД, работающими на кластерах без общих ресурсов с менее чем сотней узлов, а преимущества MapReduce начинают сказываться при работе с кластерами из тысяч узлов.

Кстати, замечу, что эта идея почти исчезла в более поздней статье Стоунбрейкера и др. . В ней по-прежнему почти ничего не говорится про отказоустойчивость, но отмечается, что не видны объективные причины, которые могут помешать линейному масштабированию до тысяч узлов имеющихся сегодня параллельных СУБД. Другими словами, когда возникнет потребность в обработке данных, для которых при использовании параллельных СУБД понадобятся кластеры с тысячами или десятками тысяч узлов, тогда мы с большой вероятностью настолько же эффективно, как сегодня, сможем применить существующие системы.




Содержание    Вперед