почему базы данных noSQL более масштабируемы, чем SQL?

100

В последнее время я много читал о СУБД noSQL. Я понимаю теорему CAP , правила ACID, правила BASE и основную теорию. Но не нашли никаких ресурсов о том, почему noSQL масштабируется легче, чем RDBMS (например, в случае системы, которая требует много серверов БД)?

Я предполагаю, что сохранение ограничений и внешних ключей стоит ресурсов, и когда СУБД распространяется, это намного сложнее. Но я ожидаю, что есть намного больше, чем это.

Может кто-нибудь объяснить, как noSQL / SQL влияет на масштабируемость?

ducin
источник
7
«Я предполагаю, что сохранение ограничений и внешних ключей стоит ресурсов, и когда СУБД распространяется, это намного сложнее. Но я ожидаю, что есть намного больше, чем это». - На самом деле, это все. Точнее, это одна общая характеристика, которая делает большинство решений NoSQL более масштабируемыми, чем их собратья SQL (для определенных моделей данных). Но NoSQL - это чрезвычайно расплывчатый термин, разные семейства баз данных NoSQL имеют разные характеристики, которые делают их более масштабируемыми.
Яннис
8
Конечно, базы данных SQL прекрасно масштабируются на триллионы записей, им просто необходим некоторый опыт для разработки и настройки, которых нет у разработчиков приложений. И вообще довольно дорогой набор оборудования и лицензий.
HLGEM
6
На мой взгляд, этот вопрос не является дубликатом ни того, ни другого. Вопрос mongodb (помимо плохого названия, делающего его более конкретным) задает что-то еще, что на самом деле является более общим. Проголосовал за открытие.
Джоери Себрехтс

Ответы:

79

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

Такие вещи, как автоматическое обеспечение ссылочной целостности, транзакций и т. Д. Это все, что очень удобно для решения некоторых проблем и требует некоторых интересных методов для масштабирования вне одного сервера (подумайте о том, что произойдет, если вам нужно заблокировать два таблицы для атомарной транзакции, и они находятся на разных серверах!).

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

Майкл Кохне
источник
2
Не знал, что это так просто
Абдул
7
В этом принятом ответе совершенно не упоминается возможность шардинга NoSQL, отсутствующая в SQL. Sharding - это то, что делает NoSQL горизонтально масштабируемым.
Гяньков
8
@HristoYankov И это работает, потому что система NoSQL не делает все то, что плохо сочетается с шардингом.
user253751
1
@ ХристоЯнков: База данных SQL может быть горизонтальной, и не все базы данных NoSQL могут быть легко горизонтальными. В действительности, Sharding не является причиной, по которой вы хотите использовать NoSQL.
Ли Райан
@HristoYankov Принятый ответ идет на один уровень глубже, чем ваше замечание о том, что «совершенно не упоминается возможность шардинга NoSQL, отсутствующая в SQL». Принятый ответ, по праву, говорит о том, ПОЧЕМУ горизонтальное разбиение является более сложным с базами данных SQL. На самом деле, я потратил добрых 20 минут на поиск ответа на этот вопрос, и почти все просто выкладывают «О, Ох, осколки NoSQL лучше», не упоминая никаких причин. Абсолютно бесполезный ответ. Принятые ответы здесь прекрасно отвечают на вопрос, хотя и очень кратко. Было бы неплохо иметь больше причин, перечисленных также.
Phoeniyx
176

Речь идет не о NoSQL против SQL, а о BASE против ACID.

Масштабируемость должна быть разбита на составляющие:

  • Масштабирование чтения = обрабатывать большие объемы операций чтения
  • Масштабирование записи = обрабатывать большие объемы операций записи

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

Напишите масштабирование, где вещи становятся волосатыми. Существуют различные ограничения, налагаемые принципом ACID, которые вы не видите в архитектурах, согласованных в конечном итоге (BASE):

  • Атомарность означает, что транзакции должны завершиться или потерпеть неудачу в целом, поэтому большая часть бухгалтерии должна вестись негласно, чтобы гарантировать это.
  • Ограничения согласованности означают, что все узлы в кластере должны быть идентичны. Если вы пишете на один узел, эта запись должна быть скопирована на все остальные узлы, прежде чем возвращать ответ клиенту. Это затрудняет масштабирование традиционного кластера СУБД.
  • Ограничения долговечности означают, что для того, чтобы никогда не потерять запись, вы должны убедиться, что перед возвратом ответа клиенту запись была записана на диск.

Чтобы увеличить количество операций записи или количество узлов в кластере, превышающее определенную точку, необходимо иметь возможность ослабить некоторые требования ACID:

  • Удаление атомарности позволяет сократить продолжительность блокировки таблиц (наборов данных). Пример: MongoDB, CouchDB.
  • Понижение согласованности позволяет увеличивать объемы записи между узлами кластера. Примеры: риак, кассандра.
  • Dropping Durability позволяет вам отвечать на команды записи без сброса на диск. Примеры: memcache, redis.

Базы данных NoSQL обычно следуют модели BASE вместо модели ACID. Они отказываются от требований A, C и / или D, а взамен улучшают масштабируемость. Некоторые, например, Cassandra, позволяют вам использовать гарантии ACID, когда они вам нужны. Однако не все базы данных NoSQL все более масштабируемы.

