Почему вы используете две (или более) базы данных вместо одной?

Question

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

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

Так зачем приложению PHP или Ruby подключаться к нескольким базам данных? Или, скорее, зачем вам распределять ваши данные по нескольким базам данных?

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

Answer 1

Вы говорите о разных физических серверах баз данных или разных базах в смысле "схемы"?

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

Answer 2

Слишком часто бывает так, что некоторые данные, которые вам нужны, хранятся в неправильной базе данных.Иногда это кадровые записи в базе данных PeopleSoft (Oracle).Может быть, это данные Enterprise CRM в Informix.Или какая-то ведомственная база данных хранится в MS SQL Server.Что бы это ни было, оно находится в другой базе данных, но вам все еще нужен доступ (надеюсь, только для чтения).

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

Answer 3

Простой ответ - «масштабируемость».

Готовность к репликации и кластеризации в ряде продуктов баз данных заставляет несколько баз данных использовать определенное «это должно быть возможно». Любой приличный ORM должен знать, как подключаться к нескольким базам данных при необходимости.

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

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

Конечно, очевидная потребность в простом исполнении. Я наблюдал за веб-приложением и базой данных, которые выросли из комфортного выживания на одной базе данных MySQL на 32-разрядной двухъядерной машине с 3Gb до , требующей двух 8-ядерных 64-разрядных серверов с 8Gb. Достигнув этой стадии, он использовал обработчик базы данных, направляющий трафик на оба сервера. У нас было окно около 50 минут в день, где он мог выжить только на одной базе данных.

Answer 4

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

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

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

Answer 5

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

Answer 6

У меня есть сайт, который соединяется с двумя базами данных.Один управляет содержимым веб-сайта (CMS DB), а другой управляет веб-приложением, которое запускается на сайте (большие объемы данных, отличных от CMS). На самом деле последний использует репликацию.

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

Answer 7

Другие причины иметь несколько баз данных.У нас есть одно приложение, доступное каждому.У нас также есть клиентская база данных, которая сильно отличается от клиента к клиенту.Легче поддерживать приложение, которое используют все клиенты (и которое поддерживается другой командой), если данные client_specific выделены в их собственные базы данных.Также легче переместить клиента на новый сервер, когда он становится крупным корпоративным клиентом, а не меньшим клиентом, работающим на сервере со многими другими клиентами.

Кроме того, существуют типы данных, которые являются транзакционными и должны находиться в базах данных, для которых установлен режим полного восстановления с полным журналом транзакций.Другие данные заполняются только из импорта и не требуют регистрации транзакций, что может замедлить работу системы, так как объем журнала вырос достаточно для обработки импорта из 10 000 000 записей.Они часто разделяются на отдельную базу данных, поэтому они могут находиться в простом режиме восстановления, поскольку нет необходимости восстанавливать данные из журнала транзакций, если есть проблема, ее можно легко восстановить путем повторного запуска импорта.

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

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

У нас есть несколько сотен баз данных на многих разных серверах.

Answer 8

Для дополнительной безопасности я всегда создаю две учетные записи для каждой базы данных: учетную запись только для чтения (хорошо для SELECT) и учетную запись для чтения и записи (для SELECT, UPDATE, INSERT, DELETE и всего, что может понадобиться). На некоторых страницах мне может понадобиться использовать обе учетные записи, поэтому я буду использовать два подключения только для одной базы данных.