Как реализовать базу данных таким образом чтобы для каждого клиента она была изолированной при этом было быстродействие (MYSQl)?
Здравствуйте, я разрабатываю CRM систему для автосервисов. Проблема возникла когда для автосервиса нужно хранить много данных
В первом прототипе использовалась выборка по company_id.
Но при достижении более тысячи строк началась задержка
Далее было принято решение, на API реализовать перенаправление на другую БД при помощи админкой базы, записывались название базы для конкретно сервиса и оттуда уже брались данные, подход вроде не плох. Но всё же задержки есть. Может его знает как лучше построить архитектуру?
К примеру какая архитектура в CRM систем если у клиентов может быть тысячи товаров
Вряд оно храниться в одной таблице)
PS: Ещё момент в том что для каждого сервиса для связки структуры может быть до 30 таблиц
Не уверен что будет эффективнее делать выборку по айди чём получать Select * с нужной бд
Василий Банников, к сожалению Postgresql уже поздно брать )
Я пробовал данные по таблицам раскидывать а потом join брать но всё равно как по мне при масштабировании такой подход очень плохой.
Но при достижении более тысячи строк началась задержка
надо не гадать, а сделать профилирование, чтобы точно знать где узкое место. СУБД без проблем могут держать 1кк строк в таблице и не имееть проблем с производительность, а тут уже на тысячи затык.
MRXWOLF,
1 профилировать код, гугли конкретный инструмент под свой ЯП, фреймворк и т.п, может не база тормозит, а код, ну или проблема типа N+1 запросов
2. включить логирование тяжелый запросов "mysql slow query log", потом разбирай каждый проблемный запрос, может там индекса не хватает
Какие задержки при 1000 строк ?? - это явно ошибка проектирования БД.
Возьмите примеры для изучения - https://classmech.ru/pages/databases/goods/ .
Если хотите предметно, то приложите свою схему БД, с указанием связей и ключей (некоторые клиенты умеют сами её генерить, тот же DBeaver).
К примеру какая архитектура в CRM систем если у клиентов может быть тысячи товаров
Такая-же как на миллион товаров...
Однозначно, проблема в структуре таблиц базы, либо криво составлены запросы, без оглядки на план выполнения запроса.
Если сложность выполнения запроса вырастает не логарифмически, а гораздо линейнее, по сравнению с тем объемом данных, который он охватывает, значит что-то делаете не так.
MRXWOLF, MySQL отлично работает с каталогами товаров на 50-100 тысяч позиций. При том, что используется CMS Битрикс, которая зачастую строит неоптимальные запросы к БД.
Раз проект новый, то я бы рекомендовал брать Postgresql.
Вот кстати - зачем? Что постгрес даст в противовес мускулю конкретно в этой задаче, да и в целом - "в чем сила, брат"? Я работал как с постгресом, так и с мускулем, сказать что я как-то заметил разницу в производительности на больших объемах - ну, нет. Больше похоже на карго культ, навеяный пиаром... Или есть что-то "сокрытое от глаз"?
Автор может посмотреть в multi-tenant database. Кажется это реализовано уже для Oracle.
Для MySQL - похоже нет но есть всякие обходные пути типа как пишут вот на стековервлоу.