В SQL API отсутствует механизм для описания запросов, в которых требования ACID смягчены. Вот почему все базы данных BASE являются NoSQL.

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

Обновление (2019-09-17):

Пейзаж баз данных изменился после публикации этого ответа. Несмотря на то, что между миром RIDBMS ACID и миром NoSQL BASE все еще существует противоречие, линия стала размытой. В базы данных NoSQL добавлены функции из мира РСУБД, такие как SQL API и поддержка транзакций. В настоящее время существуют даже базы данных, которые обещают масштабирование SQL, ACID и запись, например, Google Cloud Spanner, YugabyteDB или CockroachDB. Обычно дьявол кроется в деталях, но для большинства целей они «достаточно кислотные». Чтобы глубже погрузиться в технологию баз данных и узнать, как она развивалась, вы можете взглянуть на эту панель слайдов (примечания к слайдам сопровождаются пояснениями).

Джори Себрехтс
источник
Хотя я согласен с тем, что некоторые хранилища NoSQL заменяют ACID на BASE, это все еще не является общей функцией для всех хранилищ, которые подпадают под «категорию» NoSQL, которая, во-первых, плохо определена. Через некоторое время интерпретация термина изменилась с «Нет SQL» на «Не только SQL», но так как многие такие базы данных все еще выполняют JOINs или начали реализовывать диалекты SQLesque, Марк Мэдсен повторно ввел термин, чтобы означать что-то другое в его история баз данных в нотации : «Нет, SQL» ;-)
Лукас Эдер
2
Чтобы избежать объединений, мы будем иметь ненормализованные данные в NoSQL, что приведет к повторению и большему объему памяти. Но то же самое может быть достигнуто в RDBMS, если мы в порядке с денормализацией. Таким образом, «Joins» или «no Joins» зависит от администратора базы данных, а не от типа базы данных. Верный ?
Каушик Леле
2
@dynamic Эти сайты либо используют тяжелое кэширование, либо они осколки. В этих проектах сложность масштабирования данных находится за пределами базы данных. Вы также можете использовать nosql в таком случае, потому что это компромисс, который делает nosql.
Джоери Себрехтс
1
«В SQL API отсутствует механизм для описания запросов, в которых требования ACID смягчены». Технически это правда, но SQL-сервер сделал робкий шаг в этом направлении. В SQL 2014 введена отложенная долговечность, уменьшающая D в ACID, в обмен на снижение давления записи журнала.
EBarr
3
Это должен быть принятый ответ IMO. Это очень ясно с примерами, но удается оставаться кратким.
Ольшанск
4

Это правда, что базы данных NoSQL (MongoDB, Redis, Riak, Memcached и т. Д.) Не поддерживают ограничения внешнего ключа, и атомарные операции должны быть определены более явно. Также верно, что базы данных SQL (SQL Server, Oracle, PostgreSQL и т. Д.) Можно масштабировать для удовлетворения очень больших требований к производительности со стороны опытных администраторов баз данных.

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

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

RandomProgrammer
источник
2
Я не уверен, что согласен с частью об атомарных транзакциях, в смысле ACID (хотя трудно комментировать «NoSQL», так как обсуждается, что именно мы имеем в виду). Большая часть прироста производительности в «типичных» БД NoSQL достигается за счет ослабления гарантий согласованности (см .: конечная согласованность , ACID и BASE). Если конечная согласованность достаточно хороша для приложения (а это часто бывает), то это обеспечивает гораздо более эффективное горизонтальное масштабирование.
Даниэль Б
4

От IBM developerWorks: Обеспечение масштабируемости данных на уровне облака с базами данных NoSQL.

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

Системы NoSQL имеют ряд общих конструктивных особенностей:

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

Почему реляционные базы данных не могут быть оптимальными для масштабирования

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

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

Другой пример: для таких крупных веб-сайтов, как eBay, Amazon, Twitter или Facebook, масштабируемость и высокая доступность являются важными требованиями, которые невозможно поставить под угрозу. Для этих приложений даже малейшее отключение может иметь значительные финансовые последствия и повлиять на доверие клиентов.

На DBA.SE: Что означает горизонтальное масштабирование?

Горизонтальное масштабирование по существу строится, а не вверх. Вы не идете и не покупаете больший более мощный сервер и переносите на него всю свою нагрузку, вместо этого вы покупаете 1+ дополнительных серверов и распределяете нагрузку между ними.

Горизонтальное масштабирование используется, когда у вас есть возможность запускать несколько экземпляров на серверах одновременно. Обычно гораздо сложнее перейти с 1 сервера на 2 сервера, чем с 2 на 5, 10, 50 и т. Д.

Решив проблемы с параллельными экземплярами, вы можете воспользоваться преимуществами таких сред, как Amazon EC2, облачная служба Rackspace, GoGrid и т. Д., Поскольку вы можете увеличивать и уменьшать экземпляры в зависимости от потребностей, уменьшая необходимость платить за мощность сервера. Вы не используете только для покрытия этих пиковых нагрузок.

Реляционные базы данных являются одним из наиболее сложных элементов для параллельного выполнения полного чтения / записи.

Md Mahbubur Rahman
источник