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

Question

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

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

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

1. 30 + лет академических и трудовых исследований в разработке этих систем
2. Хорошо известный язык в языке структурированных запросов (SQL).
3. Стабильная и зрелая поддержка ORM в разных технологиях (Hibernate, ActiveRecord)

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

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

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

Answer 1

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

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

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

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

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

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

Answer 2

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

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

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

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

Answer 3

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

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

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

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

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

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

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

Answer 4

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

NoSQL стал очень популярным из-за многих факторов

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

Взгляните на СУБД СУБД

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

Для поддержки транзакций СУБД должна поддерживать Свойства ACID: атомарность, непротиворечивость, изоляция, долговечность ). Это может быть достигнуто с

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

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

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

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

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

Answer 5

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