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

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

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

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

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

• it'll allow you to put one DB on one server, and the other DB on a second server
  • and you can think about scaling a bit more, later : more servers for the "core" data, and still only one for the "technical" data -- or the opposite
• если «технические» данные не так важны, вы можете (проще) иметь два разных процесса/политики резервного копирования
• having two distinct databases, and two distinct servers, also means you can have heavy calculations on the technical data, without impacting the DB server that hosts the "core" data -- and those calculations can be useful, on logs, or stuff like that.
  • as a sidenote : if you don't need that kind of "reporting" calculations, maybe storing those data to a DB is not useful, and files would do perfectly ?

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

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

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

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

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

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

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

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

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

Для mysql нет никакой разницы, используете ли вы отдельные «базы данных», это просто каталоги.

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

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

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

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

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

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

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

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

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

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