Куда упала бы масштабированная реляционная БД в теореме CAP?

Question

Если вы масштабировали сервер SQL с одной БД для записи и несколькими БД для чтения.Не будет ли задержки для репликации данных из базы данных записи в другие базы данных чтения?В каком случае данные не противоречат друг другу?

Так, где в теореме CAP попадет масштабированная реляционная БД?

Обновление:

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

ВСогласованность теоремы CAP означает, что все компоненты видят одни и те же данные.Эта согласованность отличается от согласованности в ACID.

Из того, что я знаю, предполагается, что реляционные БД, такие как SQL-сервер, являются CA (согласованными и доступными).Это имело бы смысл, если бы была только одна база данных.Потому что все увидят одни и те же данные.Но что, если сервер SQL масштабируется с несколькими базами данных?В этом случае все базы данных будут видеть одни и те же данные?Если нет, будет ли это согласованно (в теореме CAP)?

Мне кажется, что масштабированная реляционная БД - это AP (Доступно и допускает разбиение), а не CA (Согласовано и доступно).

Answer 1

Я прочитал различные определения согласованности в отношении теоремы CAP.

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

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

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

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