Какой тип базы данных выбрать для хранения событий звонков и почему

Что проверяют

Умеете ли вы выбирать хранилище по профилю нагрузки, а не по моде. Интервьюер ждёт встречных вопросов: сколько событий в секунду, какие запросы, как долго хранить. Следом обычно спрашивают, как эти данные попадут в признаки для модели, например для автоотклонения спам-звонков.

Как отвечать

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

Под такой профиль подходит колоночная база, чаще всего ClickHouse:

• MergeTree: с PARTITION BY toYYYYMM(ts) и ORDER BY (caller, ts) запрос по номеру и окну времени читает малую часть данных;
• TTL: старые события удаляются автоматически, это важно, раз номер телефона относится к персональным данным;
• загрузка из Kafka: табличный движок Kafka или отдельный консьюмер, вставки пачками по тысячам строк, иначе сервер захлебнётся мелкими частями.

Смену статуса звонка пишите новым событием, а не UPDATE: изменения в ClickHouse это тяжёлые фоновые мутации. Для последней версии записи есть ReplacingMergeTree, но дубли он схлопывает только при слияниях, так что без FINAL или argMax можно увидеть старое значение.

Для модели разделите хранилища. Офлайн: история в ClickHouse или Parquet в объектном хранилище, оттуда собирается обучающая выборка. Онлайн: свежие признаки по номеру в Redis, потому что решение об отклонении нужно за миллисекунды. Если событий немного, хватит PostgreSQL с секционированием по дате.

Где спотыкаются

Выбирают MongoDB, «потому что данных много и схема гибкая». Агрегаты по времени документная база считает медленнее колоночной, а схема у событий звонков как раз стабильная.

Проектируют хранилище под аналитику и забывают про онлайн-скоринг. ClickHouse не рассчитан на тысячи точечных запросов в секунду с ответом за миллисекунды на каждый входящий звонок.

Не говорят о сроке хранения и маскировании номеров. Бессрочное хранение персональных данных в открытом виде это юридический риск.