Многопользовательская среда
На платформе SaaS для аналитики данных часто несколько арендаторов, таких как организации, клиенты или бизнес-единицы, используют одну и ту же инфраструктуру баз данных, при этом обеспечивая логическое разделение своих данных. Это позволяет различным пользователям безопасно получать доступ к своим данным в рамках одной и той же платформы.
В зависимости от требований существуют различные способы реализации многопользовательской среды. Ниже приводится руководство о том, как реализовать их с помощью ClickHouse Cloud.
Общая таблица
В этом подходе данные всех арендаторов хранятся в одной общей таблице, при этом используется поле (или набор полей) для идентификации данных каждого арендатора. Чтобы максимизировать производительность, это поле должно быть включено в первичный ключ. Для обеспечения того, чтобы пользователи могли получать доступ только к данным, принадлежащим их арендаторам, мы используем контроль доступа на основе ролей, реализованный через политики строк.
Мы рекомендуем этот подход, так как он является самым простым в управлении, особенно когда все арендаторы используют одну и ту же схему данных, а объемы данных умеренные (< ТБ)
Объединив все данные арендаторов в одну таблицу, мы улучшаем эффективность хранения за счет оптимизированного сжатия данных и уменьшения накладных расходов на метаданные. Кроме того, обновления схемы упрощаются, так как все данные управляются централизованно.
Этот метод особенно эффективен при работе с большим количеством арендаторов (потенциально миллионов).
Однако альтернативные подходы могут быть более подходящими, если арендаторы имеют разные схемы данных или ожидается, что они будут divergiровать со временем.
В случаях, когда существует значительное различие в объемах данных между арендаторами, меньшие арендаторы могут столкнуться с нежелательными проблемами производительности запросов. Обратите внимание, что эта проблема в значительной степени смягчается за счет включения поля арендатора в первичный ключ.
Пример
Вот пример реализации модели многопользовательской среды с общей таблицей.
Сначала создадим общую таблицу с полем tenant_id, включенным в первичный ключ.
Давайте вставим фиктивные данные.
Затем создадим двух пользователей user_1 и user_2.
Мы создаем политики строк, которые ограничивают доступ user_1 и user_2 только к данным их арендаторов.
Затем GRANT SELECT привилегии на общую таблицу, используя общую роль.
Теперь вы можете подключиться как user_1 и выполнить простой запрос select. Будут возвращены только строки от первого арендатора.
Отдельные таблицы
В этом подходе данные каждого арендатора хранятся в отдельной таблице в одной базе данных, что устраняет необходимость в конкретном поле для идентификации арендаторов. Доступ пользователей обеспечивается с помощью оператора GRANT, что гарантирует, что каждый пользователь может получать доступ только к таблицам, содержащим данные их арендаторов.
Использование отдельных таблиц — это хороший выбор, когда у арендаторов разные схемы данных.
Для сценариев с небольшим числом арендаторов с очень большими наборами данных, где производительность запросов критична, этот подход может превзойти модель общей таблицы. Поскольку нет необходимости фильтровать данные других арендаторов, запросы могут быть более эффективными. Кроме того, первичные ключи можно дополнительно оптимизировать, поскольку нет необходимости включать дополнительное поле (например, ID арендатора) в первичный ключ.
Обратите внимание, что этот подход не масштабируется для 1000 арендаторов. См. ограничения использования.
Пример
Вот пример реализации модели многопользовательской среды с отдельными таблицами.
Сначала создадим две таблицы, одну для событий из tenant_1 и одну для событий из tenant_2.
Давайте вставим фиктивные данные.
Затем создадим двух пользователей user_1 и user_2.
Затем предоставим GRANT SELECT привилегии на соответствующую таблицу.
Теперь вы можете подключиться как user_1 и выполнить простой запрос select из таблицы, соответствующей этому пользователю. Будут возвращены только строки от первого арендатора.
Отдельные базы данных
Данные каждого арендатора хранятся в отдельной базе данных в рамках одного сервиса ClickHouse.
Этот подход полезен, если каждому арендатору требуется большое количество таблиц и, возможно, материализованных представлений, и у него различная схема данных. Однако он может стать сложным в управлении, если число арендаторов велико.
Реализация схожа с подходом отдельных таблиц, но вместо предоставления привилегий на уровне таблицы привилегии предоставляются на уровне базы данных.
Обратите внимание, что этот подход не масштабируется для 1000 арендаторов. См. ограничения использования.
Пример
Вот пример реализации модели многопользовательской среды с отдельными базами данных.
Сначала создадим две базы данных, одну для tenant_1 и одну для tenant_2.
Давайте вставим фиктивные данные.
Затем создадим двух пользователей user_1 и user_2.
Затем предоставим GRANT SELECT привилегии на соответствующую таблицу.
Теперь вы можете подключиться как user_1 и выполнить простой запрос на таблицу событий соответствующей базы данных. Будут возвращены только строки от первого арендатора.
Разделение вычислительных ресурсов
Три описанных выше подхода также могут быть дополнительно изолированы с использованием Складов. Данные хранятся в общем объектном хранилище, но у каждого арендатора может быть своя вычислительная служба благодаря разделению вычислительных ресурсов с различным соотношением CPU/Память.
Управление пользователями аналогично ранее описанным подходам, поскольку все службы в складе разделяют контроль доступа.
Обратите внимание, что количество дочерних служб в складе ограничено небольшим числом. См. Ограничения склада.
Отдельная облачная служба
Самый радикальный подход — использовать отдельную службу ClickHouse для каждого арендатора.
Этот менее распространенный метод может быть решением, если данные арендаторов должны храниться в разных регионах – по юридическим,安全ным или другим причинам.
Учетная запись пользователя должна быть создана на каждой службе, где пользователь может получать доступ к данным своего арендатора.
Этот подход труднее управлять и накладывает дополнительные затраты на каждую службу, так как каждая требует собственной инфраструктуры для работы. Службы можно управлять через ClickHouse Cloud API, а также возможно оркестрация через официальный Terraform provider.
Пример
Вот пример реализации модели многопользовательской среды с отдельной службой. Обратите внимание, что в примере показано создание таблиц и пользователей на одной службе ClickHouse, то же самое необходимо будет воспроизвести на всех службах.
Сначала создадим таблицу events
Давайте вставим фиктивные данные.
Затем создадим двух пользователей user_1
Затем предоставим GRANT SELECT привилегии на соответствующую таблицу.
Теперь вы можете подключиться как user_1 на службе арендатора 1 и выполнить простой запрос. Будут возвращены только строки от первого арендатора.