Как более новые модели баз данных достигают лучшей масштабируемости и производительности по сравнению с традиционной реализацией СУБД?

Question

У нас есть

• BigTable от Google ,
• Hadoop, активно поддерживается Yahoo ,
• Dynamo от Amazon

все нацелены на одну общую цель - сделать управление данными максимально масштабируемым .

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

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

Как эти настраиваемые дружественные системы управления данными решают проблему?

Это рисунок из этого документа , поясняющийGoogle BigTable:

Выглядит то же самое для меня. Как достигается ультрамасштабируемость?

Answer 1

Говоря конкретно на ваш вопрос о Bigtable, разница в том, что иерархия на диаграмме выше - это все, что есть.Каждый планшетный сервер Bigtable отвечает за набор таблеток (смежные ряды из таблицы);сопоставление диапазона строк с планшетом сохраняется в таблице метаданных, а сопоставление с планшета на сервер планшета сохраняется в памяти мастера Bigtable.Поиск строки или диапазона строк требует поиска записи метаданных (которая почти наверняка будет в памяти на сервере, на котором она размещена), а затем ее использования для поиска фактической строки на сервере, ответственном за нее - в результате чеготолько один или несколько дисков ищет.

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

Answer 2

«Традиционный» рынок СУБД SQL на самом деле означает очень небольшое количество продуктов, которые традиционно ориентированы на бизнес-приложения в корпоративной среде.Массовая масштабируемость без разделения ресурсов исторически не была приоритетом для этих продуктов или их клиентов.Поэтому естественно, что появились альтернативные продукты для поддержки приложений баз данных в масштабе Интернета.

Это не имеет ничего общего с тем фактом, что эти новые продукты не являются "реляционными" СУБД.Реляционная модель может масштабироваться так же, как и любая другая модель.Возможно, реляционная модель подходит для этих типов масштабируемых приложений лучше , чем, скажем, сетевые (основанные на графике) модели.Просто у языка SQL есть много недостатков, и никто еще не придумал подходящих реляционных NOSQL (не-SQL) альтернатив.

Answer 3

Один теоретический ответ о масштабируемости - http://queue.acm.org/detail.cfm?id=1394128 - гарантии ACID стоят дорого.См. http://database.cs.brown.edu/papers/stonebraker-cacm2010.pdf для контраргумента.

На самом деле просто пережить сбой питания дорого.Несколько лет назад я сравнил MySQL с Oracle.MySQL был почти невероятно быстрее, чем Oracle, но мы не могли его использовать.MySQL того времени был построен на базе Berkeley DB, которая была на много километров быстрее, чем полнофункциональная база данных Oracle на основе журналов, но если отключилось питание во время работы MySQL на базе Berkely DB, это был ручной процесс, чтобы снова получить согласованность базы данныхкогда питание снова включится, и вы, вероятно, потеряете последние обновления навсегда.

Answer 4

Речь идет об использовании дешевого сопутствующего аппаратного обеспечения для построения сети / сетки / облака и распределения данных и загрузки (например, с использованием карты / уменьшения).

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

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

Другое дело - если вы строите сетку / облако из дешевых серверов, это отказоустойчиво, потому что вы храните все данные в трех (?) Разных местах, и в то же время это дешево.

Назадк вашим фотографиям - первый - с одного компьютера (обычно), второй - из сети компьютеров.