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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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