Смеси категорий
В нашей "облачной" инфраструктуре баз данных гарантии согласованности обеспечиваются для данных, а не для транзакций. Это мотивируется тем, что у данных имеются разные стоимостные характеристики. Например, для данных о банковских счетах и запасах требуется изоляция, а для журнальных данных или профилей клиентов – нет. Определение согласованности на данных, а не на транзакциях позволяет обращаться с данными в соответствии с их важностью. Однако побочным эффектом этого подхода является то, что транзакции при доступе к разным данным могут выдеть разные уровни согласованности.
Если в одной транзакции обрабатываются данные разных категорий, то каждая запись, затрагиваемая этой транзакцией, обрабатывается в соответствии с гарантиями согласованности, свойственными категории этой записи. Поэтому операции чтения данных категории A получают согласованные данные, а операции записи оставляют их в согласованном состоянии. При чтении данных категории A всегда выбираются актуальные данные. При чтении данных категории C в зависимости от эффектов кэширования могут выбираться устаревшие данные. Логическим следствием является то, что для результатов операций соединения, объединения и т.д. данных категорий A и C обеспечиваются только гарантии категории C. В большинстве ситуаций это не приносит вреда и является ожидаемым/желательным поведением. Например, в результате соединения данных об остатках на счетах (данные категории A) и данных о профилях клиентов (данные категории C) будет содержаться только актуальная информация о балансах счетов, но, возможно, устаревшие данные об адресах клиентов.
Если это необходимо с точки зрения приложения, для транзакций можно указать требуемые им гарантии. Это позволяет транзакции видеть актуальное состояние любой записи. Однако это не гарантирует, что у этой транзакции имеется монопольное право на обновление этой записи. Если одна транзакция производит запись в режиме сессионной согласованности, а другая – в режиме сериализуемости, то все равно может возникнуть несогласованность.
