Size: a a a

2020 January 20

AS

Andrey Smirnov in Data Engineers
Denis Gabaydulin
Я бы сказал так, что мы не теряем в перфоманче конечно, но не корректно утверждать что теряем в масштабируемости.
теперь я знаю как надо говорить если твое приложение однопоточное и ты не смог в многопоточное:
Each partition running on a node is single-threaded which eliminates the overhead associated with locking and latching in a typical multi-threaded environment, and transaction requests are executed sequentially.
источник

DG

Denis Gabaydulin in Data Engineers
Anton Zadorozhniy
я имею в виду согласие между нодами что они принимают транзакцию
Основная идея в том, что любые изменения детерминированы и приводят к одному и тому же результату, поэтому вообще говоря не надо иметь sync на каждую транзакцию. Надо чтобы все известные транзакции были исполнены в некоторых точках.
источник

DG

Denis Gabaydulin in Data Engineers
Alex
с каких пор Aurora с одним мастером и репликами уже стала new sql?
что-то не помню как она скейлится по записи по сравнению с тем же железом

Spanner - был больше 10 лет назад, по нему что-то и пытаются делать все остальные

Voltdb - хз, не сталкивался
ydb - туда же

у всех свой диалект sql с ослабленными гарантиями
источник

A

Alex in Data Engineers
и как это скейлится?
источник

DM

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

A

Alex in Data Engineers
Denis Gabaydulin
Там нет raft/paxos например. Вы про детерминистические транзакции читали?
тут ведь вопрос не в том чтобы один запрос независимый исполнился по одному ключу
а в том как они гарантируют “зная какие ключи мы затроним, мы можем реордерить транзакции не затрагивающие одинаковые ключи”

update xxx set a = 1 where b > 1

и всё, без поднятия индекса вся детерминированность падает
источник

DG

Denis Gabaydulin in Data Engineers
Andrey Smirnov
теперь я знаю как надо говорить если твое приложение однопоточное и ты не смог в многопоточное:
Each partition running on a node is single-threaded which eliminates the overhead associated with locking and latching in a typical multi-threaded environment, and transaction requests are executed sequentially.
Правильно, потому что локи под contention приводят к плохой производительности (вы либо ждете на спинлоке, либо проваливаетесь в планировщик).
Акторная модель по сути победила.
источник

DG

Denis Gabaydulin in Data Engineers
Daniel Matveev
при допущении о глобальных часах (синхронизация их между нодами) и транзакции мгновенны
В пейпере про это есть. Clock skew.
источник

DG

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

https://blog.developer.bazaarvoice.com/wp-content/uploads/2013/07/Screen-Shot-2013-07-01-at-2.41.08-PM.png
источник

A

Alex in Data Engineers
ну и из вашей же документации

A multi-master cluster doesn't have a reader endpoint. The reader endpoint load-balances incoming connections, freeing you from knowing which DB instance is handling a particular connection. In a multi-master cluster, managing connections involves being aware which DB instance is used for each connection. That way, modifications to a particular database or table can always be routed to the same DB instance.
источник

DM

Daniel Matveev in Data Engineers
Denis Gabaydulin
В пейпере про это есть. Clock skew.
что именно? допущения от расхождений или что делать если оно сильно разъехалось?
источник

DG

Denis Gabaydulin in Data Engineers
Denis Gabaydulin
В пейпере про это есть. Clock skew.
Да. По сути, если часы не синхронизированны оно даже не стартанет, если вовремя работы убежали вперед, это не проблема. Если откатились назад, то смотря насколько. В каких то случаях, нода может быть даже помечена как "плохая".
Если у вас настроен ntp, это полностью закрывает проблему. По крайней мереза годы эксплуатации кассандры ( а там тоже используется время для LWW),такой проблемы не возникло ни разу.
источник

AS

Andrey Smirnov in Data Engineers
Denis Gabaydulin
Правильно, потому что локи под contention приводят к плохой производительности (вы либо ждете на спинлоке, либо проваливаетесь в планировщик).
Акторная модель по сути победила.
причем тут акторная модель-то?
источник

DG

Denis Gabaydulin in Data Engineers
Alex
ну и из вашей же документации

A multi-master cluster doesn't have a reader endpoint. The reader endpoint load-balances incoming connections, freeing you from knowing which DB instance is handling a particular connection. In a multi-master cluster, managing connections involves being aware which DB instance is used for each connection. That way, modifications to a particular database or table can always be routed to the same DB instance.
Нормальный трейдофф. Там скорее всего отдельные кластера. Для oltp вам же главное чтобы данные одной партиции быстро пичались и читались, а также HA и scaling out.
Единственное ее понятно, как они делают например кросс партишн апдейты, но аврору я глубоко не изучал.  Не знаю.
источник

AZ

Anton Zadorozhniy in Data Engineers
Denis Gabaydulin
Ну если слышали тогда зачем чушь пишите?
В вольте алгоритм консенсуса основан на глобальном порядке unique ids (которые зависят от времени), подробно описано в h-store paper.
так волл клок это вполне себе алгоритм консенсуса, почему чушь?
источник

DG

Denis Gabaydulin in Data Engineers
Andrey Smirnov
причем тут акторная модель-то?
Так вы сами цитату привели. Это оно и есть внутри.
источник

AZ

Anton Zadorozhniy in Data Engineers
Denis Gabaydulin
Да. По сути, если часы не синхронизированны оно даже не стартанет, если вовремя работы убежали вперед, это не проблема. Если откатились назад, то смотря насколько. В каких то случаях, нода может быть даже помечена как "плохая".
Если у вас настроен ntp, это полностью закрывает проблему. По крайней мереза годы эксплуатации кассандры ( а там тоже используется время для LWW),такой проблемы не возникло ни разу.
у вас наверное не очень нагруженная кассандра и/или на очень хорошем железе, ну или вы просто этого не заметили, я за год на AWS два раза поймал такое
источник

AS

Andrey Smirnov in Data Engineers
Denis Gabaydulin
Так вы сами цитату привели. Это оно и есть внутри.
однопоточность != actor model
источник

DG

Denis Gabaydulin in Data Engineers
Andrey Smirnov
однопоточность != actor model
Да, разумеется. Но на практике, в таком случае приходят именно к такой модели.
источник

DG

Denis Gabaydulin in Data Engineers
Anton Zadorozhniy
у вас наверное не очень нагруженная кассандра и/или на очень хорошем железе, ну или вы просто этого не заметили, я за год на AWS два раза поймал такое
Что именно?
источник