Несколько приложений против одной архитектуры базы данных

Question

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

• Дублируйте базу данных и используйте репликацию и т. Д. Для их синхронизации
• Создайте новое приложение между базой данных и 10-15 приложениями сверху.
• Другое

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

Answer 1

Я думаю, что модным ответом на это является «Сервис-ориентированная архитектура» - это действительно вариант 2.

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

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

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

Answer 2

Анализ предоставляемых вами вариантов:

Дублируйте базу данных и используйте репликацию и т. Д. Для их синхронизации

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

Создайте новое приложение между базой данных и10-15 приложений сверху.

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

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

Answer 3

Я не понимаю, почему 10-15 приложений должны совместно использовать базу данных?Действительно ли все приложения должны использовать все таблицы?

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

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

Answer 4

Не упомянутая опция - иметь часть логики в хранимых процедурах / триггерах и т. Д. ... Не очень хорошая идея, но, тем не менее, идея.

Я бы сказал, что ваш второй вариант - лучшая ставка здесь. Если вы работаете на платформе .NET, WCF - это действительно простой и эффективный способ.