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

Question

Я знаю, что этот вопрос задан довольно много раз, но у меня нет удовлетворительного ответа.

Я прочитал много блогов, и большинство из них говорит, что СУРБД нельзя масштабировать по горизонтали. Единственный способ справиться с этим - покупка больших машин.

Затем я читаю, почему их нельзя масштабировать горизонтально. Люди говорят, потому что они обеспечивают надежные, зрелые услуги в соответствии с свойствами ACID. Мой аргумент заключается в том, что мы не можем отказаться от RDBMS для предоставления свойств ACID для определенных таблиц. Это единственная причина, по которой ее нельзя масштабировать горизонтально, и мы должны рассматривать базы данных NoSQL.

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

Это также позволяет разработчикам развиваться без необходимости преобразования структур памяти в реляционные структуры.

Вкратце, можем ли мы заставить РСУБД вести себя как база данных NoSQL и сделать ее масштабируемой по горизонтали?

Answer 1

Во-первых - что вы подразумеваете под «масштабированием по горизонтали»?

Для меня - масштабирование по горизонтали - это то, что мы делаем в базах данных MPP (Massive Parallel Processing) - таких как Vertica, Teradata, DB2 Parallel Edition, NonStop SQL и т. Д .: У вас очень большая таблица, которую вы равномерно распределяете по всем все узлы вашего кластера MPP, основанные, как правило, на хэш-значение первичного ключа или что-то подобное. Это то, что делает Hadoop и вся другая архитектура Map-Reduce, хотя и часто менее эффективны, по крайней мере, на данный момент).

(только для уточнения): Если у вас 10 узлов в вашем кластере, ваши большие таблицы распределены, чтобы иметь одну десятую их данных на каждом узле. Теперь масштабирование будет состоять в том, чтобы добавить, например, 10 узлов и повторно распределить данные, чтобы каждая таблица имела 1/20 своих данных на каждом узле. И базы данных MPP линейно масштабируются; это означает, что путем удвоения количества узлов с тем же объемом данных запросы будут выполняться в два раза быстрее.

Вы, кажется, имеете в виду нечто иное - и мне любопытно, что вы могли бы означать.

Как RDBMS, имеющих разделить все на несколько таблиц:

«R» в РСУБД означает «реляционная». Прежде чем вводить обсуждение всего этого, вы должны прочитать базовый учебник по реляционной алгебре . Отношение - это просто набор объектов, которые могут быть описаны с одинаковыми атрибутами. При этом все объекты имеют одинаковые атрибуты/colums/fields. Как только это правило нарушается, оно больше не является отношением/таблицей.

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

Это большой, большой мир, который у вас будет возможность исследовать.И все это сводится к теории множеств и булевой и реляционной алгебре. И вы можете сделать так много всего с этим ...

Ваш вопрос здесь так же, как спросить, почему у велосипеда два колеса.

Или я что-то упускаю?

Marco the Sane