Будут ли реляционные базы данных масштабироваться (или лучше), чем их коллеги NoSQL, если мы отбросим отношения?

Отказ от ответственности. Это широкий вопрос, поэтому его можно перенести в другой источник (если администраторы считают это подходящим).

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

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

Более 30 лет исследований и исследований в области разработки этих систем.
Известный язык в языке структурированных запросов (SQL).
Стабильная и зрелая поддержка ORM по технологиям (Hibernate, ActiveRecord)

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

Кроме того, я признаю, что исследования должны быть посвящены NoSQL, и что время, проведенное на этой арене, явно приведет к повышению качества интернет-технологий. Тем не менее, сравнение видов между NoSQL и традиционными предложениями RDBMS (минус отношения) было бы полезно при принятии бизнес-решений.

ОБНОВЛЕНИЕ 1. Когда я обращаюсь к базам данных NoSQL, я говорю о хранилищах данных, которые могут не требовать схем фиксированной таблицы и обычно избегают операций объединения. Следовательно, акцент в вопросе о снижении отношений в традиционной SQL RDBMS

Ответ 1

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

Большим ограничителем масштабируемости является стоимость синхронного ввода-вывода. Требования согласованности и долговечности - то, что СУБД фактически и надежно сохраняет данные, когда она сообщает вам, что она сохранила данные, является дорогостоящей.

Несколько продуктов NoSQL, которые в настоящее время находятся в моде, достигают большой производительности, ослабляя их согласованность и долговечность в своей конфигурации по умолчанию. Существует много сообщений о потерях данных CouchDB или MongoDB.

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

Аналогично, вы можете сделать базу данных SQL достигла высокой производительности, например, продуктов NoSQL, отключив функции по умолчанию, обеспечивающие безопасность данных. См. RunningWithScissorsDB.

PS: Если вы считаете, что базы данных, ориентированные на документы, являются "передовыми", я предлагаю вам прочитать MUMPS. Все старое новое снова.: -)

Ответ 2

SQL обычно имеет проблемы масштабирования, потому что гарантии, которые он дает, не только для одной "строки" за раз. Они охватывают ряды. Это затрудняет распределение нагрузки. Вот примеры RDBMS, дающие гарантии, охватывающие более одной записи:

Индексы: Атомное обновление двух базовых таблиц сразу (индекс внутри - таблица)
Внешние ключи
Материализованные представления

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

NoSQL обычно "решает" это, просто запрещая эти функции; -)

Следующий вопрос, сдерживающий SQL, заключается в том, что по умолчанию он предоставляет семантику ACID. Это не связано с реляционной моделью - это деталь реализации.

Итак, если вы отключите те функции, которые трудно распространять/разделять и отключать ACID, вы получаете производительность NoSQL. На самом деле посмотрите, как HandlerSocket делает это с MySQL. Он имеет скорость NoSQL, хотя он работает на InnoDB и предоставляет стандартный полнофункциональный SQL-интерфейс (это действительно просто безликий обход на стандартном сервере MySQL).

Никакой магии в NoSQL, просто меньше возможностей. Это нормально. Это другой компромисс.

Ответ 3

По-видимому, по-видимому, есть два заблуждения, которые могут быть связаны с этим вопросом. Во-первых, "NoSQL" не означает "нерелятивный", это просто означает нечто иное, чем SQL. Таким образом, СУБД может быть СУБД NoSQL.

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

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

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

Ответ 4

Я думаю, что плюсы/минусы использования RDBMS или NoSQL действительно зависят от данных и того, как вы планируете его использовать. Насколько я понимаю, транзакции на самом деле довольно хорошо представлены реляционной БД. Мой опыт работы с NoSql - с бесконечным графиком и Neo4J. Forensics является хорошим вариантом для NoSQL, каждый человек является node/vertex, а край может представлять различные типы связи (электронная почта, телефон, встреча с лицом к лицу, несущий голубь и т.д.). Затем вы можете взять подозреваемого/верхушку и пересечь график с определенными критериями, чтобы узнать, как фактически связаны два, казалось бы, несвязанных человека (вероятно, с большей эффективностью, чем традиционная реляционная БД). Другими хорошими примерами являются данные социальных графов, каждый пользователь является node/vertex, а отношение (friend) является границей, соединяющей два узла. Короче говоря, ваши данные лучше всего представлены и извлекаются с помощью таблиц или узлов/ребер.

Ответ 5

Отношения не являются хорошим критерием для сравнения производительности между РСУБД и NoSQL.

NoSQL стал очень популярным благодаря многим факторам

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

Посмотрите Накладные расходы RDBMS

RDBMS имеют проблемы из-за требований согласованности.

Чтобы поддерживать транзакции, СУБД должна поддерживать свойства ACID: Atomicity, Consistency, Isolation, Durability). Этого можно достичь с помощью

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

Блокировка. Традиционная двухфазная блокировка создает значительные накладные расходы, поскольку все обращения к структурам базы данных управляются отдельным объектом, Lock Manager.

Блокировка. В многопоточной базе данных многие структуры данных должны быть зафиксированы перед их доступом. Удаление этой функции и переход к однопоточному подходу имеют заметное влияние на производительность.

Управление буфером. Базовой системе основной памяти не требуется доступ к страницам через пул буферов, устраняя уровень косвенности при каждом доступе к записи.

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