Почему реляционные базы данных не могут соответствовать масштабам больших данных?


17

Часто повторяется, что проблема больших данных заключается в том, что реляционные базы данных не могут масштабироваться для обработки огромных объемов данных, которые сейчас создаются.

Но с какими ограничениями масштабируемости не связаны решения Big Data, такие как Hadoop? Почему Oracle RAC или MySQL sharding или MPP RDBMS, такие как Teradata (и т. Д.), Не могут достичь этих умений?

Меня интересуют технические ограничения - я осознаю, что финансовые затраты на кластеризацию СУБД могут быть непомерно высокими.

Ответы:


15

MS только что выступил с технологическим докладом в Нидерландах, где они обсуждали некоторые из этих вещей. Он начинается медленно, но попадает в мясо Hadoop примерно через 20 минут.

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

Hadoop и MR кажутся более приспособленными к ситуациям, когда вы вынуждены выполнять большое количество распределенных сканирований данных, особенно когда эти данные не обязательно столь же однородны или структурированы, как то, что мы находим в мире RDBMS.

С какими ограничениями не связаны решения Big Data? Для меня самым большим ограничением, с которым они не связаны, является необходимость заранее составить жесткую схему. С помощью решений для больших данных вы теперь помещаете огромные объемы данных в «ящик» и позже добавляете логику в свои запросы, чтобы справиться с отсутствием однородности данных. С точки зрения разработчика, компромиссом является простота реализации и гибкость внешнего интерфейса проекта по сравнению со сложностью запросов и менее оперативной согласованностью данных.


Спасибо, Дэйв, вы приближаете меня к тому, что я пытаюсь выяснить. Вы говорите, что Hadoop ориентирован на ситуации с большими распределенными сканированиями - если некоторые / многие СУБД имеют кластерные решения (RAC, сегменты, MPP и т. Д.), Почему они также не могут это делать? Что делает СУРБД невозможной для сортировки 10 триллионов записей за 16 часов, как это может сделать очень большой кластер Hadoop? смотрите здесь
Джереми Борода

2
Ничто не делает невозможным выполнение кластером RDBMS такого рода работы, и вы можете настроить RDBMS для масштабирования для выполнения подобных задач. Проблема с СУБД состоит в том, что для этого вам нужно быть очень осторожным с тем, как вы структурируете свою схему и разделы, чтобы она работала. Архитектура больших данных выигрывает, когда ваши данные недостаточно структурированы, чтобы их можно было легко или эффективно разделить и оптимизировать в СУБД.
Дэйв Маркл

1
Некомпетентные дизайнеры БД затрудняют масштабирование реляционных баз данных. Слишком много компаний считают, что разработчики приложений могут проектировать базы данных (или, что еще хуже, использовать ORMS для разработки), когда им нужно с самого начала нанять компетентных разработчиков баз данных. Второй человек, которого вы нанимаете для проекта, который включает данные, должен быть разработчиком базы данных.
HLGEM

3
@HLGEM: Мой ответ на это, "Мех". Наиболее эффективными разработчиками будут те, которые понимают обе стороны стека - идея о том, что существует такая вещь, как хороший «разработчик приложений», который все время работает с СУБД, не зная, как она работает, является ошибкой , Аналогично, идея о том, что существует такая вещь, как хороший «разработчик базы данных», который не понимает ORM или сторону приложения, также является ошибкой в ​​IMO.
Дейв Маркл

6

Пионер и исследователь базы данных Майкл Стоунбрейкер выступил соавтором статьи, в которой обсуждаются ограничения традиционных архитектур баз данных. Как правило, они масштабируются на более дорогом оборудовании, но им трудно масштабировать параллельно с большим количеством стандартного оборудования, и они ограничены устаревшей архитектурой программного обеспечения, разработанной для более старой эпохи. Он утверждает, что эпоха BigData требует нескольких новых архитектур баз данных, которые используют преимущества современной инфраструктуры и оптимизируются для конкретной рабочей нагрузки. Примерами этого являются проект C-store, который привел к созданию коммерческой базы данных Vertica Systems, и проект H-store, который привел к VoltDB, базе данных OLTP SQL в памяти, предназначенной для высокоскоростных рабочих нагрузок BigData. (Полное раскрытие, я работаю на VoltDB).

Вы можете найти этот вебинар интересным на эту тему. Это отвечает на некоторые из мифов, которые возникли с успехом баз данных NoSQL. По сути, он утверждает, что SQL не был проблемой, поэтому для достижения производительности не нужно отказываться от традиционных функций базы данных, таких как согласованность.


6
Чтобы квалифицироваться как полное раскрытие, вы, вероятно, должны также упомянуть, что ваш соучредитель и технический директор Майкл Стоунбрейкер также был соавтором всех ваших примеров. И эта поддержка SQL в VoltDB представляет собой довольно маленькое подмножество .
Даниэль Лайонс

5

Не совсем верно, что СУБД не может масштабироваться. Однако частичная правда в утверждении зависит от архитектуры. В приведенном вами списке Oracle RAC отличается от остальных (заштрихованные MySQL и Teradata). Основное отличие состоит в том, что разделяемый диск отличается от разделяемых архитектур.

Архитектуры совместно используемых дисков, такие как Oracle RAC, страдают от масштабирования, поскольку в какой-то момент все работающие машины должны синхронизироваться с какой-то частью данных. Например, глобальный менеджер блокировок - убийца. Вы можете настроить его до некоторой степени, но в конечном итоге вы попадете в стену. Если вы не можете легко добавлять машины, у вас должно быть меньше, но очень мощных машин, которые могут сжечь ваш карман. В случае архитектур без общего доступа (или данных с разделением) каждая машина становится владельцем некоторых данных. Он не должен синхронизироваться с другими машинами, если он хочет обновить некоторые данные.

Затем идет порода баз данных NoSQL. Я бы отнес их к подмножеству традиционных баз данных СУБД. Не всем приложениям в этом мире понадобятся все функции, предлагаемые СУБД. Если я хочу использовать базу данных в качестве кеша, я не буду заботиться о долговечности. Может быть, в некоторых случаях я бы тоже не заботился о последовательности. Если весь мой поиск данных основан на ключе, мне не нужна поддержка запросов диапазона. Возможно, мне не нужны вторичные индексы. Мне не нужен весь уровень обработки запросов / оптимизации запросов, который есть во всех традиционных базах данных.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.