Comments 17
Немного в сторону от статьи. Когда слова "такси" и "postgres" оказываются рядом, сразу вспоминается неудачная попытка Uber переехать на PG (https://habr.com/en/companies/slurm/articles/322624/) Навскидку, больнее всего стрельнул update amplification в связке с частыми обновлениями координат и репликацией.
Наверняка в начале проекта вы знали про эту историю - почему в итоге выбрали PG, а не, например YDB?
Вопрос. В какой шард попадают новые записи? Насколько я понял из статьи, Вы рассказали, как данные распределены по шардам и как получить к ним доступ.
Второй вопрос. Что делается с данными, по которым заявка закрыта?
Выбор шарда делается по формуле из статьи. То есть вычисляется хеш от PK и от него номер шарда (из фиксированного кольца). В этом смысле схема довольно типичная. Отличие тут в способе выполнения решардирования.
В этой статье не рассказывается, но в реальности, хранилище разделяется на горячую и холодную часть (на основе YTsaurus).
а почему выбрали PostgreSQL ? Транзакции особенно не нужны, индексы, кроме PK не нужны
Глядя на статью - тут прямо просится какое-нибудь Key-value хранилище
Интересно, а почему не ваша же ydb? Вроде по всем критериям подходит
На момент выбора много лет назад YDB еще не была достаточно зрелой технологией. А на текущий момент мы действительно переезжаем на YDB.
Вроде на прошлой неделе как раз была статья про переход на YDB ? Или это касалось не такси? Если всё-таки такси, то очередность статей не очень понятная - сначала написали, что отказались от Postgre в пользу YDB, а теперь описываете, как всё устроено на Postgre.
UPDATE: а, ой, это Хабр мне подсунул старую статью! А я решил, что она сегодняшняя, каюсь!
Можете подробнее рассказать, как именно копируете данные на новый шард? Репликация, силами приложения? Ведь данные постоянно обновляются, получается нужно:
1) остановить запись
2) скопировать все данные на новый шард
3) продолжить запись уже на новый шард
Понятно, что вы так не делаете, так как был бы большой простой. Но пока вы как-то копируете данные, эти данные обновляются на старом шарде и эти обновления нужно дослать на новый. А переключение записи на на новый шард можно сделать только убедившись, что все данные со старого шарда уже приехали. Иначе какой-нибудь UPDATE по условию обновит не все данные и будет не консистентно.
Я постарался раскрыть этот момент в разделе "Как поменять схему шардирования", но возможно не очень понятно получилось)
1) остановить запись
Вот этого не происходит, конечно же. Мы не можем просто взять и прервать обработку заказов, даже на несколько минут. Первым шагом мы учим узлы сервиса искать данные одновременно и в старом и в новом шарде. Благодаря этому, записи (как от сервиса, так и любую сбоку) можно делать в любой шард.
Но пока вы как-то копируете данные, эти данные обновляются на старом шарде
Чтобы такого не случилось, нужно перестать записывать новые данные в старый шард. Тогда после копирования старый шард будет "не свежее", чем новый.
В таком подходе способ копирования будет не принципиален, потому что переливать данные можно сколь угодно долго без потери консистентности. Поэтому у нас это простой фоновый скрипт.
Стандартные подходы не устраивали — поэтому команда сделала своё решение
Нельзя ли озвучить причины почему не подошли стандартные подходы?
А вы, случаем, не планировали поделиться кодом вашего решардера?
10 000 RPS и доступность 99,99%: как устроено шардирование PG в процессинге Яндекс Такси