DBMS Cost-Based Optimizers: Back Story and State of the Art

Query optimizers for relational databases have come a long evolutionary way to grow into complicated algorithms for assessing the costs of various options. However, the new generation databases pay almost zero attention to a query cost. What is it, a step back or two steps ahead? Do we even need new cost optimizers for the big data world at all?

В журнале Открытые системы №1, 2016 вышла моя статья Стоимостные оптимизаторы для СУБД: вчера и сегодня

В ней я пытаюсь рассуждать о стоимостной оптимизации в Oracle, Vertica и SparkSQL. Кажется, в области стоимостной оптимизации предстоит решить ещё множество интересных задач.

Advertisements
DBMS Cost-Based Optimizers: Back Story and State of the Art

Hadoop на распутье?

5 августа Майкл Стоунбреейкеер в своём блоге опубликовал интересную заметку Hadoop at a Crossroads?  

Ниже мой (местами вольный :)) перевод этой заметки. Кажется, что её нужно читать “на одном дыхании”, не отвлекаясь на необходимость переводить на родной язык.


 

С моего последнего в этом блоге постинга в 2012 году совместно с Джереми Кепнером (Jeremy Kepner) утекло уже много воды, и я считаю своим долгом указать на некоторые факты и мнения, а также сообщить о паре анонсов. В заключение я сделаю предположение о том, куда же “стек Hadoop” движется.

Первый анонс – выпуск Cloudera релиза новой DBMS Impala [2], работающей на HDFS. Упрощенно говоря, Impala спроектирована ровно также, как и все остальные параллельные shared-nothing SQL СУБД, работающие на рынке витрин данных. Особенно стоит отметить, что в релизе отказались от слоя MapReduce, и заслуженно. Как некоторые из нас доказывают уже на протяжении нескольких лет, MapReduce непрактичен для использования в качестве основного интерфейса внутри SQL (или Hive) СУБД [3,4]. Impala была спроектирована весьма здравомыслящими разработчиками СУБД, знакомыми с этими парадигмами. В действительности, схожая с Impala активность наблюдалась и среди разработчиков HortonWorks и FaceBook. Это, конечно же, поставило поставщиков Hadoop перед диллемой. Исторически Hadoop-ом называют open-source версию MapReduce, написанную Yahoo. Однако Impala выкинула этот слой из стека. Как же в этом случае можно быть поставщиком Hadoop, если сам Hadoop в его первоначальном смысле больше не является частью основного стека?

Ответ прост: переопределить термин “Hadoop”, и это ровно то, что было сделано поставщиками. Слово “Hadoop” теперь используется для обозначения всего стека. Иными словами, в основе HDFS, поверх которой запускается Impala, MapReduce и другие системы. Поверх этих систем работает высокоуровневое ПО типа Mahout. Слово “Hadoop” используется для обозначения всего набора.

Второй свежий анонс пришёл от Google, который объявил, что MapReduce – вчерашние новости и они идут дальше, строя свои программные решения поверх лучших систем, таких как Dremmel, Big Table, и F1/Spanner [5]. Вообще, Google должно быть тихонько посмеивается сейчас. Они изобрели MapReduce с целью поддержки процесса обхода web для своего поискового движка в 2004. Через несколько лет они заменили в своих приложения MapReduce на BigTable, потому что хотели интерактивную систему хранения, в то время как MapReduce обеспечивает только пакетную обработку. Так что основное приложение, использующее MapReduce, уже давно сменило платформу на лучшую. И теперь Google сообщает, что они не видят в будущем необходимости в MapReduce.

Весьма иронично, что Hadoop продолжает получать поддержку основной части сообщества уже около пяти лет после того, как Google перешёл на использование лучших технологий. Таким образом, весь остальной мир следует за Google в мир Hadoop с отставанием почти в десятилетие. А Google уже давно отказался от MapReduce. Интересно, сколько времени всему остальному миру понадобиться, чтобы двинуться в том же направлении, что и Google сейчас.

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

А сейчас я хотел бы вернуться к HDFS, который остался единственным общим блоком в стеке Hadoop. Очевидно, что HDFS – файловая система, способная хранить байты данных, свойство, ожидаемое от любой вычислительной платформы. Есть два вИденья, куда HDFS могло бы двинуться в будущем. Если принять точку зрения будущего как файловой системы, то пользователям нужна обычная распределенная файловая система и HDFS – отличная разумная альтернатива.

С другой стороны, с точки зрения параллельной SQL/Hive СУБД HDFS “хуже смерти”. СУБД ВСЕГДА хочет отправлять запрос (несколько килобайт) к данным (много гигабайт) и никогда наоборот. Так что попытка спрятать месторасположение данных от СУБД – это смерть, и СУБД пойдёт на многое, только бы избавиться от этой особенности. Все параллельные СУБД, неважно, от поставщиков витрин данных или Hadoop, обязательно отключат прозрачность (в смысле transparency, когда приложениее не знает, где физически хранятся данныее) расположения данных, заставляя HDFS вести себя как набор файловых систем Linux, одна на узел. Точно также, как ни одна СУБД не нуждается в репликах файловой системы. См. в [6] обширную дискуссию на эту тему. Вкратце, соображения балансировки нагрузки, оптимизации запросов и транзакционности играют в пользу поддержки систем репликации на уровне СУБД.

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

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

В обоих сценариях единственной общей частью ПО является файловая система, и поставщики Hadoop будут продавать основанные на файловой системе утилиты, либо только для СУБД или остальных продуктов (или, возможно, их обоих). Фактически они присоединятся к когорте поставщиков системного ПО, продающих ПО или сервисы. Возможно победит лучший продукт!

 

Ссылки:

[1] http://cacm.acm.org/blogs/blog-cacm/149074-possible-hadoop-trajectories/fulltext

[2] http://www.cloudera.com/content/cloudera/en/products-and-services/cdh/impala.html

[3] http://dl.acm.org/citation.cfm?id=1629197

[4] Pavlo, A. et. al., “A Comparison of Approaches to Large-Scale Data Analysis,” SIGMOD 2009.

[5] http://www.datacenterknowledge.com/archives/2014/06/25/google-dumps-mapreduce-favor-new-hyper-scale-analytics-system/

[6] Stonebraker, M., et. al., “Enterprise Data Applications and the Cloud: A Difficult Road Ahead,” Proc IEEE IC2E, Boston, Ma., March 2014

Hadoop на распутье?