Я постарался раскрыть этот момент в разделе "Как поменять схему шардирования", но возможно не очень понятно получилось)
1) остановить запись
Вот этого не происходит, конечно же. Мы не можем просто взять и прервать обработку заказов, даже на несколько минут. Первым шагом мы учим узлы сервиса искать данные одновременно и в старом и в новом шарде. Благодаря этому, записи (как от сервиса, так и любую сбоку) можно делать в любой шард.
Но пока вы как-то копируете данные, эти данные обновляются на старом шарде
Чтобы такого не случилось, нужно перестать записывать новые данные в старый шард. Тогда после копирования старый шард будет "не свежее", чем новый.
В таком подходе способ копирования будет не принципиален, потому что переливать данные можно сколь угодно долго без потери консистентности. Поэтому у нас это простой фоновый скрипт.
Транзакции в такой все-таки нужны, чтобы атомарно работать с цепочкой событий. Но, в основном, выбор был скорее субъективный, так как была хорошая поддержка постгре в userver'e.
Выбор шарда делается по формуле из статьи. То есть вычисляется хеш от PK и от него номер шарда (из фиксированного кольца). В этом смысле схема довольно типичная. Отличие тут в способе выполнения решардирования.
В этой статье не рассказывается, но в реальности, хранилище разделяется на горячую и холодную часть (на основе YTsaurus).
Да, конечно, следим за опытом коллег. Но этот кейс не очень релевантный, так как процессинг не работает с координатами (этим занимается отдельный микросервис). Процессинг отвечает за цикл заказа, то есть за продвижения автомата заказа по стадиям, а это не очень интенсивная по update'ам задача.
Скорее так:
1) Раскатка чтения в режиме "по двум схемам"
2) Переключение записи со старой схемы на новую
3) Миграция + валидация
4) Отрыв старой схемы
На тот момент хороших решений из коробки не было - они либо вносили большую задержку, либо требовали кастомизацию постгре.
Пока таких планов не было. Реализацию довольно сложно будет обобщить.
Я постарался раскрыть этот момент в разделе "Как поменять схему шардирования", но возможно не очень понятно получилось)
Вот этого не происходит, конечно же. Мы не можем просто взять и прервать обработку заказов, даже на несколько минут. Первым шагом мы учим узлы сервиса искать данные одновременно и в старом и в новом шарде. Благодаря этому, записи (как от сервиса, так и любую сбоку) можно делать в любой шард.
Чтобы такого не случилось, нужно перестать записывать новые данные в старый шард. Тогда после копирования старый шард будет "не свежее", чем новый.
В таком подходе способ копирования будет не принципиален, потому что переливать данные можно сколь угодно долго без потери консистентности. Поэтому у нас это простой фоновый скрипт.
На момент выбора много лет назад YDB еще не была достаточно зрелой технологией. А на текущий момент мы действительно переезжаем на YDB.
Транзакции в такой все-таки нужны, чтобы атомарно работать с цепочкой событий. Но, в основном, выбор был скорее субъективный, так как была хорошая поддержка постгре в userver'e.
Выбор шарда делается по формуле из статьи. То есть вычисляется хеш от PK и от него номер шарда (из фиксированного кольца). В этом смысле схема довольно типичная. Отличие тут в способе выполнения решардирования.
В этой статье не рассказывается, но в реальности, хранилище разделяется на горячую и холодную часть (на основе YTsaurus).
Да, конечно, следим за опытом коллег. Но этот кейс не очень релевантный, так как процессинг не работает с координатами (этим занимается отдельный микросервис). Процессинг отвечает за цикл заказа, то есть за продвижения автомата заказа по стадиям, а это не очень интенсивная по update'ам задача.