Я создаю веб-приложение. Это приложение будет использовать MySQL для хранения всей информации, связанной с каждым пользователем. Тем не менее, он также будет использовать MySQL для хранения файлов типа sys admin, таких как журналы ошибок, журналы событий, различные временные токены и т.д. Этот второй набор информации, вероятно, будет больше, чем первый набор, и это не так важно. Если бы я потерял все свои журналы ошибок, сайт продолжил бы без икоты.
Я разрывается на то, нужно ли иметь несколько баз данных для этих разных типов информации или вносить все это в одну базу данных в несколько таблиц.
Поводом держать все в одном, является то, что мне нужно открыть только одно соединение. Я заметил измеримый штраф времени для открытия соединения, особенно с использованием удаленных серверов mysql.
Что вы, ребята, делаете?
Fisrt, я должен сказать, думаю, что хранить все журналы событий, журналы ошибок в db - очень плохая идея, вместо этого вы можете захотеть сохранить их в файловой системе.
Вам понадобятся журналы ошибок или журналы событий, если что-то в вашем веб-приложении станет неожиданным. Затем вы загружаете файл и изучаете его, вот и все. Нет необходимости хранить его на db. Это замедлит ваш db и ваше веб-приложение.
В качестве ответа на ваш вопрос, если вы действительно хотите это сделать, вы должны их разделить, и вы должны найти способ, чтобы ваша страница работала, даже если вы загрузили и загрузили базы данных og и журнала ошибок.
Переход с двумя отдельными базами данных (один для ваших "основных" данных приложения и другой для "технических" данных) может быть не плохой идеей, по крайней мере, если вы ожидаете, что ваше приложение будет иметь много пользователей:
Возможно, открытие двух соединений означает немного больше времени - но эта разница, вероятно, весьма незначительна, не так ли?
Я несколько раз работал над приложениями, использующими две базы данных:
Таким образом, да, мы иногда открываем два подключения - один только один сервер не мог бы обрабатывать нагрузку...
Использовать объединение пула в любом случае. Поэтому время для подключения не является проблемой. Но если у вас есть 2 соединения, обработка транзакций усложняется. С другой стороны, иногда бывает полезно иметь 2 соединения: если что-то пойдет не так в бизнес-транзакции, вы можете отменить транзакцию и по-прежнему регистрировать сбой в транзакции администратора. Но я все равно буду придерживаться одной базы данных.
Не имеет никакого значения для mysql, независимо от того, используете ли вы отдельные "базы данных", это просто каталоги.
Он может облегчить настройку полномочий, это законная причина для этого. Помимо этого, это точно так же, как хранение таблиц в одном и том же дне (за исключением того, что вы можете иметь несколько таблиц с тем же именем... но, пожалуйста, не делайте этого)
Тем не менее, размещение их на отдельных серверах может быть хорошей идеей, поскольку вы, вероятно, не хотите, чтобы ваши основные критические (данные пользователя, например), смешанные с вашими большими объемами, несущественными данными. Это особенно верно для старых данных аудита, журналов отладки и т.д.Также кратковременные данные, такие как результаты поиска, сеансы и т.д., могут быть размещены на другом сервере - по-видимому, он не имеет требования к высокой доступности [1].
Сказав это, если вам не нужно это делать, выгрузите все это на одном сервере, где проще управлять (резервное копирование, обеспечить высокую доступность, управлять безопасностью и т.д.).
Как правило, невозможно сделать согласованный снимок данных на сервере > 1. Это хорошая причина иметь только один (или тот, который вам нужен для целей резервного копирования)
[1] Данные, а не база данных.
Я не вижу причин для двух баз данных. Было бы вполне приемлемо иметь таблицы, посвященные "техническим" и "деловым" данным, но логического разделения должно быть достаточно.
Физическое разделение мне не кажется необходимым, если вы не имеете в виду схему звезд приложения и хранилища данных. В этом случае это либо обновления в реальном времени, либо, более типично, ночной пакет ETL.
В MySQL InnoDB имеет возможность хранить все таблицы определенной базы данных в одном файле или иметь один файл в таблице.
В любом случае, если один файл на таблицу несколько рекомендован, и если вы это сделаете, он имеет значение на уровне хранилища баз данных, если у вас есть одна база данных или несколько.
При объединении пулов одна или несколько баз данных, вероятно, тоже не будут иметь значения.
Итак, на мой взгляд, вопрос заключается в том, если вы когда-нибудь подумаете о разделении "другой половины" базы данных на отдельный сервер - с отдельным сервером, имеющим, возможно, совсем другую аппаратную конфигурацию, например без RAID. Если да, рассмотрите возможность использования отдельных баз данных. Если нет, используйте одну базу данных.
Я бы использовал только один файл данных - в основном по причине, по которой вы поставляете: вам нужно только одно соединение для доступа к журналам и сохраненным данным пользователя.
В зависимости от вашего языка программирования некоторые структуры (J2EE в качестве примера) обеспечивают объединение пулов. С двумя базами данных вам понадобятся два пула. В PHP, с другой стороны, производительность появляется в перспективе при настройке соединения (или двух).