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

Question

Я создаю веб-приложение. Это приложение будет использовать MySQL для хранения всей информации, связанной с каждым пользователем. Однако он также будет использовать MySQL для хранения вещей типа sys admin, таких как журналы ошибок, журналы событий, различные временные токены и т. Д. Этот второй набор информации, вероятно, будет больше, чем первый набор, и это не так важно. Если я потеряю все свои журналы ошибок, сайт будет работать без сбоев.

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

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

Что вы, ребята, делаете?

Answer 1

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

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

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

Answer 2

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

Answer 3

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

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

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

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

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

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

Answer 4

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

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

Answer 5

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

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

Answer 6

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

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

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

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

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

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

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

Answer 7

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

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

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

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