Есть ли преимущества в разделении баз данных приложений по шаблонам использования?

Question

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

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

Между этими двумя группами таблиц не должно быть никаких RI.

У меня такой вопрос: имеет ли смысл создавать две отдельные базы данных для этих очень разных типов данных? Каковы преимущества и недостатки обоих подходов?

Если это имеет значение, он встроен в .NET с использованием серверной части SQL Server 2008.

Answer 1

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

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

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

Answer 2

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

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

Answer 3

Исходя из ваших описаний, создается впечатление, что у вас есть две разные службы (с точки зрения сервисно-ориентированного программного обеспечения). Одним из основных принципов SOA является то, что ваши службы должны быть автономными, но автономность очень трудно достичь, поэтому Пока у вас есть общая база данных за ними. Вы несколько раз упоминали в своем описании, что данные очень разные и что приложения довольно независимы друг от друга. Это хороший признак того, что у вас есть четкая граница разделения между тем, что можно рассматривать как две разные службы, каждая из которых должна иметь собственную базу данных для улучшения автономности. У вас может быть сервис с высоким уровнем записи / низким уровнем чтения, потребляющий сервис с высоким уровнем чтения / низким уровнем записи, или вы можете иметь сервис с высоким уровнем чтения периодически публиковать изменения для любых подписчиков (то есть сервис с высоким уровнем записи), каждый из который будет кэшировать данные, которые им нужны локально, в своей собственной базе данных.

Очень хорошее описание этого типа сервис-ориентированного дизайна можно найти в этом видео от Udi Dahan: http://www.vimeo.com/5022174. Это может помочь вам решить вашу проблему.