можно конечно тыкнуть два теста, один олтп, второй олап чтобы показать проблемы фдв, но про них вроде и так знают, просто "не горело"

опять же с патчами на фдв можно попробовать показать что они ппц нужны

ну так а если без шардинга через фдв, то как?

самый скучный вариант просто симулировать ноду, которая делает импорт снапшотов

и вот тут пул книжника!

ггг

можно конечно тыкнуть два теста, один олтп, второй олап чтобы показать проблемы фдв, но про них вроде и так знают, просто "не горело"

ну вот скорее всего, надо транзакции потяжелее сделать, но не OLAP, так чтоб пару секунд была транзакция

энивей тебе придется защищать применимость клок-сиай а не другой штуки и на самом основном профиле нагрузки

и вот тут пул книжника!

ага, и сингулярность настанет)

так что тесты делать надо и такие и такие, главное не преподносить как раньше "на трех нодах всё хуже чем на одной" шардить надо

энивей тебе придется защищать применимость клок-сиай а не другой штуки и на самом основном профиле нагрузки

а другой нет)

ну как же

http://cs-www.cs.yale.edu/homes/dna/pubs/displaypubs.cgi

ну как же

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

ну это да

есть еще кучка вариантов с отдельной нодой для снапшотов типо PostgresXL или Greenplum (у них не отдельная правда, а координатор к которому ты подключен)

но оно совсем не про OLTP

я скорее боюсь, что могут времени физического испугаться

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

так что да, надо отдельно тестить перфоманс на разном кол-ве горячих ключей

http://cs-www.cs.yale.edu/homes/dna/papers/rethink-mvcc.pdf слайд номер 9 например, на 11 странице

а как у тебя кстати транзакция узнает что хватит ждать?

а как у тебя кстати транзакция узнает что хватит ждать?

пытается взять лок на xid. Когда взяли знаем, что транзакция с таким xid-ом завершилась и отпустила лок на этот xid

а, то ее разбудят по стандартному флоу?

так что да, надо отдельно тестить перфоманс на разном кол-ве горячих ключей

думаю worst case будет для чего-то типо одни транзакции делают update и прописывают updated_at, а другие выбирают все с updated_at > now - 100ms. Тогда постоянно много in-progress надо читать будет

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

чтобы не лочил лол

будет и снапшот ту олд и снапшот ту лардж

а, то ее разбудят по стандартному флоу?

угу. Ждем постгресового коммита обычного. Но там есть тонкий момен, транзакция сначала становится видимой по постгресовомы снапшоту (удалили из procArray), потом ей ставится CSN и только после этого она отпускает локи. Поэтому этот трюк с локом на xid ждет чуть дольше чем до коммита, и этим снимается дырка, когда её закоммитили, но CSN еще не поставили

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

ну вот про них мало чего читал, но а почему бы и нет, если не делаем general purpose db

в вертике 100 апдейтов в секунду

и для csn надо сходить на все ноды кластера время узнать, то ждем + раундтрип

в вертике 100 апдейтов в секунду

и ничего норм, зато батч заливка терабайтами в секунду

в вертике 100 апдейтов в секунду

ей можно

и для csn надо сходить на все ноды кластера время узнать, то ждем + раундтрип

это все можно вместе с PREPARE / COMMIT PREPARED делать

то есть кол-во хождений по сети такое же как и при обычном 2PC

а за временем надо идти на препаре же да?

и на коммит сказать с каким коммитить

ага, всё так

тогда между удалением из прокаррей и видимостью какая пауза?

удаляется же небось на коммите а не на препаре

тогда между удалением из прокаррей и видимостью какая пауза?

удаление из прокаррей == видимость пауза там у тех кто ждет InDoubt транзакций. Им нельзя просто подождать пока удалять из ProcArray, им надо ждать пока CSN появится. А появится он чуть позже. Но лок на xid транзакция отпустит еще чуть позже поэтому ок

