Один большой и широкий стол или много не очень большой для статистических данных

Question

Я пишу простую аналитическую систему для своей компании. У меня есть около 100 различных типов событий, которые должны собираться на десятки проектов. Нас не интересуют кросс-проектные аналитические запросы, но события имеют похожие типы по всем проектам. Я использую PostgreSQL в качестве основного хранилища для этой системы. Теперь я должен решить, какая архитектура более предпочтительна.

Первая архитектура является один очень большой стол (в терминах строк подсчитывать) в проект, который содержит данные для всех типов событий. Это будет около 20 или более столбцов, многие из которых будут иметь значение NULL. Может быть, будет использоваться разделение, чтобы разбить эту таблицу по типу события, но таблица все еще будет настолько широкой.

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

Я собираюсь получить аналитические данные из этих таблиц, используя разные запросы на присоединение (само объединение в случае первой архитектуры). Какой из них предпочтительнее и где их ловушки?

UPD. Все события имеют около 10 общих атрибутов. А атрибуты остаются разными от одного типа событий к другому.

Answer 1

В прошлом у меня были подобные ситуации. С postgres у вас есть множество вариантов. В зависимости от того, как ваши данные вводятся в систему (все одновременно/немного за раз) и объем ваших данных для каждого проекта (сотни точек данных против миллионов точек данных) и шаблон запроса (IE, запрос после все данные, запросы в ночное время или отчеты постоянно работают), есть много вариантов. Еще один фактор будет заключаться в том, что новые типы проектов (с новыми типами данных) могут возникнуть.

Во-первых, в вашей «первой архитектуре» первый вопрос, который возникает для меня, - это все «точки данных» одного и того же типа данных (или, по крайней мере, очень похожие). Являются ли некоторые текстовые и другие цифры? Некоторые цифры и другие плавают? Если это так, вы, вероятно, столкнетесь с проблемами при свертывании данных без создания столбца или таблицы для каждого типа данных. Если все ваши данные совпадают с типом данных, то указанная вами первая архитектура может работать очень хорошо.

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

Третья архитектура, о которой вы не упоминали, состоит в том, чтобы иметь комбинацию 1 и 2. В основном есть 1 таблица для хранения 10 общих атрибутов и использование 1 или 2 для хранения дополнительных атрибутов. Это будет иметь преимущество, особенно если дополнительные данные не были часто использованы или были нечисловыми.

И, наконец, вы можете использовать один из типов данных типа «хранилище документов» PostgreSQL. Вы можете сохранить эту информацию в массивах, hstores или json. Теперь это будет довольно неэффективно, если вы выполняете тонну агрегатных функций, так как вы можете рассчитывать агрегаты за пределами Pgsql или, как минимум, на выполнение неэффективного запроса. Вы можете сохранить 10 обычных полей в обычных полях, а дополнительные - как hstore или json.

Я не спрашивал вас, но было бы хорошо знать, что если каждое событие в проекте имеет более 1 точки данных (IE вы регистрируете изменения или просто обновляете данные).Если ваша общая таблица имеет менее 100 000 строк, скорее всего, лучше всего сосредоточиться на том, что проще в обслуживании и программе, а не на производительности, поскольку небольшие объемы данных довольно быстро, независимо от того, как они хранятся.