Тут важно понимать, что у userver и у нас разная аудитория :) Нашему серверу в проде всё равно запускаться пока что только на x86-64, а пользователи, которые отлаживаются на маках, после наших изменений вполне довольны жизнью)
Конечно, есть сценарии, когда Docker Desktop может оказаться лучше. Но конкретно в нашем сценарии, когда на ARM запускаем x86-64 бинарь, Colima с Rosetta 2 работает гораздо лучше.
Представьте ситуацию: Вы работаете, а тут пришло напоминание о встрече. Взяли ноутбук и пошли в переговорку. Конечно, же многие забывают погасить докеры и т.п. Да и неудобно каждый раз запускать и останавливать.
Да, именно так. Теперь ноут гораздо реже просыпается вне зависимости от того докер это или нативное исполнение, благодаря чему работает намного дольше.
Извините, но я с Вами не соглашусь. Линейный не означает, что коэффициент строго равен единице. Линейная функция может иметь произвольные коэффициент и константу. Но Вы правильно отметили, что с коэффициентом 1 масштабироваться в большинстве случаев нереально.
Рад, что статья понравилась :) Мне кажется, что либо пытаться ориентироваться на TPC-C, либо, что лучше и правильнее, использовать свой бенчмарк, соответствующий профилю нагрузки.
Вася сначала прочитал старые данные, которые были закомичены когда-то давно, с шарда, куда еще не дошёл коммит новых. Потом с другого шарда, где уже случился коммит Алисы, т.е. тоже данные закомичены. Поэтому в примере "Read Committed". Интересно, что в случае "Read Uncommitted" конкретно в данном примере получился бы консистентный результат.
ну прийдет ему попап на телефон, на минуту позже. Никакой разницы Васе, что он узнал о транзакции позже (если он не собирается ее обновлять).
Кажется я понял, в чём недопонимание. Проблема не в том, что Вася узнаёт что-то с задержкой, а в том, что он видит неправильный результат. Eventually consistency означает не задержку, с которой результат транзакции становится видим всем, а то, что какое-то время виден неверный результат.
Дедлок, только если делать SELECT FOR UPDATE на разные ноды. Понятно, что не надо так делать.
В этом и заключался первоначальный вопрос. И вопрос правильный, так как эта конструкция часто используется, чтобы достичь serializable изоляции. Кроме того, отсутствие многошардового SELECT FOR UPDATE является еще одним хорошим примером того, как шардированный PostgreSQL отличается от монолитного.
Не знаю как в Citus, но в простейшем случае - 2РС должен сломаться (rollback) на одной из транзакций, которая попытается commit после commit другой.
Это очень интересный вопрос. И тут важно всегда помнить, что в случае Citus-подобных решений шард – полноценный PostgreSQL, который ничего не знает о других шардах-постгресах.
SELECT FOR UPDATE в citus ограничен одним шардом. Представьте две транзакции, которые берут локи на одни и те же строки на каждом из двух шардов. Будет дедлок.
В случае Алисы и Васи координатор выполняет исключительно роль маршрутизатора и координатора 2PC. Нужна более сложная логика, чтобы превратить его в координатора распределенных транзакций.
Транзакция Васи только читает, а пишет транзакция Алисы. Когда транзакция Алисы пишет в несколько шардов, то транзакция Васи может прочитать часть старых данных и часть новых, но уже закомиченных.
И вывод - отсутствие консистенции в данных, но эту задержку в консистентности 'Вася' узнает, только если ему сказать, что данные поменялись в независимым способом, но в 'своей' ноде он этого пока не видит.
Проблема в том, что Вася видит лишь часть изменений, что и создаёт неконсистентность. Если бы он видел только старые данные или только новые, то всё было бы хорошо.
Тут важно понимать, что у userver и у нас разная аудитория :) Нашему серверу в проде всё равно запускаться пока что только на x86-64, а пользователи, которые отлаживаются на маках, после наших изменений вполне довольны жизнью)
Под ARM64 у нас только CLI и SDK. Сам сервер YDB бы собираем сейчас только x86-64.
Конечно, есть сценарии, когда Docker Desktop может оказаться лучше. Но конкретно в нашем сценарии, когда на ARM запускаем x86-64 бинарь, Colima с Rosetta 2 работает гораздо лучше.
Мы планируем продолжить работу в этом направлении, но конкретных планов пока нет.
Тогда попробуйте OrbStack или Colima. Всё должно стать сильно лучше.
Представьте ситуацию: Вы работаете, а тут пришло напоминание о встрече. Взяли ноутбук и пошли в переговорку. Конечно, же многие забывают погасить докеры и т.п. Да и неудобно каждый раз запускать и останавливать.
Да, именно так. Теперь ноут гораздо реже просыпается вне зависимости от того докер это или нативное исполнение, благодаря чему работает намного дольше.
Просто мы считали, что предмет нашего рассказа достаточно известен в определенных кругах :)
Извините, но я с Вами не соглашусь. Линейный не означает, что коэффициент строго равен единице. Линейная функция может иметь произвольные коэффициент и константу. Но Вы правильно отметили, что с коэффициентом 1 масштабироваться в большинстве случаев нереально.
Рад, что статья понравилась :) Мне кажется, что либо пытаться ориентироваться на TPC-C, либо, что лучше и правильнее, использовать свой бенчмарк, соответствующий профилю нагрузки.
Вася сначала прочитал старые данные, которые были закомичены когда-то давно, с шарда, куда еще не дошёл коммит новых. Потом с другого шарда, где уже случился коммит Алисы, т.е. тоже данные закомичены. Поэтому в примере "Read Committed". Интересно, что в случае "Read Uncommitted" конкретно в данном примере получился бы консистентный результат.
Да, это наш официальный репозиторий. Если будут вопросы, то у нас есть группа в tg, где мы помогаем пользователям.
К сожалению (или к счастью), абсолютного победителя пока нет. Но мы в YDB над этим усиленно работаем :)
Да, я с Вами согласен: всё зависит от требований приложения. Иногда можно показать неверные сходящиеся данные, а иногда это может быть проблемой.
Кажется я понял, в чём недопонимание. Проблема не в том, что Вася узнаёт что-то с задержкой, а в том, что он видит неправильный результат. Eventually consistency означает не задержку, с которой результат транзакции становится видим всем, а то, что какое-то время виден неверный результат.
Алисой
В этом и проблема, что Вася этого знать не будет. И сказать ему некому. Он начнёт звонить Алисе и в банк :)
В этом и заключался первоначальный вопрос. И вопрос правильный, так как эта конструкция часто используется, чтобы достичь serializable изоляции. Кроме того, отсутствие многошардового
SELECT FOR UPDATEявляется еще одним хорошим примером того, как шардированный PostgreSQL отличается от монолитного.Извините, но я не понял, что Вы имеете в виду.
Это очень интересный вопрос. И тут важно всегда помнить, что в случае Citus-подобных решений шард – полноценный PostgreSQL, который ничего не знает о других шардах-постгресах.
SELECT FOR UPDATEв citus ограничен одним шардом. Представьте две транзакции, которые берут локи на одни и те же строки на каждом из двух шардов. Будет дедлок.В случае Алисы и Васи координатор выполняет исключительно роль маршрутизатора и координатора 2PC. Нужна более сложная логика, чтобы превратить его в координатора распределенных транзакций.
Транзакция Васи только читает, а пишет транзакция Алисы. Когда транзакция Алисы пишет в несколько шардов, то транзакция Васи может прочитать часть старых данных и часть новых, но уже закомиченных.
Проблема в том, что Вася видит лишь часть изменений, что и создаёт неконсистентность. Если бы он видел только старые данные или только новые, то всё было бы хорошо.