Почему NoSQL лучше «масштабируется», чем RDBMS?

Question

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

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

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

Моя путаница:

1. Почему RDBMS менее способны масштабироваться?И причина покупки более крупных серверов вместо более дешевых.
2. Почему NoSQL лучше масштабируется?

Answer 1

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

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

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

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

Answer 2

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

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

2. Горизонтальное масштабирование - Реальное преимущество 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.

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

Answer 3

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

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

Answer 4

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

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

Answer 5

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

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

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