Какая платформа аналитики мне подойдет?

Question

[Narts]

Привет! Есть веб-приложение, где в базе данных в специальной таблице я храню атрибуты юзера: если пользователь подтвердил email, то создается запись с user_id, attrubite: 'email_confirmed'; если пользователь создал пост, то user_id, attrubite: 'has_post'. Со временем количество атрибутов возрастает и кажется неправильным хранить их в бд, где также хранятся юзеры, посты и прочая бизнес инфа.

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

Резюмируя, требований несколько:
- Хранение и обновление атрибутов пользователя в связке id, date, updated_date, user_id, attrubute, payload
- Возможность выгрузки user_id с нужными мне атрибутами
- Возможность строить графики по аттрибутам
- Сохранение продуктовой аналитиики, по типу переходов по страницам, клики, гео
- Возможность строить графики по продуктовой аналитике
- Либо решение, которые нужно разворачивать на своем сервере; либо saas, но при котором не будет проблем с санкциями, геополитикой и прочим

Есть ли подобные инструменты которые такое умеют?)

Answer 1

[rPman]

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

Теперь по способ хранения, когда ты в базе начинаешь изобретать универсальное хранилище key-entity-value, ты лишаешься значительной доли производительности и контроля за целостностью.

Правильно - заводить по полю в таблице user (лучше создать отдельную 1к1 связью, обслуживать ее будет проще). Если вы привыкли заводить атрибуты из интерфейса, то нет никакой особой разницы, делать это ddl alter table или dml insert (на самом деле есть, если записей миллионы или миллиарды, бд при удалении колонки пересоздает таблицу копированием, и это будет долго), а вот возможность создать индивидуальный индекс на каждый атрибут многого стоит.

Есть ещё варианты, например атрибуты boolean, если нет необходимости в null, можно хранить в отдельной таблице, фактом наличия записи (представь таблицу с единственным полем user_id), очень эффективно, если установленных значений много меньше всех записей.
И помни, если из-за аналитики поднимается нагрузка на основную базу, можно настроить репликации на другую году, и работать по аналитике именно с ней...