mayton2019

Был такой нудный дедушка Эдгар Кодд. Он как-то из соображений своей нудности взял и объявил что только он знает как правильно делать реляционные базы.

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

Но если внутри JSON будет поле которое способно изменяться независимо от остальной части документа - то старичок Эдгар будет на вас сильно зол. Может даже вас побить.

В наше время уже созданы специализированне БД (Mongo, CouchDb) которые плевали на нормализацию. Они расширяют и ослабляют понятия нормализации. Not-Only-SQL говорят про себя.

Данные из таблиц как всегда удаляются через DELETE FROM table ... но если есть ограничения констрейнтов - то надо указать опцию CASCADE.

Вообще в очень сложных и много-уровневых БД необычайно тяжело что-то удалять. Иногда удаление одной строки вызывает долгий процесс проверки зависимостей. Особенно на массовых удалениях.

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

11 миллионов inserts в день - это 127 в секунду. При такой нагрузке справится любая современная БД. Ну я не знаю таких чтоб не справлялись. Делайте только короткую буферизацию и batch-insert пачками по 100 - 1000 чтобы оптимизировать сетевой roundtrip.

Есть специализированные NoSQL системы такие как RocksDb, Tarantool в которых именно много оптимизаций сделано было для быстрой вставки. Они выдерживают и во много раз быстрее.

И в данной задаче нужно также спросить бизнес - как быстро данные нужны к чтению пользователя. Нужно сию секунду чтоб они отобразились на UI или можно подождать пару минут или часов.

Если backend это Java - то заявлен тип данных java.time.LocalDate. Он - сериализуемый следовательно будет однозначно писаться и считываться из памяти и из сети.

Вообще у программистов backend не возникает вопросов как "лучше хранить" и передавать время. Если вы хотите сильно экономить то храните и передавайте количество секунд с начала суток. Это будет целое число от 0 до 86400. Достаточно экономно. Но будете иметь свои трения при согласовании форматов между отделами разработки фронта и бєка. Можете передавать строкой как есть "08:40:20" но договоритесь о запрещенных комбинациях и так далее.

Короче этот вопрос не про Postgres а про технологии сериализации даты-времени, стандарты и протоколы.

Это может называться temporal database. Когда есть дата активации объекта. Нативную поддержку темпоральности имеют Oracle, MS-SQL. С помощью темпоральности удобно трекать юридическую информацию. Например владение чем-то. Или биржевые мета-данные.

Еще вариант bi-temporal, это когда для объекта пишуться две даты. Та-же темпоральная и еще другая типа даты регистрации событий.

Postgresql - более консервативен. Его можно брать почти для любых проектов. Есть partitioning что свидетельствует о зрелости системы и об Enterprise-ready. Единственное что может быть не очень - это некий кумулятивный эффект от частых inserts/updates который требует вакуума. И со счетчиками транзакций там есть нюанс. Но скорее всего в твоём сегменте разработки PHP/Laravel - тебе будет просто безразлично сущестование вакуума.

MySQL это лейбл под которым на самом деле могут работать различные engines таблиц. И если анализировать какой-то performance-инцедент то нужно в первую очередь спрашивать с какой опцией таблица создавалась. MyISAM/Innodb/e.t.c. Потому что выбор этого двигателя влиял на какие-то опции скорости и транзакций. Я заменял например в создающих скриптах InnoDb на MyISAM для того чтобы просто быстрее прогрузить 1Тб CSV файл.

В более современных версиях типа MariaDb (я уже не следил за этими новостями) есть более умные двигатели которые учитывают дефекты старых и по идее они должны быть универсальнее. Тоесть можно их брать смело.

Что лично меня раздражает в диалекте My/SQL - так это странного вида кавычки-апострофы. Никогда не понимал зачем это.

Если честно у меня - путаница. Трекеры и клиенты - это одни и те-же сущности?

Kafka - хорошая штука но она любит грамотный дизайн топиков. Какой здесь будет маппинг? Если клиентов - 100 мильонов то вряд-ли кафка выдержит столько-же топиков. Если топик делать один на все события - то нужно как-то партицировать по признакам. По каким?

Вобщем мало информации. Нужны диаграммы и цифры. Без них такого решения как кафка - нельзя принимать. Иначе это будет просто... безответственно. Тоесть мы посоветовали кафку а дальше - бейся сам как хочешь.