потерянный апдейт

Такое возможно, для LWW. Я скорее о том, что часы на нормально сконфигурированной машине с доступом к интернету, не должны часто разъезжаться. И когда они немного отстают можно немного подождать. В общем throughout это по идее не должно быть заметно.

Строго говоря да. Меня смутила ваша фраза "упираться в консенсус". Если бы тут был какой нибудь paxos с его кучей лишних хопов, то да. Но в данном случае, этот "консенсус" не будет узким местом.

как раз в облаках на виртуалках часы едут постоянно,  ну и кому нужен throughput когда мы сериализацию теряем?

Хороший вопрос про облака. Возможно voltdb в облаках не взлетит, не знаю.

кмк тут спор куда-то не туда зашел, вы пытались показать что newsql дает масштабируемость sql acid как у nosql и без уступок в плане гарантий? кмк у вас не очень получилось, в каждом примере оказывается что есть какие-то доп ограничения..

Ну я не согласен, мне кажется я вполне привел примеры того, что это возможно. И даже залез в некоторые тех детали,

в изначальной Dynamo whitepaper, по которой C* написана, вместо wall clock используются векторные часы, просто эту фичу посчитали лишней

А dynamo другого класса система. И вот забавно, что от того первоначального пейпера в самом dynamo, мало что осталось, если верить reinvent 2018.

Вектора клока per row уже нет.

Ну хз, вопрос про скейл в авроре там явно написано что одна бд-таблица всегда уезжает на один инстанс, то есть партиционированием мы увеличиваем скорость дисковой подсистемы, но вот общий тротпут упрется в этот инстанс, хотя newsql позиционирование горизонтальный скейл за счёт множества транзакций процессоров

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

И тд, то есть той победы которой обещали даже близко нету

Я бы сказал не ограничения, а особенности архитектуры, которые есть абсолютно в любой базе. Запустить запрос, которые модифицирует 3/4 партиций, да это будет медленно, но это будет медленно на любой базе, даже single instance pg. А уж про kv молчу.
Главное, что получилось показать, что вполне можно иметь OLTP систему, которая горизонтально масштабируется и имеет strict serializable.

Диалект очень близок к ansi sql.

https://github.com/apache/spark/commit/17857f9b8bdf95eb64735eb986e86bf8fd8bc1a9

Из той же оперы, сразу заявляет что поддерживаем ansi sql, а следом в патчах говорим что мы ему не следуем

Сериалайзбл никакак не аффектит нас, если оно не под exclusive lock (как в традиционных базах).

С этим запросом как раз есть полная ясность.

У вас запросы не исполняются конкуретно, их порядок определен. Значит и эффекты аъполночтью вычислимы.

Внимательно слушаю, так как в примерах у них везде светился id

Так это все можно было до newsql, какой-нибудь тандем или ас/400

Проблемы могут быть в запросах типа update x = 1 where id = rand например. Но такие запросы это изотерика скорее.