Ситуация:
1) есть база данных с несколькими рабочими таблицами
2) есть PHP-скрипт, который постоянно висит в памяти и кладёт данные в одну из рабочих таблиц
3) со временем эта таблица стала слишком большой, и её разделили на несколько новых небольших таблиц
4) количество этих новых таблиц постоянно растёт, через 3 месяца их будет 100 и количество будет продолжать расти
Из-за появления новых таблиц стало сложно визуально ориентироваться в списке таблиц (делать выборки и искать нужные таблицы). Думаем над тем, чтобы вынести их в отдельную базу - если их вынесем, в PHP-скрипте придётся постоянно поддерживать 2 соединения с базами.
Вопрос:
1) стоит ли делить таблицы по разным БД?
2) насколько критичным может быть наличие двух одновременных соединений с базами через скрипт, постоянно висящий в памяти?
3) если в разделении на базы нет ничего страшного, на сколько баз в перспективе можно будет делить данные (если новых таблиц станет over 9000)?
4) что почитать по подобной организации данных? :)
В MySQL (к другим СУБД это не относится) в запросе возможно указать базу данных. Более того, в одном запросе может быть обращение к таблицам разных БД. Разумеется, если все они работают на одном сервере.
Т.е. безо всяких дополнительных соединений можно сделать:
INSERT INTO base1.table1 (field2) SELECT base2.table2.field2 FROM base2.table2;
Таким образом, никаких проблем с разделением таблиц по нескольким базам нет. И несколько соединений тоже не требуется.
Если же базы будут работать на разных серверах, то да - понадобится по одному соединению на сервер. Что тоже проблем не вызовет.
Партицирование у нас закладывается вторым шагом - для архивирования записей старше 1 месяца в этих таблицах. А все over 9000 таблиц нужны нам в быстром доступе.
Другой вопрос, если одного _сервера_ вам становится мало. Тогда лучше сразу мигрируйте на nosql, если нет требований по консистентности и транзакционности или читайте про шардирование РСУБД.
@Melkij хороший вариант. Но, к сожалению, миграция в нашей ситуации не самый лёгкий процесс, а решение нужно в ближайшие пару недель. Пока таблиц не так много, всего 5, но через месяц их станет 50.
Сейчас нам надо сделать хоть какое-то решение, и уже потом будем анализировать и планировать миграцию (а заодно и целесообразность увеличения количества серверов).
1) по базам данных - запросто, если разделение обосновано. В частности, базы данных легко разнести на разные рейды.
По десяткам одинаковых таблиц - нет, не стоит.
2) не имеет значения. В случае шардирования (да и просто мастер-слейва) держать несколько открытых коннектов - нормально.
3) см.п.1
4) как уже упомянул - шардирование
@Melkij да, деление обоснованное (на мой взгляд) - отделить остальные таблицы от разросшейся старой, разделенной на несколько новых таблиц.
Значит, будем делить сначала по базам данных, включим партицирование для архивирования и потом смотреть и делать шаги в сторону шардинга и возможной миграции на другую СУБД. Верным путём пойдем?
@Remmi , верным или нет - невозможно сказать в отрыве от решаемой задачи. Хайлоад - это индивидуальные решения. Вам стоит пригласить архитектора, который разгребёт задачу на "что, зачем и когда".
Возможно, вам нужен только отдельный сторадж для активных данных (или, наоборот - для архивных). Возможно - вам действительно надо отказаться от РСУБД, возможно - пересмотреть схему обработки данных. Неизвестно, надо смотреть картину в общем и частном сразу.