можно было быть писать CSN под тем же локом, что и удаление из ProcArray, но это слишком

слишком дорого

и хочу еще узнать про то куда именно идти за координацией времени csn если у меня есть ноды А Б и Ц, они пошаржены пополам и не пересекаются я делаю какую-то работу на А и мне понадобилось сходить на Б за какой-то строкой иду, а там транзакция которую мне надо ждать, пусть она будет Y предположим что Y менял данные только на ноде Б и Ц так вот, на коммите Y пойдет синкать время на А или только на Б и Ц?

удаление из прокаррей == видимость пауза там у тех кто ждет InDoubt транзакций. Им нельзя просто подождать пока удалять из ProcArray, им надо ждать пока CSN появится. А появится он чуть позже. Но лок на xid транзакция отпустит еще чуть позже поэтому ок

>надо ждать пока CSN появится так его же сказали на коммите, чего ждать? сеть или что

и еще, если мы берем лок на чужой xid чтобы проверить когда транзакция закончится предположим что у нас два читальщика ждали лок на писателя они смогут одновременно начать работу после коммита писателя или второму читальщику надо дождаться первого

и хочу еще узнать про то куда именно идти за координацией времени csn если у меня есть ноды А Б и Ц, они пошаржены пополам и не пересекаются я делаю какую-то работу на А и мне понадобилось сходить на Б за какой-то строкой иду, а там транзакция которую мне надо ждать, пусть она будет Y предположим что Y менял данные только на ноде Б и Ц так вот, на коммите Y пойдет синкать время на А или только на Б и Ц?

время синкается не на коммите, а на старте транзакции: на одной ноде делаем export snapshot, полчаем 100. На другой говорим import 100, она ставит себе этот снапшот. При этом если локальное время на второй 95 на этот момент, то надо будет ждать 5 единиц времени

>надо ждать пока CSN появится так его же сказали на коммите, чего ждать? сеть или что

да просто запись в два места в памяти. Можно прочитать между случайно, если запись без лока/мьютекса. А она без лока по соображениям производительности. Но это конкретные детали. Можно и по-другому было делать

и еще, если мы берем лок на чужой xid чтобы проверить когда транзакция закончится предположим что у нас два читальщика ждали лок на писателя они смогут одновременно начать работу после коммита писателя или второму читальщику надо дождаться первого

одновременно смогут

время синкается не на коммите, а на старте транзакции: на одной ноде делаем export snapshot, полчаем 100. На другой говорим import 100, она ставит себе этот снапшот. При этом если локальное время на второй 95 на этот момент, то надо будет ждать 5 единиц времени

то есть мы пойдем по всем нодам узнавать csn при экспорте снапшота?

потому что в алгоритме ты пишешь что нода экспортирует глобал цсн

чото у меня всё запуталось

то есть мы пойдем по всем нодам узнавать csn при экспорте снапшота?

Не. Поработали на ноде А, поняли что надо еще куда-то пойти, сделали export snapshot. Потом на какую бы ноду не пошли делаем перед стейтментами import snapshot

а экспорт снапшот какое время пишем? свое только?

а экспорт снапшот какое время пишем? свое только?

да

а на импорт они сравнивают со своим

в пункте три ты просто пишешь When local transaction imports foreign global snapshot with some GlobalCSN и это сбивает

ну и в пункте один кажется что indoubt это всё что сделало export snapshot а не только между фазой препаре и коммит

или препаре это и есть у тебя экспорт снапшот

indoubt только между препаре и коммит

супер

осталось письмо поправить :)

просто видимость на CSN так устроена: CSN-ы это счетчик коммитов. Но если ты ведешь такой счетчик, то снапшот это просто значение этого счетчика на момента старта транзакции

без всяких массивов ксидов как сейчас в постгресе

меня путает цсн и глобалцсн когда вижу глобал - читаю как "спросить всех"

а

я вставлял глобал, чтоб подчеркнуть, что это время

