Почему NoSQL лучше "масштабируется", чем РСУБД?

Я прочитал следующий текст в техническом блоге , обсуждая преимущества и недостатки NoSQL

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

Я запутался в масштабируемости RDBMS и NoSQL.

Мое замешательство:

Почему РСУБД менее способны масштабироваться? И причина покупки больших серверов вместо того, чтобы покупать более дешевые.
Почему NoSQL больше способен масштабироваться?

Ответ 1

У РСУБД есть ACID (http://en.wikipedia.org/wiki/ACID) и поддерживает транзакции. Из-за этих концепций масштабирование "вне" с РСУБД сложнее.

Решения NoSQL обычно предлагают атомарность на уровне записи, но не могут гарантировать, что серия операций будет успешной (транзакция).

Это сводится к: для сохранения целостности данных и поддержки транзакций для многосерверной RDBMS потребуется быстрый канал связи с базой данных для синхронизации всех возможных транзакций и операций записи, предотвращая/обрабатывая тупик.

Вот почему вы обычно видите только 1 мастер (писатель) и несколько подчиненных (читателей).

Ответ 2

Итак, я пытался выяснить реальную нижнюю строку, когда речь заходит о NoSQL и RDBMS, и всегда получаю ответ, который не совсем режет. В моем поиске есть действительно 2 основных различия между NoSQL и SQL, причем только 1 является истинным преимуществом.

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

Скажем, мы хотим вернуть такой объект:

post {
    id: 1
    title: 'My post'
    content: 'The content'
    comments: {
      comment: {
        id: 1
      }
      comment: {
        id: 2
      }
      ...

    views: {
      view: {
        user: 1
      }
      view: {
        user: 2
      }
      ...
    }
}

В NoSQL этот объект будет в основном храниться как есть и, следовательно, может находиться на одном сервере как отдельный автономный объект, без необходимости объединять данные из других таблиц, которые могут находиться на других серверах БД.

Однако, с реляционными БД, пост должен будет присоединиться к комментариям из таблицы comments, а также к представлениям из таблицы views. Это не будет проблемой в SQL ~ UNTIL ~ БД разбивается на осколки, и в этом случае "комментарий 1" может быть на одном сервере БД, а "комментарий 2" еще на другом сервере БД. Это затрудняет создание одного и того же объекта в РСУБД, который масштабируется по горизонтали, чем в базе данных NoSQL.

Будут ли какие-либо эксперты БД утверждать или аргументировать эти моменты?

Ответ 3

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

Системы NoSql делают разные компромиссы. Например, они не гарантируют, что второй сеанс сразу увидит данные, полученные первым сеансом. Таким образом, происходит развязка транзакции хранения некоторых данных из процесса создания этих данных для каждого пользователя. Google "в конечном итоге последователен". Таким образом, одной транзакции не нужно ждать какой-либо (или гораздо меньше) связи node. Поэтому они могут намного легче использовать большое количество узлов.

Ответ 4

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

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

Ответ 5

Для NO SQL, 1. Все дочерние элементы, связанные с коллекцией, находятся на одном и том же месте и так далее на одном сервере, и нет операции соединения для поиска данных с другого сервера.

2. Нет никакой схемы, поэтому на любом сервере не требуется блокировок, и обработка транзакций остается для клиентов.

Вышеуказанное 2 экономит много накладных расходов на масштабирование в NO-SQL.