Базы данных MySQL. Сколько за веб-приложение?

Fisrt, я должен сказать, думаю, что хранить все журналы событий, журналы ошибок в db - очень плохая идея, вместо этого вы можете захотеть сохранить их в файловой системе.

Вам понадобятся журналы ошибок или журналы событий, если что-то в вашем веб-приложении станет неожиданным. Затем вы загружаете файл и изучаете его, вот и все. Нет необходимости хранить его на db. Это замедлит ваш db и ваше веб-приложение.

В качестве ответа на ваш вопрос, если вы действительно хотите это сделать, вы должны их разделить, и вы должны найти способ, чтобы ваша страница работала, даже если вы загрузили и загрузили базы данных og и журнала ошибок.

Переход с двумя отдельными базами данных (один для ваших "основных" данных приложения и другой для "технических" данных) может быть не плохой идеей, по крайней мере, если вы ожидаете, что ваше приложение будет иметь много пользователей:

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

Возможно, открытие двух соединений означает немного больше времени - но эта разница, вероятно, весьма незначительна, не так ли?

Я несколько раз работал над приложениями, использующими две базы данных:

• Одна база данных "master" / "write", которая будет использоваться только для записи
• и одна "подчиненная" база данных (репликация первой, на несколько подчиненных серверов), которая будет использоваться для чтения

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

Использовать объединение пула в любом случае. Поэтому время для подключения не является проблемой. Но если у вас есть 2 соединения, обработка транзакций усложняется. С другой стороны, иногда бывает полезно иметь 2 соединения: если что-то пойдет не так в бизнес-транзакции, вы можете отменить транзакцию и по-прежнему регистрировать сбой в транзакции администратора. Но я все равно буду придерживаться одной базы данных.

Не имеет никакого значения для mysql, независимо от того, используете ли вы отдельные "базы данных", это просто каталоги.

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

Тем не менее, размещение их на отдельных серверах может быть хорошей идеей, поскольку вы, вероятно, не хотите, чтобы ваши основные критические (данные пользователя, например), смешанные с вашими большими объемами, несущественными данными. Это особенно верно для старых данных аудита, журналов отладки и т.д.

Также кратковременные данные, такие как результаты поиска, сеансы и т.д., могут быть размещены на другом сервере - по-видимому, он не имеет требования к высокой доступности [1].

Сказав это, если вам не нужно это делать, выгрузите все это на одном сервере, где проще управлять (резервное копирование, обеспечить высокую доступность, управлять безопасностью и т.д.).

Как правило, невозможно сделать согласованный снимок данных на сервере > 1. Это хорошая причина иметь только один (или тот, который вам нужен для целей резервного копирования)

[1] Данные, а не база данных.

Я не вижу причин для двух баз данных. Было бы вполне приемлемо иметь таблицы, посвященные "техническим" и "деловым" данным, но логического разделения должно быть достаточно.

Физическое разделение мне не кажется необходимым, если вы не имеете в виду схему звезд приложения и хранилища данных. В этом случае это либо обновления в реальном времени, либо, более типично, ночной пакет ETL.

В MySQL InnoDB имеет возможность хранить все таблицы определенной базы данных в одном файле или иметь один файл в таблице.

В любом случае, если один файл на таблицу несколько рекомендован, и если вы это сделаете, он имеет значение на уровне хранилища баз данных, если у вас есть одна база данных или несколько.

При объединении пулов одна или несколько баз данных, вероятно, тоже не будут иметь значения.

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

Я бы использовал только один файл данных - в основном по причине, по которой вы поставляете: вам нужно только одно соединение для доступа к журналам и сохраненным данным пользователя.

В зависимости от вашего языка программирования некоторые структуры (J2EE в качестве примера) обеспечивают объединение пулов. С двумя базами данных вам понадобятся два пула. В PHP, с другой стороны, производительность появляется в перспективе при настройке соединения (или двух).