Вопрос или проблема
Рассмотрим следующую упрощенную базу данных системы веб-аналитики.
Арендаторы
-------
id
название
временные метки
Веб-сайты
--------
id
название
временные метки
tenant_id
События
------
id
название (просмотр страницы, клик, скачивание и т.д.)
браузер
ос
устройство
временная метка
website_id
tenant_id
Я знаю, что мы должны добавить столбец tenant_id в каждую таблицу для изоляции или целостности данных.
Но что насчет таких таблиц, как events, которая станет огромной (миллиарды строк), поскольку мы храним каждое событие в виде новой строки?
Мы всегда будем фильтровать события по website_id, и у него уже есть поле tenant_id.
Стоит ли все равно добавлять tenant_id в эту таблицу и каковы плюсы и минусы?
Ответ или решение
Сохранение идентификатора арендатора (tenant_id) в каждой таблице базы данных в многопользовательской среде (multi-tenant) является важным аспектом проектирования структуры базы данных, однако есть нюансы, которые стоит учитывать, особенно в случаях, когда речь идет о больших таблицах, таких как таблица событий.
Должен ли я хранить tenant_id в каждой таблице?
Ответ: Да, желательно хранить tenant_id в таблице events.
Вот основные причины для включения tenant_id в таблицу events, несмотря на то, что идентификатор арендатора уже содержится в связанной таблице websites:
1. Упрощение запросов
Когда tenant_id находится непосредственно в таблице events, запросы становятся проще и понятнее. Вам не нужно будет делать дополнительные соединения (JOIN) с таблицей websites, чтобы определить, к какому арендатору относится каждое событие. Это может существенно упростить SQL-запросы, особенно если частота обращений к столбцу events высокая.
2. Повышение производительности
Фильтрация по tenant_id в таблице events может улучшить производительность запросов. Если бы вам приходилось использовать соединение с таблицей websites, это потребовало бы дополнительных ресурсов, особенно если events имеет миллиарды строк. Индексы на tenant_id и другие столбцы могут помочь в ускорении запросов.
3. Гибкость в аналитике
Возможно, в будущем вам придётся выполнять анализ или генерировать отчеты, которые напрямую связаны с идентификатором арендатора. Хранение tenant_id непосредственно в таблице событий упрощает такие сценарии.
Возможные недостатки
1. Увеличение объема данных
Это может привести к некоторому увеличению объема данных в базе, так как tenant_id будет дублироваться в каждой записи событий. Однако, в большинстве случаев, это увеличение достаточно минимально по сравнению с общим объемом данных, а преимущества производительности и удобства использования перевешивают этот недостаток.
2. Усложнение согласованности данных
При необходимости изменения tenant_id (например, по ошибке при миграции), у вас может возникнуть ситуация, когда значение в таблице events и соответствующее значение в таблице websites могут стать несогласованными. Однако это также можно решить с помощью правильно реализованных триггеров и процедур, которые обеспечивают целостность данных.
Заключение
В итоге, хранение tenant_id прямо в таблице events в большинстве случаев является рекомендуемым подходом для упрощения запросов и повышения производительности. Хотя это добавляет некоторые дополнительные данные, выгоды в удобстве и быстродействии обычно перевешивают недостатки. Это решение также улучшает гибкость при работе с данными и аналитическими запросами.
Таким образом, при проектировании многопользовательской базы данных не следует пренебрегать целостностью и доступностью данных, и хранение tenant_id в таких больших таблицах, как events, будет целесообразным шагом.