Многопользовательский доступ
На платформе аналитики данных SaaS обычно несколько арендаторов, такие как организации, клиенты или бизнес-единицы, используют одну и ту же инфраструктуру базы данных, при этом сохраняется логическое разделение их данных. Это позволяет различным пользователям безопасно получать доступ к своим данным на одной и той же платформе.
В зависимости от требований, существуют различные способы реализации многопользовательского доступа. Ниже представлен гид по их реализации с ClickHouse Cloud.
Общая таблица
В этом подходе данные всех арендаторов хранятся в одной общей таблице, при этом для идентификации данных каждого арендатора используется поле (или набор полей). Чтобы максимизировать производительность, это поле должно быть включено в первичный ключ. Для обеспечения того, чтобы пользователи могли получать доступ только к данным, принадлежащим их арендаторам, используется контроль доступа на основе ролей, реализованный через политики строк.
Мы рекомендуем этот подход, так как он является самым простым в управлении, особенно когда все арендаторы используют одну и ту же схему данных, а объем данных умеренный (< TBs)
Консолидируя все данные арендаторов в одну таблицу, мы улучшаем эффективность хранения за счет оптимизированного сжатия данных и уменьшения накладных расходов на метаданные. Кроме того, обновления схемы упрощаются, так как все данные управляются централизованно.
Этот метод особенно эффективен для работы с большим количеством арендаторов (возможно, миллионов).
Однако альтернативные подходы могут быть более подходящими, если у арендаторов разные схемы данных или ожидается их расхождение с течением времени.
В случаях, когда существует значительный разрыв в объеме данных между арендаторами, меньшие арендаторы могут столкнуться с неоправданными проблемами производительности запросов. Обратите внимание, что эта проблема в значительной степени устраняется за счет включения поля арендатора в первичный ключ.
Пример
Вот пример реализации модели многопользовательского доступа с использованием общей таблицы.
Сначала создадим общую таблицу с полем tenant_id, включенным в первичный ключ.
Вставим фейковые данные.
Затем создадим двух пользователей user_1 и user_2.
Мы создаем политики строк, которые ограничивают доступ user_1 и user_2 только к данным их арендаторов.
Затем GRANT SELECT привилегии на общую таблицу с использованием общей роли.
Теперь вы можете подключиться как user_1 и выполнить простой запрос select. Будут возвращены только строки от первого арендатора.
Отдельные таблицы
В этом подходе данные каждого арендатора хранятся в отдельной таблице в одной базе данных, что устраняет необходимость в конкретном поле для идентификации арендаторов. Доступ пользователей обеспечивается с использованием операторов GRANT, гарантирующих, что каждый пользователь может получать доступ только к таблицам, содержащим данные их арендаторов.
Использование отдельных таблиц - хороший выбор, когда у арендаторов разные схемы данных.
Для сценариев с несколькими арендаторами с очень большими наборами данных, где производительность запросов имеет критическое значение, этот подход может превзойти модель с общей таблицей. Поскольку нет необходимости фильтровать данные других арендаторов, запросы могут быть более эффективными. Кроме того, первичные ключи могут быть дополнительно оптимизированы, так как нет необходимости включать дополнительное поле (например, идентификатор арендатора) в первичный ключ.
Обратите внимание, что этот подход не масштабируется для 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 для каждого арендатора.
Этот менее распространенный метод может быть решением, если данные арендаторов должны храниться в разных регионах - по юридическим, Sicherheits- или пространственным причинам.
Необходимо создать учетную запись пользователя на каждом сервисе, где пользователь сможет получить доступ к данным своего арендатора.
Этот подход сложнее в управлении и требует дополнительных ресурсов для каждого сервиса, поскольку каждый из них требует своей собственной инфраструктуры для работы. Услуги могут управляться через ClickHouse Cloud API с возможной оркестрацией также через официальный провайдер Terraform.
Пример
Это пример реализации модели многопользовательского доступа с использованием отдельного сервиса. Обратите внимание, что пример показывает создание таблиц и пользователей на одном сервисе ClickHouse, то же самое должно быть воспроизведено на всех сервисах.
Сначала создадим таблицу events
Вставим фейковые данные.
Затем создадим пользователя user_1
Затем предоставим привилегии GRANT SELECT на соответствующую таблицу.
Теперь вы можете подключиться как user_1 на сервисе для арендатора 1 и выполнить простой запрос select. Будут возвращены только строки от первого арендатора.
