проде при больших нагрузках?
Вопрос абстрактный, но хочу понять, какой порядок хотя бы.
10-ки или сотни тысяч могут быть?
(Вопрос не обязательно про MemSQL)
Что за запросы? Что за большие нагрузки? Какое железо? Когда ответите на все эти вопросы, можете провести эксперимент)
какой эксперимент?
Эксперимент "А сколько примерно баз данных на одном инстансе БД в проде при больших нагрузках?"
Под большими нагрузками имел в виду сценарий, когда на проде делают sharding для БД и репликации - интересен был случай распределённой SQL БД - сколько на таких обычно баз данных создают. Но поскольку такой вопрос сильно усложнил бы всё, то задал вопрос попроще.
А что это значит в применении к mySQL? Где нет баз данных?
почему нет баз данных? information_schema по умолчанию, а дальше create database…, show databases…
хочу понять, сколько в макс нагрузках на практике может быть баз данных - пусть будет MySQL или любая другая RDBMS.
Баз данных в mySQL нет, она всегда одна единственная
ну схемы, ок. Сути вопроса это не меняет, если заменить базы данных на схемы.
Меняет кардинально.
В каждом инстансе mySQL должна быть только одна пользовательская БД. На одной машине должен быть только один инстанс mySQL Иначе ты запутаешься мониторить нагрузку и работу СУБД
а по каждой схеме нельзя мониторить?
Ну выведи innodb status по одной схеме, есть она там?
хм, посмотрю. спасибо
Ну я намекаю что нет там схем. Память у mySQL одна. Кэш один, ничто не конфигурируется посхемно. Так что...
Интересно, спасибо. Буду знать. А если брать другие БД - например, Oracle, которые на большие объёмы данных, то там всё иначе?
В оракле так же. В SQL server/Sybase - наоборот
Есть СУБД работающие с одной БД только, и есть способные работать с разными. Хотя, даже если СУБД может работать с разными БД, всегда остаются ресурсы, которые конфигурируются на уровне инстанса СУБД, и общие для всех БД. И всё сказанное отчасти справедливо и для них. Так что вообще лучше одна СУБД - одно приложение, одна БД
абстрактные вопросы требуют абстрактных ответов. вопрос сложный и ответ на него зависит не только от бд, но и от диска, файловой системы и т.д. в целом mysql почти все равно на количество таблиц/бд. достаточно будет поднять параметры касающиеся кеширования метаданных и все будет более-менее ок. проблемы придут откуда не ждали. мониторинг станет медленее и будет давать нагрузку при чтении метаданных из information_schema и это уже будет напрямую влиять на производительность mysql и делать это будет часто. потом накладные расходы со стороны FS: не любят многие когда много файлов лежит в одном каталоге и это тоже скажется на производительности. медленнные рестарты и т.д.. вроде как это не проблема из-за мускула, а проблема сторонних систем, но работать медленно будет именно он. немного личного опыта. 1) лучше иметь 100 схем по 100 таблиц, чем одну схему и 10К таблиц; 2) ext4 без каких-либо проблем работает с 1К таблиц в одной схеме (больше у меня не было); 3) был у меня сервер с ~13К таблицами в ~300 схемах и небольшой нагрузке (6-7K qps) и все работало как часы. 4) согласно доке макс количество таблиц 5 billions - вам хватит 5) все остальное за рамками моего опыта. если у вас немного опыта, то я бы не рекомендовал пихать вам больше пары-тройки тысяч таблиц в базу. касательно советов, которые вам давали: одна база - одна схема или один сервер - один инстанс мускула: это все глупости, можете это игнорировать
Спасибо за обширный ответ, понял.
Обсуждают сегодня