на случай если обычные CSN-ы закоммитят)

и хочу еще узнать про то куда именно идти за координацией времени csn если у меня есть ноды А Б и Ц, они пошаржены пополам и не пересекаются я делаю какую-то работу на А и мне понадобилось сходить на Б за какой-то строкой иду, а там транзакция которую мне надо ждать, пусть она будет Y предположим что Y менял данные только на ноде Б и Ц так вот, на коммите Y пойдет синкать время на А или только на Б и Ц?

так вот в этом кейсе транзакция Y пойдет собирать пропоузд глобал цсн на все три ноды или только там где данные поменяла (Б и Ц) а если она на Ц только читала а меняла на Б

то есть в пункте два, что такое each participant

так вот в этом кейсе транзакция Y пойдет собирать пропоузд глобал цсн на все три ноды или только там где данные поменяла (Б и Ц) а если она на Ц только читала а меняла на Б

импорт снапшота надо делать везде где читать/писать будешь. Препаре/коммиты с обменом CSN-ами делать надо только там где запись была

то есть если Y началась на Б, когда читала на Ц сделала экспорт и импорт снапшота туда. тут все понятно потом она хочет коммитить на Б, на Ц ничего не меняли, только читали тут будет какой-то препаре или просто коммит на Б?

или мы даже ничего экспортировать не будем потому что ходили только читать?

чет сложно. Может с примером будет понятнее: on nodeA: begin; export global snapshot; -> 3000 --some useful r/w work prepape transaction 'mytx' returns snapshot; -> 4001 commit prepared 'mytx' with snapshot '4002'; on nodeB: begin; import global snapshot '3000'; --some useful r/w work prepape transaction 'mytx' returns snapshot; -> 4002 commit prepared 'mytx' with snapshot '4002'; on nodeC: begin; import global snapshot '3000'; --some useful r/o work commit; (или abort, без разницы, мы же ничего не писали)

транзакция началась на ноде_А, сходила и поменяла что-то на ноде_B и прочитала что-то с ноды_C

а если было только А с rw и С с ro

импортим снапшот на все ноды, препарим только там где меняли, собирает CSN с препар (4001, 4002), коммитим с максимыльным 4002

на А будет коммит локальный просто?

на А будет коммит локальный просто?

ага

вопросов больше нет, спасибо большое

про краш рекавери, нетворк сплит и репликацию потом

вопросов больше нет, спасибо большое

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

про краш рекавери, нетворк сплит и репликацию потом

а это не затрагивается) то есть здесь ручки чтоб изоляцию делать, а как уж сделать fault-tolernt коммит это отдельная история

ты можешь написать в хакерс по результатам моих распросов какие-то коммон сценарии работы чтобы понятнее было почему клок-сиай 1. приемлемо 2. безопасно ну и как вообще работает

потому что топик сложный

ну и это поможет бенчмарки объяснить/пояснить что тестировали и зачем

ты можешь написать в хакерс по результатам моих распросов какие-то коммон сценарии работы чтобы понятнее было почему клок-сиай 1. приемлемо 2. безопасно ну и как вообще работает

ok

а без фдв ты как хочешь бенчмаркать? взять башку от координатора который вы писали?

я к тому что pgbench натравить надо как-то прозрачно людям

но если делать какой-то проксик, то для шардинга там надо пилить знание где что лежит

а без шардинга будет не так вкусно

а с шардингом фдв тормозит

ох

там третий патч делаешь так что бы postgres_fdw сам эти ипорты/экспорты/препаре делал. Так что просто пгбенч можно по таблице с партициями, где часть партиций это fdw

а, вопрос был без fdw

без fdw я думал просто симулировать pgbench-ем принимающую сторону: после бегина всегда делать импорт

посмотри насколько сильно у тебя конфликт будет с патчем от хоригучи [HACKERS] asynchronous execution

без fdw я думал просто симулировать pgbench-ем принимающую сторону: после бегина всегда делать импорт

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

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