Привет всем. Посоветоваться хочу. Сочиняю схему БД для записи звонков. Суть такая

есть таблицы:
- звонки: id, номера всякие, время старта, врем конца
- нарушения во время звонков: id звонка, тип нарушения, таймстемп, проверено/не проверено
- данные по биллингу звонков: id звонка, тариф, интервал, сумма

И тут такой момент таблица со звонками будет большая и с большой глубиной хранения. 500+ГБ несколько лет хранения. А в интерфейс системы, конечно же будет выводиться результат джоина всех этих таблиц и будет куча фильтров.
Помимо этого в таблицу со звонками будет идти интенсивная запись, т.к. звонков много.

Вопрос: если сделать в звонках поля start_time и end_time, то сначала запись будет инсертиться в таблицу, а потом, по завершении звонка апдейтиться по полю end_time. Не вызовет ли это проблемы конкуренции, т.к. вставляется куча записей в конец таблицы, а потом апдейтится.

может лучше сделать таблицу со звонками + отдельную таблицу с временем начала и конца: id звонка, начало/конец, таймстемп?

такой же вопрос по биллингу: можно в таблице звонков завести соответствующие поля и обновлять в конце звонка. но с биллингом я на 99% уверен, что отдельная таблица будет лучше.

СУБД будет постгрес. я думал вкорячить timescaledb, партиционировать большие таблицы по дате и ограничить по дате в интерфейсе пользователя выборку каким-нибудь способом, чтобы не больше нескольких месяцев за раз тягал.
Есть какие-то мысли?

реляционная база для этого ничего, лучше все писать в inmemory типа тарантула или аналогов, а потом уже от туда безконфликтно как тебе удобно для аналитики раскладывать в SQL или Clickhouse

боюсь, стек тут менять не будут)))

вообще, я подумал отнестись к этому, как к данным мониторинга (потипу заббикса). записи только аппендятся в конец. старые не удаляются, и не изменяются. чем старше данные, тем меньше вероятность, что к ним обратятся. timescale как раз отлично повзоляет вертеть довольно большие БД заббикса на ПГ (у нас как раз гигов на 500-600 крутится)

ну в целом у вас правильные мысли по поводу секционирования и интерфейсных ограничений глубины 500 гигов сейчас не очень много, в общем в неденормализованной структуре туда немало влезет

или ты про бд заббы в 500гигов. тут такой момент, что без таймскейла заббикс начал унывать в районе 150-200ГБ

профиль нагрузки у систем, заполняющих хранилище автоматически собираемыми данными принципиально отличается от регистрации человеческой активности (людей мало, действий они совершают мало) исключение - компании уровня операторов связи федерального масштаба, сервисы компаний уровня гугла, амазона, яндекса - но их CTO сюда за советами не приходят

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