В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

Data Engineers

1710 membersпожаловаться на группу
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 транзакции, выполняя последовательно получим одно, конкурентно можем получить другое, если вторая закомитилась раньше чем закончилась первая
источник
13:38пожаловаться#1

DG

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

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

A

Alex in Data Engineers
И вот как в этом случае скейлить?
источник
13:41пожаловаться#3

A

Alex in Data Engineers
Выше же сказали что не аффеетит перфоманс
источник
13:41пожаловаться#4

A

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

DG

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

DG

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

AZ

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

A

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

AZ

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

AZ

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

AZ

Anton Zadorozhniy in Data Engineers
И просто говорить везде что мы не OLTP база)
источник
13:49пожаловаться#12

DG

Denis Gabaydulin in Data Engineers
А "вы", это кто?)
источник
13:49пожаловаться#13

AZ

Anton Zadorozhniy in Data Engineers
Терадата)
источник
13:49пожаловаться#14

A

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

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

В случае ydb упор на детерменированность которая не всегда доступна в запросах
источник
13:50пожаловаться#15

A

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

AZ

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

DG

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

AZ

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

AZ

Anton Zadorozhniy in Data Engineers
ну или датомик! )
источник
14:01пожаловаться#20