Pro таких баз данных, как BigTable, SimpleDB

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

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

Ответ 1

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

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

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

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

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

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

Ответ 2

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

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

В google-центре данных 50 из этих строк хранятся на сервере A, 50 на B и 100 на сервере C. Дополнительно сервер D содержит избыточные копии данных с серверов A и B, а сервер E содержит избыточные копии данных на сервер C.

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

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

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

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

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

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

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

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

Ответ 3

Так что я получаю то, что существует вся философия "denormalize, no join", а не потому, что сами объединения не масштабируются в больших системах, а потому, что их практически невозможно реализовать в распределенных базах данных.

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

Ответ 4

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

Ответ 5

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