Практическая реализация мультитенантного подхода в mysql / mariadb (или amazon aurora)

Question

Я полностью понимаю плюсы и минусы использования общих и отдельных схем (или баз данных в MySQL). Глядя на те, которые мы выбрали для использования общей схемы.

Ищем идеи о том, как нам легче реализовать мультитенантность. Я рад добавить ключ к каждой таблице, но это означает, что нам нужно будет добавить «where tenant_id = X» для каждой таблицы, которая использует многопользовательскую структуру в каждом отдельном запросе. Звучит больно.

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

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

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

2. Создание представлений, которые фильтруют по идентификатору арендатора и динамически задают имя таблицы в запросе

3. Использовать разделы по идентификатору клиента и запрашивать отдельные разделы.

У кого-нибудь есть идеи получше?

Answer 1

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

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

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

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