Профессионалы/Недостатки использования нескольких баз данных по сравнению с использованием единой базы данных

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

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

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

Что такое хорошие профессионалы/недостатки для использования сингла или нескольких баз данных?

[сводка до сих пор]

Аргументы против нескольких баз данных:

  • Потеря целостности данных (не может использовать внешние ключи по базам данных),

  • Потеря целостности восстановления

  • Получение сложности (пользователи/роли дб)

  • Маленький сервер/база данных разногласий понизится

Решения:

  • Используйте схемы для разделения доменов.

  • POC: Используйте фиктивные данные для подтверждения точки зрения в планах выполнения на 7/1 дб

14
15.01.2020, 21:15
5 ответов

Ни одна из производительности, устойчивости, оптимизация не верна. У кого-либо есть твердый аргумент или ссылочная статья, почему они были бы верны?

Ресурсы не выделяются базе данных: экземпляр SQL Server балансирует ресурсы, таким образом, это не имеет никакого значения

Вы проигрываете:

  • целостность данных
  • целостность восстановления (данными в DB7 будет позже затем DB1),

Вы получаете сложность:

  • безопасность (пользователи, роли и т.д.) должны быть во всех базах данных
  • у Вас будут некоторые данные, которые не вписываются в 1 базу данных приятно

Опции:

  • разделение базы данных на отдельные диски может быть сделано с группами файлов
  • используйте схемы для логичного разделения данных (на основе другого ответа)
16
24.01.2020, 22:54

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

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

6
24.01.2020, 22:54
  • 1
    8 фиктивных дб, клиент еще не объяснил детали о 'производительности, устойчивости и оптимизации'. Мне также любопытно к этому ответу. Будет говорить его позже на этой неделе. –   12.07.2011, 15:27

При после разделении данных логическим доменом, Вы могли бы всегда смотреть на использование схем в SQL2008 (уходящий от значения по умолчанию dbo.), но даже который является болезненным и может вызвать проблемы с ИЛИ/Г-ЖА которые не ожидают нестандартную схему.

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

Как тест, создайте 7 фиктивных баз данных. Создайте запрос, который требует данных одновременно из всех 7 или по крайней мере большого количества их.

Затем сравните планы выполнения! Я думаю, что Вы выиграете свое дело тут же.

5
24.01.2020, 22:54
  • 1
    Моя идея состоит в том, чтобы (действительно) использовать схему для логических доменов. Также будет использовать Модели данных Объекта. Как альтернатива я попробую :) –   12.07.2011, 12:47

Мысленный эксперимент: Вместо того, чтобы делить Вашу базу данных на семь частей, разделение это вместо этого в 7 000 частей. Какова вероятность, что отказ оборудования собирается повлиять на Ваше приложение? Если существует шанс на 0,1%, что какой-либо конкретный сервер может перестать работать в конкретный день, Ваши возможности лучше или хуже, что Вы собираетесь быть повлиявшими отказом оборудования при увеличении числа машин, от которых Вы зависите?

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

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

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

4
24.01.2020, 22:54

Я соглашаюсь с одним DB и файлом использования и опциями схемы вместо этого.

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

Среда приложения (dev, тест, напоминание) конфигурация, такая как FTP-серверы, экспортирует пути к файлам, и т.д...., Материал, который Вы хотите сохранить на сервер и не быть перезаписанными на восстановлении.

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

Но это поддержка и не проблемы производительности.

2
24.01.2020, 22:54

Теги

Похожие вопросы