#машины_разное

Обидно, когда ты берешься копать тему, которая тебе кажется до жути интересной, и перестает быть таковой, как только ты разобрался в вопросе.

Мне не давала покоя история Spanner/TrueTime и его гарантии ACID в контексте СУБД планетарного масштаба. Я влез в нее, делая записки своих изысканий, надеясь сделать из этого полноценный блог, но блога тут хорошего не выйдет. Почему? Долгая история, но вы на меня подписаны не ради того, чтобы читать мои конспекты книг или, прости Господи, репосты.

Ниже, собранный из осколков пост, кратко описывающий, как оно работает.

Про TrueTime вы уже знаете. Он возвращает не время, но дельту вероятных времен. Spanner использует эту дельту, чтобы построить четкий порядок очередности транзакций, для обеспечения Consistency as in ACID.

Тут надо сделать небольшую ремарку: C в ACID и C в CAP это… разные consistency! Точнее слово-то одно, но оно так изнасиловано академиками кудахтер саенс, что консистентность тут имеет разные определения.

Консистентность по ACID означает то, что каждый запрос на чтение в базу вернет корректное состояние на момент исполнения запроса. По CAP - что каждый запрос на чтение вернет все завершенные записи.

Согласитесь, это несколько разные вещи? В ACID консистентность обеспечивается за счет атомарности и изоляции транзакций. В случае со Spanner, используется классический подход snapshot isolation что в купе с хитростями TrueTime дает нам нужные гарантии. Как хранилище Spanner’а обеспечивает скорую репликацию данных между регионами вопрос уже десятый, и не такой уж и интересный. В конце концов все упирается в физику, двухфазные коммиты и вот это вот все.

Что Cloud Spanner, что Aurora Global Database - прикольные решения, но в голове нужно держать цитату Мартина Клепманна: A node in the network cannot *know* anything for sure—it can only make guesses based on the messages it receives (or doesn’t receive) via the network.