Size: a a a

2020 January 20

AZ

Anton Zadorozhniy in Data Engineers
Denis Gabaydulin
Что именно?
потерянный апдейт
источник

DG

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

DG

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

AZ

Anton Zadorozhniy in Data Engineers
Denis Gabaydulin
Такое возможно, для LWW. Я скорее о том, что часы на нормально сконфигурированной машине с доступом к интернету, не должны часто разъезжаться. И когда они немного отстают можно немного подождать. В общем throughout это по идее не должно быть заметно.
как раз в облаках на виртуалках часы едут постоянно,  ну и кому нужен throughput когда мы сериализацию теряем?
источник

DG

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

AZ

Anton Zadorozhniy in Data Engineers
Denis Gabaydulin
Строго говоря да. Меня смутила ваша фраза "упираться в консенсус". Если бы тут был какой нибудь paxos с его кучей лишних хопов, то да. Но в данном случае, этот "консенсус" не будет узким местом.
кмк тут спор куда-то не туда зашел, вы пытались показать что newsql дает масштабируемость sql acid как у nosql и без уступок в плане гарантий? кмк у вас не очень получилось, в каждом примере оказывается что есть какие-то доп ограничения..
источник

DG

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

AZ

Anton Zadorozhniy in Data Engineers
Denis Gabaydulin
Хороший вопрос про облака. Возможно voltdb в облаках не взлетит, не знаю.
в изначальной Dynamo whitepaper, по которой C* написана, вместо wall clock используются векторные часы, просто эту фичу посчитали лишней
источник

DG

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

DG

Denis Gabaydulin in Data Engineers
Вектора клока per row уже нет.
источник

A

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

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

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

DG

Denis Gabaydulin in Data Engineers
Anton Zadorozhniy
кмк тут спор куда-то не туда зашел, вы пытались показать что newsql дает масштабируемость sql acid как у nosql и без уступок в плане гарантий? кмк у вас не очень получилось, в каждом примере оказывается что есть какие-то доп ограничения..
Я бы сказал не ограничения, а особенности архитектуры, которые есть абсолютно в любой базе. Запустить запрос, которые модифицирует 3/4 партиций, да это будет медленно, но это будет медленно на любой базе, даже single instance pg. А уж про kv молчу.
Главное, что получилось показать, что вполне можно иметь OLTP систему, которая горизонтально масштабируется и имеет strict serializable.
источник

DG

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

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

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

A

Alex in Data Engineers
Denis Gabaydulin
Диалект очень близок к ansi sql.
https://github.com/apache/spark/commit/17857f9b8bdf95eb64735eb986e86bf8fd8bc1a9

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

DG

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

DG

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

update xxx set a = 1 where b > 1

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

DG

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

A

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

AZ

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

DG

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