Каковы плюсы / минусы и лучшие практики использования единой базы данных?

Question

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

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

Любые мысли, советы или советы приветствуются. Спасибо

EDIT В ответ на комментарий по этому вопросу мы используем SQL Server 2005 и на самом деле говорим о переносе отдельных баз данных одного и того же экземпляра в одну базу данных. Движущей силой является полное отсутствие ссылочной целостности в базах данных, поскольку большинству наших приложений необходим доступ к общим данным, таким как запись сотрудника или информация о филиале.

UPDATE Несколько человек попросили меня обновить этот вопрос с результатами нашей встречи, так что вот оно. Мы обсуждали плюсы и минусы этого (я даже показал им этот вопрос с помощью проектора), и к тому времени, когда мы закончили, мы в значительной степени рассмотрели все плюсы и минусы. Приблизительно половина из нас думала, что мы могли бы сделать это с правильными ресурсами и обязательством, и приблизительно половина думала, что мы не могли сделать это (или что это не будет работать хорошо). Мы решили использовать некоторое время вместе с Microsoft, чтобы узнать их мнение и рекомендации для конкретной платформы. Я обязательно обновлю этот вопрос и мой блог после того, как мы поговорим с ними. Спасибо за помощь и полезные ответы.

Answer 1

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

Правильное использование файловых групп устранит большинство недостатков, процитированных в предыдущих ответах: они могут распределять ввод-вывод, они могут обезопасить ваши планы обслуживания и стратегию резервного копирования / восстановления, они предлагают доступность, переводя в автономный режим только поврежденная часть БД в случае сбоя. Поэтому я бы сказал, что хотя эти «минусы» и являются законными проблемами, их можно смягчить с помощью правильной стратегии развертывания. Правда, эти действия по смягчению последствий требуют настоящего, опытного, dba у руля, поскольку они выйдут за пределы зоны комфорта разработчика, которому по необходимости понадобился dba.

Некоторые плюсы, о которых я могу вспомнить быстро:

1. Последовательность. Вы можете сделать резервную копию-восстановление, чтобы все данные были согласованы. Отдельные базы данных не допускают этого, потому что вы не можете координировать согласованный набор резервных копий, пока вы не переведите их все в автономный режим или не выполните их во время резервного копирования.
2. Низкая дешевая высокая доступность: вы можете развернуть зеркальное отображение базы данных для аварийного восстановления и высокой доступности. Несколько баз данных имеют проблемы, потому что невозможно координировать одновременное переключение при сбое, и приложения сталкиваются с дилеммой поиска каждой текущей базы данных.
3. Security. В то время как в большинстве других публикаций одну базу данных труднее защитить, я бы сказал, что проще . Несколько баз данных сложно защитить должным образом, просто потому, что все делают один вход в систему и добавляют его в эту группу базы данных db_owner. Наличие одной базы данных усложнит ситуацию (если вы в конечном итоге не сделаете все dbo, что очень плохо), но как только вы начнете делать правильные вещи (детальный доступ), тогда один db не сложнее, чем несколько dbs, на самом деле проще, потому что у вас не будет копировать / поддерживать некоторые общие группы / права для нескольких баз данных.
4. Контроль. Будет проще навязывать определенные политики и передовые практики одному БД, чем нескольким (нет доступа к данным для разработчиков, доступ к данным приложения только через права на выполнение в схеме для обеспечения доступа к процедурам и т. Д.).

Есть также некоторые минусы, которые я не видел в других сообщениях:

1. Это будет намного сложнее, чем вы думаете сейчас
2. Увеличение связи между ранее разделенными приложениями наложит ограничения на разработку: вы не можете просто изменить свою схему, вам придется согласовать ее с остальными приложениями (вы можете утверждать, что это также имело место ранее, но было очищено под ковром имея отдельные дбс, и ты прав)
3. Записи журнала, которые теперь распределены по нескольким журналам базы данных, будут объединены в один файл журнала. Если ваши записи значительны, это может оказаться серьезным узким местом и вынудить вас купить дорогие быстрые диски для нового консолидированного файла журнала. В общем, это может быть сделано путем создания лог-диска с разделенным массивом на столько полос, сколько необходимо, чтобы сделать его достаточно быстрым (обычно raid 10).
4. GAM / SGAM / PFS распределения также будут консолидированы, но опять-таки это будет облегчено путем правильного использования групп файлов.

Answer 2

Плюсы:

