Многослойность

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

В зависимости от требований существуют разные способы реализации многослойности. Ниже приведено руководство о том, как реализовать это с помощью ClickHouse Cloud.

Общая таблица

В этом подходе данные всех арендаторов хранятся в одной общей таблице, с полем (или набором полей), используемым для идентификации данных каждого арендатора. Для максимизации производительности это поле должно быть включено в первичный ключ. Чтобы гарантировать, что пользователи могут получать доступ только к данным, принадлежащим их соответствующим арендаторам, мы используем контроль доступа на основе ролей, реализованный через политики строк.

Мы рекомендуем этот подход, так как он является самым простым в управлении, особенно когда все арендаторы используют одну и ту же схему данных, а объемы данных являются умеренными (< ТБ)

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

Этот метод особенно эффективен для работы с большим количеством арендаторов (потенциально миллионами).

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

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

Пример

Это пример реализации модели многослойности с общей таблицей.

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

Теперь вставим фиктивные данные.

Теперь создадим двух пользователей user_1 и user_2.

Мы создаем политики строк, которые ограничивают доступ user_1 и user_2 только к данным их арендаторов.

Затем GRANT SELECT привилегии на общую таблицу, используя общую роль.

Теперь вы можете подключиться как user_1 и выполнить простой запрос. Вернутся только строки от первого арендатора.

Отдельные таблицы

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

Использование отдельных таблиц является хорошим выбором, когда арендаторы имеют разные схемы данных.

Для сценариев с несколькими арендаторами с очень большими наборами данных, где производительность запросов критична, этот подход может опередить модель общей таблицы. Поскольку нет необходимости фильтровать данные других арендаторов, запросы могут быть более эффективными. Кроме того, первичные ключи могут быть дополнительно оптимизированы, так как нет необходимости включать дополнительное поле (такое как ID арендатора) в первичный ключ.

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

Пример

Это пример реализации модели многослойности с отдельными таблицами.

Сначала создадим две таблицы, одну для событий от tenant_1 и одну для событий от tenant_2.

Теперь вставим фиктивные данные.

Теперь создадим двух пользователей user_1 и user_2.

Затем предоставьте GRANT SELECT привилегии на соответствующую таблицу.

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

Отдельные базы данных

Данные каждого арендатора хранятся в отдельной базе данных в одном и том же сервисе ClickHouse.

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

Исполнение аналогично подходу с отдельными таблицами, но вместо предоставления привилегий на уровне таблицы привилегии предоставляются на уровне базы данных.

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

Пример

Это пример реализации модели многослойности с отдельными базами данных.

Сначала создадим две базы данных, одну для tenant_1 и одну для tenant_2.

Теперь вставим фиктивные данные.

Теперь создадим двух пользователей user_1 и user_2.

Затем предоставьте GRANT SELECT привилегии на соответствующую таблицу.

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

Разделение вычислений

Три подхода, описанные выше, также могут быть дополнительно изолированы с помощью Хранилищ. Данные обмениваются через общее объектное хранилище, но каждый арендатор может иметь свою собственную вычислительную службу благодаря разделению вычислений с различным соотношением CPU/Памяти.

Управление пользователями аналогично подходам, описанным ранее, так как все сервисы в хранилище разделяют контроль доступа.

Обратите внимание, что количество дочерних служб в одном хранилище ограничено небольшим числом. См. Ограничения хранилища.

Отдельный облачный сервис

Самый радикальный подход - использовать отдельный сервис ClickHouse для каждого арендатора.

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

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

Этот подход сложнее в управлении и требует дополнительных ресурсов для каждого сервиса, так как каждый из них требует своей инфраструктуры. Управлять сервисами можно через API ClickHouse Cloud, а также проводить оркестрацию через официальный провайдер Terraform.

Пример

Это пример реализации модели многослойности с отдельным сервисом. Обратите внимание, что пример показывает создание таблиц и пользователей на одном сервисе ClickHouse, то же самое будет необходимо воспроизвести на всех сервисах.

Сначала создадим таблицу events

Теперь вставим фиктивные данные.

Теперь создадим двух пользователей user_1

Затем предоставьте GRANT SELECT привилегии на соответствующую таблицу.

Теперь вы можете подключиться как user_1 на сервисе для арендатора 1 и выполнить простой запрос. Вернутся только строки от первого арендатора.