#mysql #mariadb #amazon-aurora
#mysql #mariadb #amazon-aurora
Вопрос:
Я полностью понимаю плюсы и минусы использования общих и отдельных схем (или баз данных в mysql). Рассматривая те, которые мы выбрали для использования общей схемы.
Ищу идеи о том, как мы можем более легко реализовать мультитенантность. Я рад добавить ключ к каждой таблице, но это означает, что нам нужно будет добавить «where tenant_id = X» для каждой отдельной таблицы, которая использует мультитенантность в каждом отдельном запросе. Звучит болезненно.
Гораздо лучшим подходом было бы установить некоторый параметр, который влияет на все таблицы в запросе или на все запросы в соединении. Это позволило бы избежать необходимости обновлять все существующие запросы и включать проверки идентификаторов клиентов в будущие запросы.
У меня было несколько первоначальных идей (ниже), но все они также кажутся довольно болезненными.
-
Создайте временные представления для каждой таблицы, которые автоматически фильтруются по идентификатору клиента (возможно, с использованием временных таблиц?)
-
Создайте представления, которые фильтруют по идентификатору клиента и динамически задают имя таблицы в запросе
-
Используйте разделы по идентификатору клиента и запрашивайте отдельные разделы.
У кого-нибудь есть идеи получше?
Комментарии:
1. Рассматривали ли вы префикс имени таблицы?
2. Итак, разделяем каждую таблицу на несколько таблиц с префиксом клиента? Я не думаю, что практично создавать новый набор таблиц для каждого клиента, потому что это усложнило бы добавление клиентов и затруднило бы внесение изменений в таблицу, поскольку нам нужно было бы обновить X таблиц вместо одной.
3. Вы не указали, что у каждого клиента идентичная схема. Я все равно не вижу проблемы. Имея столбец в каждой таблице, вы, конечно, получаете возможность использовать разделы таблицы. И вы, вероятно, собираетесь поместить какую-то оболочку вокруг всего, чтобы вам все равно не нужно было добавлять предложение WHERE к каждому запросу.
4. Я полагал, что при использовании общей схемы это означает, что все арендаторы будут частью одной и той же схемы. Мне любопытно, что вы имели в виду под оболочкой, хотя, какую оболочку вы имеете в виду? Спасибо!
Ответ №1:
Одна из проблем с моделью общей схемы, которую вы предлагаете, — это ваши клиенты. В прошлом я работал с рядом компаний, в клиентских соглашениях которых оговаривалось, что их данные должны быть автономными и не смешиваться с другими клиентскими данными, что означало, что нам приходилось использовать отдельную схему для каждого клиентского маршрута.
Возможно, вы обнаружите, что это также более гибкое решение, поскольку, если какой-либо из ваших клиентов станет действительно большим, вы можете переместить их на их собственный сервер / экземпляр и использовать утилиту, такую как ProxySQL, для направления трафика на соответствующий сервер / экземпляр на основе имени схемы.
Если у вас есть данные, которые являются общими для всех клиентов, поместите их на собственный «основной» сервер, который реплицируется на клиентские серверы. Затем вы можете выполнить дальнейшую репликацию, связав реплики с клиентского сервера (ов), если вам нужно увеличить объем ваших операций чтения.
Как бы вы ни решили это сделать, я бы просто был осторожен с юридическими последствиями объединения клиентских данных в единую схему — проверьте, есть ли у вас разрешение клиента на объединение данных. Очевидно, что если вы создаете что-то вроде социальной сети, то вам нужно будет объединить данные, но этого следовало ожидать.