Multitenancy(мультиарендность) — это подход к проектированию приложения, когда один экземпляр приложений обслуживает несколько клиентов с непересекающимися наборами данных. Например сайт по учёту персональных финансов имеет одну копию кода, одно хранилище данных и много клиентов, при этом каждому клиенту доступны только его собственные данные. Наиболее популярен этот подход, по очевидным причинам, в облачных SaaS решениях — каждый клиент видит общий, единый, экземпляр приложения как свою собственную копию.
Чаще всего проблемы с реализацией multitenancy кроются не на уровне логики приложения, а на уровне хранения данных: мы должны уметь отделять данные одного клиента от другого и не давать им шанса смешаться. Существует три основных подхода к решению этой проблемы:
- Разделение на уровне базы данных — под каждого клиента создаётся (или запускается) отдельный экземпляр БД, уникальный для этого клиента и в нём распологаются данные только этого клиента.
- Разделение на уровне схемы — в одной и той же базе данных создаются разные схемы (schema/namespace) в которых создаются копии структуры таблиц, необходимых для работы клиента и данные каждого клиента живут в отдельно схеме.
- Разделение на уровне таблиц — и база данных одна, и схема одна, и даже таблицы те же самые. Но в каждой таблице заводится столбец (дискриминатор), указывающий, какому клиенту принадлежит какая таблица.
Hibernate поддерживает первые два подхода к multitenancy, а третий подход можно реализовать вручную, используя интерцепторы и фильтры.
Фильтры в Hibernate
Hibernate позволяет определить простое SQL условие, которое будет прикладываться к любом запросу. Фактически фильтр это просто параметризованное SQL условие с именем, которое в рамках одной сессии прикладывается к каждому выполняемому запросу.
Определяется фильтр в два шага: вначале задаётся имя фильтра и список его параметров, затем собственно текст запроса для фильтра. Например, зная что мы делаем основанную на дискриминаторе multitenancy, и что в каждой таблице есть столбец дискриминатора, который называется, допустим, tenantId, мы могли бы написать следующий фильтр:
1 2 3 4 5 6 | @FilterDefs({ @FilterDef(name = "discriminator_filter", parameters={@ParamDef( name="tenantIdValue", type="string" )} ) }) @Filters({ @Filter(name="discriminator_filter", condition="tenantId = :tenantIdValue") }) |
Фильтр называется discriminator_filter, принимает параметр tenantIdValue типа String. Фильтр добавит к запросу SQL условие tenantId = :tenantIdValue.
Чтобы использовать фильтр, необходимо разрешить его применение в сессии:
1 2 3 4 | session = sessionFactory .openSession(); session.enableFilter("discriminator_filter") .setParameter("tenantIdValue", "de"); |
Discriminator multitenancy
Выше пример использования фильтров в Hibernate показывает, как ограничивать запросы по tenant id, хранящемуся в таблицах. Но этого недостаточно — его надо хранить и корректно заполнять.
В отличие от других подходов к multitenancy, этот подход требует внесения изменений в схему данных, в частности добавления столбца дискриминатора. Это проще всего сделать создав отдельный @MappedSuperclass для хранения этого столбца и унаследовать все остальные сущности от него.
1 2 3 4 5 6 7 8 9 10 | @MappedSuperclass public class AbstractDiscriminatorObject extends AbstractIdentifiableObject { /** * Actual tenant id value. */ @Getter @Setter private String tenantId; } |
Я использовал схему данных из других примеров multitenancy и добавил в неё дополнительный класс. В коде выше хорошо видно, что классы с @MappedSuperclass могут быть унаследованы друг от друга и создавать достаточно сложные иерархии наследования.
Последней частью имитации discriminator based multitenancy станет интерцептор, который будет заполнять tenant id при сохранении сущности в базу.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | public class DiscriminatorSettingInterceptor extends EmptyInterceptor { private TenantIdResolver resolver = new TenantIdResolver(); @Override public void preFlush(Iterator entities) { entities.forEachRemaining(o -> { if (o instanceof AbstractDiscriminatorObject) { AbstractDiscriminatorObject t = (AbstractDiscriminatorObject) o; if (t.getTenantId() == null) { String tenantId = resolver.resolveCurrentTenantIdentifier(); if (tenantId == null) { throw new IllegalStateException("No tenant id specified"); } t.setTenantId(tenantId); } } }); super.preFlush(entities); } } |
Код достаточно сложен на первый взгляд, но на самом деле ничего сверхестественного здесь не происходит. В метод preFlush() передаётся итератор с сохраняемыми сущностями, для каждой из которых проверяется тип и, если она содержит столбец дискриминатора и он пуст, он заполняется текущим значением tenant id. В качестве источника tenant id используется, весьма в стиле Hibernate, реализация интерфейса CurrentTenantIdentifierResolver, которая (в моём случае) просто хранит заранее заданное значение.
Наконец попробуем использовать всё что мы написали выше:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 | protected void writeAUPerson() { resolver.setCurrentTenantIdentifier("au"); Session session = sessionFactory .openSession(); session.beginTransaction(); Passport p = new Passport(); p.setSeries("AS"); p.setNo("123456"); p.setIssueDate(LocalDate.now()); p.setValidity(Period.ofYears(20)); Address a = new Address(); a.setCity("Kickapoo"); a.setStreet("Main street"); a.setBuilding("1"); Person person = new Person(); person.setFirstName("Test"); person.setLastName("Testoff"); person.setDob(LocalDate.now()); person.setPrimaryAddress(a); person.setPassport(p); Company c = new Company(); c.setName("Acme Ltd"); p.setOwner(person); person.setWorkingPlaces(Collections.singletonList(c)); session.merge(person); session.getTransaction().commit(); session.close(); } |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 | protected void writeDEPerson() { resolver.setCurrentTenantIdentifier("de"); Session session = sessionFactory .openSession(); session.beginTransaction(); Passport p = new Passport(); p.setSeries("RY"); p.setNo("654321"); p.setIssueDate(LocalDate.now()); p.setValidity(Period.ofYears(20)); Address a = new Address(); a.setCity("Oberdingeskirchen"); a.setStreet("Hbf Platz"); a.setBuilding("1"); Person person = new Person(); person.setFirstName("Johan"); person.setLastName("von Testoff"); person.setDob(LocalDate.now()); person.setPrimaryAddress(a); person.setPassport(p); Company c = new Company(); c.setName("Acme Ltd"); p.setOwner(person); person.setWorkingPlaces(Collections.singletonList(c)); session.merge(person); session.getTransaction().commit(); session.close(); } |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 | @Test public void testGreeter() { writeAUPerson(); writeDEPerson(); Session session = sessionFactory .openSession(); session.enableFilter("discriminator_filter") .setParameter("tenantIdValue", "au"); session.beginTransaction(); session .createCriteria(Person.class) .list() .stream() .forEach(System.out::println); session.getTransaction().commit(); session.close(); session = sessionFactory .openSession(); session.enableFilter("discriminator_filter") .setParameter("tenantIdValue", "de"); session.beginTransaction(); session .createCriteria(Person.class) .list() .stream() .forEach(System.out::println); session.getTransaction().commit(); session.close(); } |
1 2 | Person{firstName='Test', lastName='Testoff', dob=2016-11-04, passport=Passport{series='AS', no='123456', issueDate=2016-11-04, validity=P20Y, owner=Testoff}, primaryAddress=Address{city='Kickapoo', street='Main street', building='1', tenants=Test}, workingPlaces=[Company{name='Acme Ltd', workers=Test}]} Person{firstName='Johan', lastName='von Testoff', dob=2016-11-04, passport=Passport{series='RY', no='654321', issueDate=2016-11-04, validity=P20Y, owner=von Testoff}, primaryAddress=Address{city='Oberdingeskirchen', street='Hbf Platz', building='1', tenants=Johan}, workingPlaces=[Company{name='Acme Ltd', workers=Johan}]} |
