Size: a a a

2020 January 20

A

Alex in Data Engineers
Update xxx set a = 1 where b > 1
Update xxx set c = 2 where a = 1

Пришли 2 транзакции, выполняя последовательно получим одно, конкурентно можем получить другое, если вторая закомитилась раньше чем закончилась первая
источник

DG

Denis Gabaydulin in Data Engineers
Alex
Update xxx set a = 1 where b > 1
Update xxx set c = 2 where a = 1

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

A

Alex in Data Engineers
И вот как в этом случае скейлить?
источник

A

Alex in Data Engineers
Выше же сказали что не аффеетит перфоманс
источник

A

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

DG

Denis Gabaydulin in Data Engineers
Если транзакции затргиивают условно говопя один кусок данных (партицию), они исполняются локально в один поток. Внутри там можно оптимизировать как захочется. Если транзакции затрагивают несколько партиций, то нужна какая то сущеость - координатор. Безусловно, чем больше транзакция затрагивает партицией, тем больше работе для координатора.
источник

DG

Denis Gabaydulin in Data Engineers
Но в OLTP  мы же обычно трогаем небольшой кусочек данных, который относится к какой то партиции. Там еще будет вопрос с индексами(они тоже могут быть устроены по разному, но это очень длинная тема).
источник

AZ

Anton Zadorozhniy in Data Engineers
Alex
И вот как в этом случае скейлить?
Заворачивать в хранимую которая прямо на СУБД исполняется, сериализация не нужна, но мульти-партишен начинает тормозить + это конечно серьезное ограничение на логику приложения
источник

A

Alex in Data Engineers
Это все известно, вы не рассказали как это скейлится, так как партиционирование придумали задолго до newsql, поэтому и вопрос возник про ваше заявление что они повсюду
источник

AZ

Anton Zadorozhniy in Data Engineers
Deterministic transactions работают отлично ровно до того момента когда вам нужна недетерминированность)
источник

AZ

Anton Zadorozhniy in Data Engineers
Надо делать как мы - блокировка, причём даже не на ключ а сразу на весь хэш бакет)
источник

AZ

Anton Zadorozhniy in Data Engineers
И просто говорить везде что мы не OLTP база)
источник

DG

Denis Gabaydulin in Data Engineers
А "вы", это кто?)
источник

AZ

Anton Zadorozhniy in Data Engineers
Терадата)
источник

A

Alex in Data Engineers
В случае spanner понятно

В случае авроры все влетает в один инстанс, а дальше уже aws мутит 🤷‍♂️

В случае ydb упор на детерменированность которая не всегда доступна в запросах
источник

A

Alex in Data Engineers
Anton Zadorozhniy
И просто говорить везде что мы не OLTP база)
Зато честно и без хайпа, но маркетологи наверное недовольны :)
источник

AZ

Anton Zadorozhniy in Data Engineers
Alex
Зато честно и без хайпа, но маркетологи наверное недовольны :)
Хайп был в 1979, а теперь просто на работу ходят)
источник

DG

Denis Gabaydulin in Data Engineers
Ну хайп не хайп, а 5 лет назад, вручную делая шардинг на pg, я о таком только мечтал. Теперь уже ни за чтобы не выбрал такое, если под рукой будет доступен newsql.
источник

AZ

Anton Zadorozhniy in Data Engineers
Denis Gabaydulin
Ну хайп не хайп, а 5 лет назад, вручную делая шардинг на pg, я о таком только мечтал. Теперь уже ни за чтобы не выбрал такое, если под рукой будет доступен newsql.
Кмк если вам нужна очень производительная на запись СР база - скорее всего что-то не так в логике приложения (ну или просто очень редкий случай); по-моему опыту бОльшая часть реальных задач красиво решается маленькой СР базой (ну мб с репликами на чтение/кэшем) и большой АР базой с ЕС или даже crdt
источник

AZ

Anton Zadorozhniy in Data Engineers
ну или датомик! )
источник