Каковы различия между NoSQL и традиционной СУБД?

71

Каковы различия между NoSQL и традиционной СУБД?

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

Где лучшие места для использования NoSQL? Почему?

Spredzy
источник

Ответы:

61

NoSQL означает «Не только SQL» и обычно означает, что база данных не является реляционной базой данных, которая была очень популярна в последние десятилетия.

Причина, по которой NoSQL был так популярен в последние несколько лет, заключается главным образом в том, что когда реляционная база данных растет на одном сервере, ее уже не так просто использовать. Другими словами, они не очень хорошо масштабируются в распределенной системе. Все крупные сайты, которые вы упомянули Google, Yahoo, Facebook и Amazon (я мало знаю о Digg), содержат много данных и хранят их в распределенных системах по нескольким причинам. Возможно, данные не помещаются на одном сервере или существуют требования к высокой доступности .

CAP Теорема

Свойства распределенной системы могут быть описаны теоремой CAP . Из трех свойств вы можете иметь не более двух:

  • C onsistency
  • оступность
  • толерантность к сети P artitioning

Amazon Dynamo использует Eventual Consistency, чтобы приблизиться, чтобы получить все три свойства. Бумаги Динамо: Очень Доступный ключ-значение магазин Amazon, стоит читать , когда изучение баз данных NoSQL и распределенные системы. Amazon Dynamo имеет свойства A и P.

Google использует другой подход с BigTable , который имеет свойства C и A.

Другие базы данных NoSQL

Как я писал в начале, есть много других видов баз данных NoSQL, которые разработаны для различных требований. Например, графовые базы данных, такие как Neo4j , базы данных документов, такие как CouchDB, и базы данных многомодельных / объектных объектов, такие как OrientDB .

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

Jonas
источник
1
Хороший, исчерпывающий ответ.
TML
NoSQL НЕ означает нереляционный, он означает нечто иное, чем СУБД SQL.
nvogel
1
Похоже, что на недавней конференции О'Рейли Страта Марк Мэдсен придумал новую интерпретацию «NoSQL» в своей истории баз данных, чтобы заменить «не только SQL». Теперь: «Нет, SQL» ;-)
Лукас Эдер
6
«Не только» был модифицирован, раннее движение NoSQL было бешено против реляционных баз данных. Затем они попали в реальный мир.
Гай
22

NoSQL - это очень широкий термин, который обычно называют «не только SQL». Термин теряет популярность в сообществе, не относящемся к РСУБД.

Вы обнаружите, что база данных NoSQL имеет несколько общих характеристик. Их можно условно разделить на несколько категорий:

  • хранилище ключей / значений
  • Bigtable вдохновленные базы данных (на основе статьи Google Bigtable)
  • Базы данных на тему динамо
  • распределенные базы данных
  • базы данных документов

Это огромный вопрос, но на него довольно хорошо ответили в этом обзоре распределенных баз данных .

Для краткого ответа:

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

Что касается того, когда их использовать - это полностью зависит от потребностей вашего приложения.

Иеремия Пешка
источник
12

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

Однако есть некоторые компромиссы для всей этой гибкости: базы данных NoSQL довольно не хватает функций по сравнению с системами RDBMS, такими как SQL Server, Oracle, DB2, MySQL и т. Д. Там нет Service Broker, протоколирование транзакций, пакеты ETL и т. Д.

NoSQL не является чем-то новым. Это было на самом деле в течение 50-60 лет. Тогда это называлось COBOL. Та же самая точная идея, просто другая группа придумала это.

mrdenny
источник
3
Точка 1 неверна для многих (всех?) Баз данных NoSQL, если вы явно не сказали базе данных, что вам все равно, если запись будет успешной. Например, любая база данных, поддерживаемая Hadoop, запишет данные в три места, где бы они ни находились. По умолчанию Кассандра будет писать в три местоположения и будет подтверждать, что запись была успешной, если два успешно завершены.
Иеремия Пешка
3
Как он обрабатывает параллелизм при выполнении этих обновлений? Есть ли транзакция распределенного типа, которая идет между ними, или ACK-запись на запись выполняется вручную, а серверы обрабатывают все остальное в фоновом режиме?
Мрденный
Параллельность полностью зависит от реализации. Riak использует векторные часы для обеспечения параллелизма, и в случае конфликтующих записей они могут быть возвращены вызывающему приложению для разрешения. Другие используют последние записи побед.
Иеремия Пешка
Что касается подтверждения записи - в большинстве случаев запись не подтверждается до тех пор, пока ОС не подтвердит запись. Вы даже можете зайти так далеко, что запросите подтверждение длительной записи, что означает, что биты на самом деле записываются на диск, а не в буфер ОС. MongoDB по умолчанию подтверждает запись в память, но может быть настроена на требование подтверждения записи на диск. Репликация обрабатывается по-разному для каждого продукта. С Hadoop клиент пишет на сервер A, который пишет в B, который пишет в C. Как только C отвечает, запись завершена, и клиент получает подтверждение записи.
Иеремия Пешка
В этом случае я исправлюсь. Я удалил неправильное утверждение. Я FUBAR что-нибудь еще?
Мрденный
6

По сути, отказ от реляционной настройки, с первичными и внешними ключами, а также с дополнительными накладными расходами, связанными с обеспечением безопасности транзакций, часто дает экстремальное повышение производительности. Однако это не уникально для новых баз данных / хранилищ данных, так как, например, MySQL был настроен для работы на «уровнях NoSQL», минуя слои.

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

Это компромисс между безопасностью и производительностью.

Йоханна Ларссон
источник
5

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

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

steve.lippert
источник
Тот факт, что на этот вопрос можно ответить, перейдя в WP, заставляет меня потереть подбородок, когда я обдумываю ответы здесь. Я думаю, что это слишком «вопрос с наполнителем», но это действительно все, что у нас есть сейчас.
Jcolebrand
1
Важным примечанием здесь является то, что отказ от поддержки отношений (внешнего ключа) в инфраструктуре базы данных / сервера освобождает базу данных / серверы от нагрузки, связанной с управлением загрузкой и блокировкой, и сохранением ссылочной целостности. Следствием этого, компромисса, является то, что ссылочная целостность, согласованность и другие проблемы ACID затем распространяются на приложения. Многие приложения выигрывают от этого, а не ограничиваются этим. (Некоторые приложения должны быть включены в модель клиент / сервер).
Джим Деннис
0

Я много работал над базой данных MongoDB NoSQL и Oracle.

схема

База данных SQL имеет собственную предопределенную схему для хранения структурированных данных.

В базе данных NoSQL нет предопределенной схемы, здесь схема является наиболее динамичным элементом, основанным на элементах данных.

Масштабируемость

Базы данных SQL являются вертикально масштабируемыми, что означает, что если мы хотим масштабировать базовую базу данных SQL, нам необходимо усилить аппаратное обеспечение, на котором установлена ​​система СУБД. Вот где это иногда идет для ограничения масштабируемости.

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

Извлечение данных

В базах данных на основе SQL для определения и обработки данных мы можем использовать SQL (Structured Query Language), который в настоящее время является очень мощным.

С точки зрения базы данных NoSQL запросы фокусируются на сборе и документах. Иногда это называется UnQL (неструктурированный язык запросов). Это все еще в фазе эволюции, поэтому она варьируется от поставщика к поставщику базы данных NoSQL.

Подробнее о ключевых различиях в моем блоге: Разница между базой данных SQL и NoSQL

Вират Гайвала
источник