Разве никакая горизонтальная масштабируемость когда дело доходит до записи дефекта RDBMS не? или это происходит со всем DBMS?
При ударе крыши в чтение из базы данных Вы имеете два варианта, масштабируетесь вертикально путем помещения большего количества аппаратных средств в сервер или масштабируетесь горизонтально путем помещения второго сервера, чтобы помочь разгрузить чтения.
Разгрузка чтений к второму серверу, средствам, что все записи поразят оба сервера, в то время как хиты только для чтения один.
Проблема состоит в том при ударе крыши записью так как запись должна произойти со всеми серверами, это означает, что все серверы будут перегружены с запросами записи, и сервер прибывает неприменимый. Добавление большего количества серверов к проблеме не помогает, так как это только добавляет больше серверов, которые будут перегружены. Таким образом, необходимо масштабироваться вертикально.
Это - что-то, что характерно для RDBMS? или это - что-то, что происходит со всем DBMS?
Я знаю, что можно сделать вещи на стороне программного обеспечения и разделить базу данных в два, например, все записи, запускающиеся с 0-m в одном дб, в то время как n-z в другом, но по моему скромному мнению это - больше обходного решения, чем решение проблемы.
2 ответа
Я не вижу, чтобы это было специфично для реляционной модели. Все базы данных, которые должны читать и писать (а это большинство из них), будут иметь подобную проблему.
Если уж на то пошло, то большинство баз данных читают гораздо чаще, чем пишут, поэтому крыша для записи возникает реже, чем можно подумать. Кроме того, балансировка нагрузки баз данных в соответствии с вашим методом имеет тенденцию к немедленной записи на основную базу данных с записью в очередь на все вторичные (по крайней мере, по моему опыту).
В этом случае вы как пользователь фактически не ждете нескольких записей, вы просто ждете первой. СУБД сама управляет синхронизацией между экземплярами. Это, конечно, означает, что вторичные базы данных могут быть не совсем актуальными, но это можно контролировать. Технически, это нарушает ACID-свойства системы в целом, но это можно обойти.
Я думаю, что так обстоит дело с любой СУБД, хотя некоторые справляются с этим лучше, чем другие. Как вы упомянули, наиболее распространенным решением этой проблемы является программное разбиение базы данных.
Однако во многих приложениях такое разделение базы данных имеет смысл в любом случае, если вы работаете в таком большом масштабе, что это становится необходимым. Например, если у вас есть приложение для социальной сети, вероятно, имеет смысл разделить вашу базу данных по странам или другим географическим регионам. Это позволит вам разместить ваши серверы географически близко к регионам, которые они обслуживают. Это также поможет смягчить любые проблемы с «социальным графом» между базами данных, поскольку друзья людей, как правило, живут поблизости.