Имеет ли смысл создавать несколько баз или лучше создать несколько таблиц?

Question

[Евгений Иванов]

Выделенный сервер. База/базы MySQL. На сервере работают скрипты (cron). На сервер заходят пользователи (вызывают скрипты). Возникают самые разные ситуации.

Например: долгое выполнение определенного MySQL запроса (например - иногда бывает ).
Относительно большой объем таблицы - 8 ГБ (дальше расти не будет).
Относительно частые запросы cron к БД - раз в 4 секунды.

Например: пользователь вызвал скрипт, который долго выполняет MySQL запрос.
В то же время cron тоже выполняет MySQL запрос. В то же время происходит что то ещё.

Имеет ли смысл создавать несколько баз?
Например отдельную базу под таблицы > 8 ГБ. Отдельную базу под таблицы пользователя. Влияет ли это на стабильность и производительность?
Или в этом нет никакого смысла и несколько таблиц в одной БД будут работать абсолютно также, как и несколько баз (со своими таблицами)?

Comments

[Vitsliputsli]

Имеет ли смысл создавать несколько баз?

нет, не имеет смысла.

Например отдельную базу под таблицы > 8 ГБ. Отдельную базу под таблицы пользователя. Влияет ли это на стабильность и производительность?

Не влияет ни на стабильность, ни на производительность.

Или в этом нет никакого смысла и несколько таблиц в одной БД будут работать абсолютно также, как и несколько баз (со своими таблицами)?

Да, с точки зрения скорости, стабильности и т.д., все будет работать одинаково в обоих случаях.

Answer 1

[cogden]

Вы пытаетесь лечить симптомы, вместо постановки диагноза и лечения болезни.
П – профилирование. Сначала выясняется причина тормозов, затем думается как исправлять. А не наоборот.

8 гигов данных и пара десятков запросов в минуту – это ничего для любой современной субд, если она нормально спроектирована.

Comments

[Евгений Иванов]

Простите, наболело

Например: долгое выполнение определенного MySQL запроса (например - иногда бывает ).

Вот дважды написал - например... Думал поймут.
Например, корабль может затонуть и когда это случится сколько спасательных лодок надо?
10 больших или 30 маленьких?
- Сначала выясняется причина почему корабль может затонуть... 0_0
Да их миллионы... Айсберг, риф, взрыв в машинном отделении, саботаж - в жизни всякое бывает.

[cogden]

Евгений Иванов, долгое выполнение запроса не должно приводить к стопору сервера. Если это происходит, то нужно определять причину стопора (это может быть как и неоптимальный запрос, приводящий к локам, так и плохонькая конфигурация самого сервера).
Вместо того чтоб задуматься над этим, вы предпочитаете переколбасить всё и включить обиженку.

[Александр]

Вот дважды написал - например... Думал поймут.

Евгений Иванов, если Вы не можете повлиять на поведение клиентов -- это должно быть отражено в условии задачи.

Сначала выясняется причина почему корабль может затонуть... 0_0

Именно так, еще на этапе проектирования корабля учитываются наиболее возможные риски. Применительно к базе: 1)кол-во одновременных подключений; 2)необходимые вычислительные ресурсы для п.1; 3) приемлемое время отклика базы, при превышении которого база считается деградирующей по производительности.

Да их миллионы...

Чаще всего -- кораблик бумажный и шлюпки не спасут. А даже усугубят ситуацию.

10 больших или 30 маленьких?

Пока не получите ожидаемого запаса. Можно как 1 большую (вертикальный рост мощности сервера: больше озу, быстрее/большее кол-во ядер), можно так же кучку маленьких (несколько машин, объединенных в кластер (если поддерживает клиент), либо мимикрирование кластера под единую машину).
От перетасовки табличек между базами внутри одной машины Вы не получите ничего, кроме геммороя.

[Vitsliputsli]

Евгений Иванов, вы правы, для страховки от случая, что корабль-СУБД затонет по неизвестной причине, аналитику не проводят. На этот случай создают бекапы, и ведут журналы, чтобы возможно было восстановить максимально последнее состояние баз данных. Но в вашем случае, речь идет скорее о падении скорости корабля, поэтому тут нужны механики, а не спасательные шлюпки.

Answer 2

[ThunderCat]

Например: долгое выполнение определенного MySQL запроса (например - иногда бывает ).

log_slow_queries   = /path/to/log/mysql-slow.log
long_query_time         = 1 #время в секундах

после того как вы увидите что у вас реально что-то тормозит, можно что-то реально поправлять. Например прогнать медленные запросы через explain.

Относительно частые запросы cron к БД - раз в 4 секунды.

м? что? Относительно частые запросы - 50 в секунду и выше. Конечно на Васином бложике на хостинге за 3 бакса в год это может считаться частыми запросами, но, судя по таблицам по 8Г, у вас проект немножко серьезнее...

Например: пользователь вызвал скрипт, который долго выполняет MySQL запрос.
В то же время cron тоже выполняет MySQL запрос. В то же время происходит что то ещё.

Космические корабли бороздят просторы Большого театра?
Если скрипт не блокирующий(не запись массива строк) то эти процессы не будут друг другу мешать. И даже в таком случае все настраивается - смотрите разницу в типах таблиц и приоритеты на запись/чтение.

Имеет ли смысл создавать несколько баз?

нет.