Какие аргументы у одной таблицы ивентов вместо 4 разных на

каждый тип ивента?

Ситуация такая, что заказчик хочет разбить одну таблицу ивентов на 4 разных, по виду ивента. Данных там и так не очень много (несколько ГБ в день), и я ищу вот аргументы против этого разделения, может кто может подсказать что-то дельное на эту тему? Или может я вообще не прав и стоит разделять на таблички с дельтой в 100мб

Колоночная СУБД И у этих эвентов половина+ колонок имеют одни и теже данные (всякое о пользователе например) Тогда если правильно отсортировать, повторяющиеся данные о пользователе будут нормально сжаты

А зачем искать аргументы против? Это вроде как нормальный подход делить разные данные на разные таблицы

так а смысл от бигдаты тут вообще?

Нет, несколько гб это не биг дата

смысл хранения все в однйо таблице имеет смысл когда у нас события могут динамически добавляться и схема их тоже может менятсья динамически. И даже есть такой тип “моделирования” https://github.com/ActivitySchema/ActivitySchema

А как будет менее больно жить?

ну это хороший вопрос, видимо мне проще с одной, аналитикам проще с 4

так сделай одной и четыре вьюхи

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

У нас, например, все эвенты из мобильного приложения в сыром виде сыпятся в одну таблицу кликхауса. Большая часть полей у событий общая. Индивидуальные значения хранятся в отдельной колонке json. На следующем слое dwh уже как душе угодно - под задачи конкретного анализа. Если какой-то тип события имеет индивидуальный способ последующей обработки/обогащения, то выделяем его в отдельную таблицу.