Про базы данных, такие как BigTable, SimpleDB

Question

Новые парадигмы школьных хранилищ данных, такие как Google BigTable и Amazon SimpleDB, специально разработаны, в частности, для масштабируемости. По сути, запрещение объединений и денормализация - это способы достижения этой цели.

В этой теме, однако, все согласны с тем, что объединения в больших таблицах не обязательно должны быть слишком дорогими, а денормализация в некоторой степени "переоценена" Почему же эти вышеупомянутые системы запрещают объединения и объединяют все в одной таблице для достижения масштабируемости? Это просто объем данных, которые необходимо хранить в этих системах (много терабайт)?
Разве общие правила для баз данных просто не применимы к этим шкалам? Это потому, что эти типы баз данных специально предназначены для хранения многих похожих объектов?
Или я упускаю какую-то большую картинку?

Answer 1

Распределенные базы данных не так наивны, как предполагает Орион; была проделана большая работа по оптимизации полностью реляционных запросов по распределенным наборам данных. Вы можете посмотреть, что делают такие компании, как Teradata, Netezza, Greenplum, Vertica, AsterData и т. Д. (Наконец-то Oracle вступила в игру с их недавним объявлением; Microsoft купила их решение от имени компании, которая раньше называлась DataAllegro).

При этом, когда данные масштабируются в терабайты, эти проблемы становятся очень нетривиальными. Если вам не нужны строгие гарантии транзакционности и согласованности, которые вы можете получить от RDBM, зачастую гораздо проще денормализовать и не выполнять объединения. Особенно, если вам не нужно много перекрестных ссылок. Особенно, если вы не выполняете специальный анализ, но вам нужен программный доступ с произвольными преобразованиями.

Денормализация переоценена. То, что происходит, когда вы имеете дело с 100 тера, не означает, что этот факт должен использоваться каждым разработчиком, который никогда не удосужился узнать о базах данных и испытывает затруднения при запросе миллиона или двух строк из-за плохого планирования схемы и оптимизации запросов. .

Но если вы находитесь в диапазоне 100 тера, во что бы то ни стало ...

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

В менее глобальном масштабе я настоятельно рекомендую BerkeleyDB для решения подобных проблем.

Answer 2

Я не слишком знаком с ними (я только что прочитал те же блоги / новости / примеры, что и все остальные), но я полагаю, что они решили пожертвовать многими обычными функциями реляционных БД в названии. масштабируемости - попробую объяснить.

Представьте, что в вашей таблице данных 200 строк.

В центре данных Google 50 из этих строк хранятся на сервере A, 50 на B и 100 на сервере C. Кроме того, сервер D содержит избыточные копии данных с серверов A и B, а сервер E содержит избыточные копии данных на сервер C.

(В реальной жизни я понятия не имею, сколько серверов будет использоваться, но он настроен на работу со многими миллионами строк, поэтому я представляю довольно много).

Чтобы "выбрать *, где name = 'orion'", инфраструктура может запустить этот запрос ко всем серверам и агрегировать результаты, которые возвращаются. Это позволяет им линейно масштабировать столько серверов, сколько им нужно (к вашему сведению, это почти то же, что и mapreduce)

Это, однако, означает, что вам нужны некоторые компромиссы.

Если вам нужно было выполнить реляционное соединение для некоторых данных, где они были распределены, скажем, на 5 серверах, каждому из этих серверов нужно было бы получать данные из каждого другого для каждой строки . Попробуйте сделать это, когда у вас есть 2 миллиона строк на 10 серверах.

Это приводит к компромиссу № 1 - нет объединений.

Кроме того, в зависимости от задержки в сети, нагрузки на сервер и т. Д. Некоторые из ваших данных могут быть сохранены мгновенно, но некоторые могут занять секунду или 2. Опять же, когда у вас есть десятки серверов, это становится все длиннее и дольше нормальный подход «все просто ждут, пока самый медленный парень закончил» больше не становится приемлемым.

Это приводит к компромиссу №2. Ваши данные не всегда могут быть сразу видны после их записи.

Я не уверен, какие еще есть компромиссы, но, в общем-то, это главные 2.

Answer 3

Итак, что я получаю, так это то, что вся философия «денормализовать, без объединений» существует не потому, что сами объединения не масштабируются в больших системах, а потому, что их практически невозможно реализовать в распределенных базах данных.

Это кажется довольно разумным, когда вы храните в основном инвариантные данные одного типа (как это делает Google). Я на правильном пути здесь?

Answer 4

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

Answer 5

Novaday Вам необходимо найти более функциональную среду для баз данных. Чаще всего вам нужны не только реляционные БД, такие как MySQL или MS SQL, но и фермы больших данных в виде Hadoop или нереляционные БД, такие как MongoDB. В некоторых случаях все эти БД будут использоваться в одном решении, поэтому их производительность должна быть максимально возможной в макромасштабе. Это означает, что Вы не сможете использовать, скажем, Azure SQL в качестве реляционной БД и одну ВМ с 2 ядрами и 3 ГБ ОЗУ для MongoDB. Вы должны масштабировать свое решение и использовать БД в качестве службы, когда это возможно (если это невозможно, то построить свой собственный кластер в облаке).