@entermix

Стоит ли разделять БД?

Допустим есть MySQL (innoDB) база данных:

users
user_statuses
user_*
...
...

letters
letter_statuses
tasks
...
и т.д.,

Предположим, что база будет расти огромными темпами, имеет ли смысл раскидать сущности по разных БД? Допустим сделать отдельную базу, чтобы хранить пользователей, рассылку, задачи и т.д.? Поможет ли это в будущем?
  • Вопрос задан
  • 691 просмотр
Решения вопроса 1
Fesor
@Fesor
Full-stack developer (Symfony, Angular)
если вы можете ваши данные так раскидать - значит сможете потом шардинг настроить когда место закончится. А к шардингу стоит прибегать когда память не хватает (например у меня сейчас есть миленький сервачек с 256 гигов оперативки, есть ребята и покруче).
Ответ написан
Пригласить эксперта
Ответы на вопрос 4
miraage
@miraage
Старый прогер
Своевременные шардинг/репликация помогут.
Ответ написан
@hscode
Если у тебя за день тысячи посетителей, и если за месяца в базу добавиться милион записей, то стоит, а иначе нет!
Ответ написан
Комментировать
@Daje
Современные БД изначально спроектированы под работу с миллионами записей, они работают с ними достаточно хорошо.
Если ты планируешь выход на сотни миллионов записей - можешь думать о разделении сразу.

Тут лучше основную (самую нагруженную) таблицу разносить на различные сервера (например, пользователи от А до Ж на одном сервере, пользователи от З до Т на другом сервере, пользователи от У до Я на третьем сервере, если у тебя основной является таблица пользователей, если ты будешь там всех жителей Европы хранить.

С другой стороны, есть нагрузка по записи и по чтению.
С третьей стороны - если делать не только БД, а и сервера, обрабатывающие данные, то все еще круче будет.

Делать на одном сервере - смысла нет никакого, лишние заморочки.
Ответ написан
Вот когда начнёт расти "огромными" темпами, то вот тогда и только тогда будет смысл.
Кстати, "огромными" это какими?
Ответ написан
Ваш ответ на вопрос

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

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