Как оптимизировать БД для highload проекта на перспективу?

Question

[Макс]

Привет всем. Подскажите пожалуйста, кто имел дело с highload проектами. Возьмем в качестве примера обычную CRM систему, в которой есть компании заводящие сделки. Как правило для каждой компании создается свой поддомен в рамках которого она работает. Теперь сам вопрос, как для таких целей правильно организовать БД? У меня есть 2 варианта:

1. Для каждой компании создается своя БД с которой она работает. Что это дает:
+ Компании со 100% вероятностью не увидят данных друг друга, в случае если в коде затаится бага проверки прав доступа
+ через несколько лет данных в этой базе будет гораздо меньше, чем если бы была одна общая база на всех, а значит выборка будет шустрее и производительность повыше
- При развитии проекта, придется вносить правки по БД абсолютно для все БД, а если их будет 10к и более - это весьма проблематично

2. Все компании работают с одной и той же БД. Плюсы и минусы как и в первом пункте, только наоборот.

Если делать по второму пункту, и через несколько лет данных в таблице будет более 20млн. Как быть? Как в таком случае поступают? Может делают дубль таблицы и туда заливают новые данные, тогда как быть, если потребуются старые сделки?

Answer 1

[Алексей Лебедев]

Конечно первый вариант. Базы ж не пересекаются, а для внесения правок напишите скрипты. Это гораздо будет дешевле, чем разбивать.

А вообще, что для вас Higload. 20 млн строк - это мелочевка. Помню я скорость тестировал на 1 млрд строк.

Нужны следующие данные:
1) размер строки
2) что чаще чтение или запись
3) какая допустимая скорость ответа
4) количество одновременных запросов
5) типы запросов

Comments

[Евгений]

Не согласен: пробовали первый вариант, при 100+ базах начинается ад. Лучше 1 база + горизонтальный шардинг некоторых таблиц.

[Макс]

20кк - это я так, чисто условно написал. Естественно, если учесть что допустим имеется 10к компаний. Каждая заводит в среднем 10 сделок в день. Получается в год уже 36кк. Не говоря уже про различные реляционные таблички для MANY_MANY связей. Допустимая скорость ответа не более 0.7 сек. По поводу что чаще, тут нет однозначного ответа. К примеру для таблицы с клиентами чаще чтение, для сделок 50\50. Про репликации я знаю, но это получится куча дублей БД. Проще было бы действительно разделить базы между собой)

Answer 2

[Алексей]

Одна база + хороший программист.
От записей зависит в меньшей мере, больше от рук. У нас в проекте за 2 года чуть более 20млд записей (в самой большой таблице), работает очень шустро, в секунду добавляется/удаляется/изменяется не менее 40т строк.

Comments

[Робот]

Это на mysql да? innodb? Настройки дефолтные на какие примерно поменяли?

Answer 3

[sim3x]

- При развитии проекта, придется вносить правки по БД абсолютно для все БД, а если их будет 10к и более - это весьма проблематично

нет - используются миграции и автоматическое тестирование

Используют комбинированный вариант - маленькие проекты идут в одной базе, крупные проекты, которые платят больше денег - на отдельных нодах

Answer 4

[Робот]

Вам бы по обычным БД подтянуться. Даже в одной базе они не увидят данные друг друга.
Удаляйте старые данные из БД или переносите их в архивную таблицу или в архивную БД.