Разве нет горизонтальной масштабируемости, когда дело доходит до написания дефекта RDBMS? или это происходит со всеми СУБД?

Question

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

Разгрузка чтений на второй сервер означает, что все записи попадут на оба сервера, а чтение только на один.

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

Это что-то особенное для СУРБД?или это происходит со всеми СУБД?

Я знаю, что вы можете делать что-то на стороне программного обеспечения и разделить базу данных на две части, например.все записи начинаются с 0-m в одном дб, а nz - в другом, но ИМХО это скорее обходной путь, чем решение проблемы.

Answer 1

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

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

Answer 2

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

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

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

Answer 3

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

1) Чтения являются более частыми, чем записи

2) Современные RDBM имеют Multi-Version Concurrency Control, способную уменьшить блокировку при чтении / записи