Как реализовать мультитенантную стратегию «Общая база данных, отдельная схема» - PullRequest
Новая
       26

Как реализовать мультитенантную стратегию «Общая база данных, отдельная схема»

2 голосов
/ 29 июля 2010

Мне нужно включить мультитенантное веб-приложение с использованием подхода с использованием отдельной схемы общей базы данных. Приложение построено с использованием Java / J2EE и Oracle 10g.

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

Каков наилучший подход к реализации для достижения этой цели?

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

1 Ответ

0 голосов
/ 26 мая 2015

На высоком уровне, вот несколько вещей, которые следует учитывать:

  • Вы, вероятно, хотите скрыть соображения арендатора от повседневной разработки. Таким образом, вы, вероятно, захотите как можно больше спрятать его в своей инфраструктуре и отделить от своей бизнес-логики. Вы не хотите всегда проверять, в каком контексте вашего арендатора вы находитесь ... вы просто хотите быть в этом контексте.
  • Если вы используете шаблон единицы работы, вам нужно убедиться, что любая единица работы (кроме той, которая работает в чисто инфраструктурном контексте, а не в бизнес-контексте) выполняется в контексте ровно одного арендатора. , Если вы не используете шаблон работы единицы ... может быть, вам следует. Не уверен, как еще вы будете следовать советам в пункте выше (хотя, возможно, вы сможете найти способ).
  • Возможно, вы хотите поместить идентификатор клиента в заголовок каждого сообщения или HTTP-запроса. Вероятно, лучше держать это в стороне от принципа защиты от бизнес-логики. Вы можете скрыть это за кулисами и убедиться, что за кулисами он получает любые исходящие сообщения / запросы.
  • Я не знаком с Oracle, но в SQL Server, и я верю, что в Postgres вы можете использовать олицетворение как способ переключения арендаторов. То есть, вместо параметризации схемы в каждой команде SQL и запросе, вы можете просто иметь одного пользователя SQL (без ассоциированного входа в систему), который имеет схему для связанного арендатора в качестве схемы по умолчанию, а затем оставить схему вне ваш повседневный SQL. Вам придется перехватывать вызовы в базе данных и заключать их в вызов подражания. Как я уже сказал, я не совсем уверен, как это работает в Oracle, но это общая идея для SQL Server.
  • Аутентификация и безопасность являются здесь серьезной проблемой. Это далеко выходит за рамки того, что я могу обсудить в этом ответе, но убедитесь, что вы правильно поняли .
...