Про базы данных, такие как 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. Вы должны масштабировать свое решение и использовать БД в качестве службы, когда это возможно (если это невозможно, тогда создайте свой собственный кластер в облаке).