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

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

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

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

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

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

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

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

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

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

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

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

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