• Вам нужно запомнить только одну строку подключения
• Когда пользователи сообщают, что доступ медленный, вы знаете, какая БД вызывает проблему

Минусы:

• Резервное копирование The One DB займет много времени и будет постепенно увеличиваться со временем.
• Восстановление данных из резервной копии будет становиться все труднее.
• Настройка производительности (SQL Profiler, оценка плана выполнения) для функции для одного приложения замедлит работу каждого приложения.
• Ограничение доступа к данным одного приложения является обременительным, если это вообще возможно, что, вероятно, будет означать на практике, что всем разработчикам и администраторам баз данных будут предоставлены ключи для ВСЕГО королевства.
• Новые разработчики / администраторы баз данных имеют гораздо большую кривую обучения, поскольку им необходимо ориентироваться в большой и в основном бесполезной (для них) структуре базы данных, что означает более высокие затраты на обучение / наращивание.
• Когда база данных One отключается, все в вашей организации играют в пасьянс до тех пор, пока она не будет восстановлена.
• Создание тестовых экземпляров для разработки приложений означает копирование всей вашей базы данных

Answer 3

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

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

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

Вот что на самом деле нужно сделать вашей компании: иметь единую КОНЦЕПТУАЛЬНУЮ базу данных, которая содержит все «данные предприятия» и определена таким образом, что обеспечивается соблюдение как ссылочной целостности, так и целостности сущностей. Пересмотрите существующие схемы, чтобы они соответствовали базе данных CONCEPTUAL, за исключением данных, которые являются чисто локальными по отношению к этой схеме и не документированы в единой концептуальной базе данных. Используйте ограничения везде, где это необходимо, чтобы гарантировать, что данные, охватываемые этими схемами, не потеряют целостность.

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

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

Документируйте концептуальную базу данных из gazoo. Не просто соглашайтесь на определения ФОРМЫ данных. Настаивайте также на определениях семантики данных.

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

Это будет непросто.

Answer 4

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

Некоторые другие общие минусы:

• В будущем гораздо сложнее переместить приложение на другое место / сервер.
• Возможные проблемы с блокировкой, если какие-либо приложения используют базу данных tempdb.
• Возможно несвязанное снижение производительности на одном приложении, когда другое приложение используется.
• Гораздо сложнее реализовать модель безопасности на уровне приложений, если все таблицы находятся в одной базе данных.

Answer 5

Существует много других способов решения проблемы ссылочной целостности (RI). Я не так знаком с SQL Server, как другие БД. В Informix вы можете использовать синонимы для указания на объекты в других БД и использовать их для вашего RI. В Oracle вы можете сделать ссылки на БД на одну или несколько БД, чтобы выполнить то же самое. Эти подходы имеют проблему, заключающуюся в том, что если какой-либо из БД не работает, RI потерпит неудачу, вызывая проблемы в зависимых БД. Выбор будет работать, но вставки не удастся. Консолидация может быть хорошей идеей, в зависимости от размера схемы и других проблем с масштабируемостью. SQL Server имеет серьезные проблемы с масштабируемостью. Другие платформы БД допускают горизонтальное масштабирование либо с использованием подхода с общим доступом (Oracle RAC, последняя версия Informix), либо с использованием подхода с разделением без совместного использования (DB2 DPF, Informix XPS, Netezza, Teradata)

Мне и другим здесь интересно узнать результаты вашей встречи.

Answer 6

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

На том же сервере вы можете выгружать или извлекать данные из официального репозитория основных данных и вставлять любые новые строки / обновлять любые измененные строки. Вы даже можете сделать это с помощью триггера в базе данных master (хотя я не рекомендую это делать).

Если это разные экземпляры или серверы, вы можете использовать связанные серверы или службы SSIS.

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

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

Answer 7

Ах, старый шаблон дизайна EggsInOneBasket. Это не любимый.

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

Answer 8

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

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

Answer 9

Я вижу, что это страшно, но, учитывая количество предприятий, которые используют Oracle EBS или SAP, или другие системы, которые, по сути, являются той же самой конфигурацией, я не вижу, что это плохая вещь и торговля ;. Это большой шаг, и будет 10000 * трудно получить правильное решение, но это может действительно улучшить интеграцию в масштабах всего предприятия.

Answer 10

Плюсы:

• Удобство хранения всего в одном месте
• Меньше думая о хорошем дизайне базы данных

Минусы:

• Даже несвязанные вещи находятся в одном месте
• Меньше размышлений о хорошем дизайне базы данных, приводящем к плохо нормализованным данным

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