xenon
@xenon
Too drunk to fsck

Нужно ли прорабатывать масштабирование / шардинг при использовании облачных БД?

Есть собственное веб-приложение, которое (в нынешнем варианте) хранит данные в MySQL на том же сервере. Отлично работает в масштабе одного сервера при текущей (довольно невысокой) нагрузке, но возникает интерес, как оно будет работать, если вдруг внезапно на нем окажется в тысячу раз больше пользователей (и все таблицы в базе станут гораздо больше, каждый запрос будет более трудоемким да и сумма запросов на базу вырастет) ?

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

Если перейти, например, на AWS RDS (или посоветуете какие-то другие варианты?), придется ли как-то использовать похожие схемы (отдельные базы данных/шарды для каждой группы пользователей) или можно тупо не волноваться о нагрузке, она любую разумную нагрузку вытянет? (А суммы, которые придется за это платить, будут больше, чем если переобдумать схему масштабирования)?

Вообще, есть какие-то может быть хорошие гайды по легкому масштабированию для моего случая (когда каждый юзер работает исключительно со своими данными). В каждой таблице (коих немало) иметь поле user_id и по нему индексировать, и в каждом запросе указывать WHERE user_id=NNN ? Но это кажется довольно трудоемким и много шансов где-то в коде пропустить это условие. Напрашивается простое решение, чтоб у каждого юзера все его данные были в его базе данных (очень небольшой) и приложение работало с ней. Но тогда у нас будет очень много баз данных, и это будет немного некрасиво как-то. Может быть как-то можно получить аналогичный эффект сохранив простоту и надежность и малый риск ошибок?
  • Вопрос задан
  • 146 просмотров
Решения вопроса 1
inoise
@inoise Куратор тега Amazon Web Services
Solution Architect, AWS Certified, Serverless
Буду довольно резким, но зато без воды:
- облачные провайдеры не умеют в магию, только в создание ресурсов
- реляционные базы даже сегодня умеют только в вертикальное масштабирование
- да, думать приходится самостоятельно
- для облегчения жизни можно использовать Read Replicas, но готовьтесь к задержкам
- спайковую нагрузку реляционные базы выдерживать не умеют (да и остальные делают это из рук вон плохо)

Рекомендации:
- планируйте масштабирование
- научитесь понимать как используются ваши данные
- научитесь в микросервисы (и не по тому что это популярно, а по тому что так происходит изоляция данных)
- научитесь в другие виды баз данных, например то же DynamoDB, хотя если не вникать то можно огрести еще больше проблем
- вспомните что есть кэширование
- прочитайте что есть такие паттерны как CQRS
- научитесь в проектирование PWA (Progressive Web Applications)
- выбросите это все по тому что это будет очень дорого по итогу
Ответ написан
Пригласить эксперта
Ответы на вопрос 1
@vitaly_il1
DevOps Consulting
Отлично работает в масштабе одного сервера при текущей (довольно невысокой) нагрузке, но возникает интерес, как оно будет работать, если вдруг внезапно на нем окажется в тысячу раз больше пользователей

Ответ очень простой - проверить с помощью stress test. То есть проанализировать текущий запросы к базе и симулировать х1000 кол-во пользователей. 90% что можно обойтись без шардинга, но опят покажет.
Плюс - с самого начала пишите аппликацию так, чтобы read-only запросы можно было направлять на отдельный ДБ сервер, это уменьшит нагрузку на master.
Ответ написан
Ваш ответ на вопрос

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

Похожие вопросы