MaxDukov
@MaxDukov
впишусь в проект как DevOps.

Гео-распределеная БД/шардинг?

Коллеги, хочется немного странного.
есть некий сервис аутентификации. Сейчас сервер исключительно в европе, есть желание утащить второй сервер в азию.
данные лежат в Postgre, но сие не догма. Пользователи, пришедшие в европейски сервер, вот так сразу на азиатский не придут, но потенциально могут.
что можно сделать "в лоб" - асинхронную репликацию. Вроде как не сложно и даже должно работать, но. В некоторой перспективе пользователей может быть МНОГО, но при этом мигрирующих между серверами доли процента. Синкать прям всех как-то не слишком эффективно.
Что хочется - некий извращенный шардинг(?). Т.е. европейских пользователей пишем в европейский сервер, азиатских в азиатский, но читать надо все (своих быстро, "чужих" - ну, как получится). Это вообще реально?
  • Вопрос задан
  • 424 просмотра
Пригласить эксперта
Ответы на вопрос 6
@Drno
Поставить обратный прокси, и на основе IP адреса кидать на разные сервера?
Хз можно ли так с БД делать...
Ответ написан
BojackHorseman
@BojackHorseman Куратор тега MySQL
...в творческом отпуске...
я бы поднял db-линки между серверами
Ответ написан
@ky0
Миллиардер, филантроп, патологический лгун
Что хочется - некий извращенный шардинг(?). Т.е. европейских пользователей пишем в европейский сервер, азиатских в азиатский, но читать надо все (своих быстро, "чужих" - ну, как получится). Это вообще реально?

Пользователи "своего региона" пусть быстро авторизовываются в локальной базе, а те немногие, которым не повезёт - в другой. Для последних это будет чуть дольше, но в целом, наверное - ничего страшного.

На случай неполадок с каналом до "удалённой" базы можно, наверное, периодически их синхронизировать между собой, чтобы в крайнем случае подсунуть не самые свежие реквизиты. Но пароли обычно достаточно редко меняются, в большинстве случаев должно проканать.
Ответ написан
firedragon
@firedragon
Senior .NET developer
У европейского сервера
своя база
у азиатского своя

Соответственно запросы у европейского
1. Европейская - быстрый ответ
2. Азиатская - медленный ответ и добавление в европейскую базу
3. Ничего - два запроса , но тут так получилось

У азиатского наоборот
Ответ написан
@le1ic
Не нужно оверэнжинирить. Если пользователю нужно мигрировать, он сам может создать новый эккаунт в другом DC.
Ответ написан
@boss_lexa
между европой и азией RTT примерно 200 мс (Германия-Сингапур)
https прошлых версии требует = 3-4 RTT (600-800 мс) + DNS
если у вас настроено TLS v 1.3 + 0-RTT = 2-3 RTT (400-600) + DNS
подробнее тут https://blog.cloudflare.com/introducing-0-rtt/

Приложение и БД должны быть в одном датацентре (регионе) иначе каждый http-запрос будет отрабатываться как кол-во sql-запросов * RTT 200 мс = долго)

соотвественно если у вас трафик азии приземляется только на единственный сервер в европе пользователи из азии тратят больше на подключение, на 600-800 мс больше.

если вы купите слугу CDN для ускорения динамического сайта (или настроите свои сервера) и ваш https будет терминироваться в азии, а само приложение и бд останется все также в европе - оставшаяся задержка сократиться до 1 RTT = 200 мс,

также к этому прикручиваете быстрый anycast DNS, например Cloudflare (только DNS, без СDN) или AWS route 53 (он еще от ddos 3,4 уровня защищен)
тут статистика DNS сервисов по latency https://www.dnsperf.com/

если будете смотреть CDN выбирайте тут: https://www.cdnperf.com/
но услуга ускорение динамики есть не у всех

если хотите свое - можно использовать AWS Global Accelerator (в нем дают anycast ip) это даст:
- терминацию TCP близко к пользователя
- приоритетную сеть с меньшими задержками
- защиту от Ddos 3,4 уровня
- быстрое переключение на резервный датацентр/регион если основной упал
+ пару дешевых региональных EC2 под терминацию Https

как аналог еще смотрите Azure Front Door

Как уменьшить оставшиеся 200 мс:

1) Если использовать синхронную рекликацию между континентами, например как mysql galera/percona xtradb cluster - скорость чтения будут локальной, но кол-во транзакций записи в секунду будет очень медленным, тк упрется в RTT, а если оно 200 мс = 5 транзакций/секунда

2) Если делать шардинг пользователей по континентам, то будут возникать проблемы если у вас есть кроссшардовые операции или может быть решардинг (пользователь переезжает в другой континент).
Есть CockroachDB которые завляюят что у них это все это решается "из коробки" - на практике хз.

4) Если вам подходит eventual consistency и split brain на короткое время не сломает ваше приложение - можно попробовать БД, которые будут использовать Согласованность в конечном счёте используя асинхронную репликацию

Но так ли критично уменьшение этих оставшихся 200 мс?
Стоит ли использовать новые необкатанные БД в production с которыми нет опыта решение проблем ради оставшихся 200 мс?
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы