Как оптимизировать БД для highload проекта на перспективу?
Привет всем. Подскажите пожалуйста, кто имел дело с highload проектами. Возьмем в качестве примера обычную CRM систему, в которой есть компании заводящие сделки. Как правило для каждой компании создается свой поддомен в рамках которого она работает. Теперь сам вопрос, как для таких целей правильно организовать БД? У меня есть 2 варианта:
1. Для каждой компании создается своя БД с которой она работает. Что это дает:
+ Компании со 100% вероятностью не увидят данных друг друга, в случае если в коде затаится бага проверки прав доступа
+ через несколько лет данных в этой базе будет гораздо меньше, чем если бы была одна общая база на всех, а значит выборка будет шустрее и производительность повыше
- При развитии проекта, придется вносить правки по БД абсолютно для все БД, а если их будет 10к и более - это весьма проблематично
2. Все компании работают с одной и той же БД. Плюсы и минусы как и в первом пункте, только наоборот.
Если делать по второму пункту, и через несколько лет данных в таблице будет более 20млн. Как быть? Как в таком случае поступают? Может делают дубль таблицы и туда заливают новые данные, тогда как быть, если потребуются старые сделки?
Конечно первый вариант. Базы ж не пересекаются, а для внесения правок напишите скрипты. Это гораздо будет дешевле, чем разбивать.
А вообще, что для вас Higload. 20 млн строк - это мелочевка. Помню я скорость тестировал на 1 млрд строк.
Нужны следующие данные:
1) размер строки
2) что чаще чтение или запись
3) какая допустимая скорость ответа
4) количество одновременных запросов
5) типы запросов
20кк - это я так, чисто условно написал. Естественно, если учесть что допустим имеется 10к компаний. Каждая заводит в среднем 10 сделок в день. Получается в год уже 36кк. Не говоря уже про различные реляционные таблички для MANY_MANY связей. Допустимая скорость ответа не более 0.7 сек. По поводу что чаще, тут нет однозначного ответа. К примеру для таблицы с клиентами чаще чтение, для сделок 50\50. Про репликации я знаю, но это получится куча дублей БД. Проще было бы действительно разделить базы между собой)
Одна база + хороший программист.
От записей зависит в меньшей мере, больше от рук. У нас в проекте за 2 года чуть более 20млд записей (в самой большой таблице), работает очень шустро, в секунду добавляется/удаляется/изменяется не менее 40т строк.
Вам бы по обычным БД подтянуться. Даже в одной базе они не увидят данные друг друга.
Удаляйте старые данные из БД или переносите их в архивную таблицу или в архивную БД.
