Redshift: характеристики плоских столов в сравнении с размерами и фактами - PullRequest
0 голосов
/ 11 мая 2018

Я пытаюсь создать размерную модель на плоских таблицах OLTP (не в 3NF).

Есть люди, которые думают, что таблица размерной модели не требуется, потому что большинство данных для отчета представляют собой единую таблицу.Но эта таблица содержит более 300 столбцов.Должен ли я разделить плоский стол на измерения и факты или просто использовать плоские таблицы непосредственно в отчетах.

Ответы [ 2 ]

0 голосов
/ 12 мая 2018

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

Теги вопроса указывают, что вы используете Amazon Redshift, и ответ для этой базы данных отличается от традиционных реляционных баз данных, таких как SQL Server и Oracle.

Во-первых, вам необходимо понять, чем Redshift отличается от обычных реляционных баз данных:

1) Это Massively Parallel Обработка (MPP) система, которая состоит из одного или нескольких узлов, которыеданные распределяются по всему, и каждый узел обычно выполняет часть работы, необходимую для ответа на каждый запрос.В связи с тем, что способ, которым данные распределяются по узлам, становится важным, цель обычно состоит в том, чтобы данные распределялись достаточно равномерно, чтобы каждый узел выполнял примерно одинаковое количество работы для каждого запроса.

2) Данныехранится в столбчатом формате .Это полностью отличается от строкового формата SQL Server или Oracle.В столбчатой ​​базе данных данные хранятся таким образом, что делает запросы с большими типами агрегации намного более эффективными.Этот тип хранения частично сводит на нет причину использования таблиц измерений, поскольку хранение повторяющихся данных (атрибутов) в строках является относительно эффективным.

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

Поэтому при принятии решения о создании измерений необходимо подумать о том,это на самом деле принесет много пользы.Если в данных есть столбцы, которые регулярно обновляются, то лучше поместить их в другую таблицу меньшего размера, чем в одну большую таблицу.Однако, если данные в основном только для добавления (без изменений), тогда нет никакой пользы в создании измерений.Запросы, объединяющие и объединяющие данные, будут эффективными для одной таблицы.

СОЕДИНЕНИЯ могут стать очень дорогими в Redshift, если только обе таблицы не распределены по одному значению (например, идентификатору пользователя) - если они не Redshift, придется физически копировать данные вокруг узлов, чтобы иметь возможность запуститьзапрос.Таким образом, если у вас должны быть измерения, то вы захотите распределить таблицу наибольшего размера по тому же ключу, что и таблица фактов (помня, что каждая таблица может быть распределена только по одному столбцу), тогда может потребоваться распределение любых других измерений.как ВСЕ (копируется в каждый узел).

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

0 голосов
/ 11 мая 2018

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

  • Запрашивать проще
  • Это позволяет избежать соединений, которые могут быть запутанными и подвержены ошибкам для причинных пользователей
  • Запросы выполняются быстрее (особенно для систем хранилищ данных, которые используют столбчатое хранилище данных )

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

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

Отличным примером многих столбцов является наличие флагов, облегчающих написание предложений WHERE, таких как WHERE customer_is_active, вместо необходимости присоединяться к другой таблице.и выяснить, использовали ли они услугу за последние 30 дней.Эти столбцы нужно будет пересчитывать ежедневно, но они очень удобны для запроса данных.

Итог: Вы должны поставить простоту использования * на 1031 * выше производительности при использовании хранилищ данных,Затем выясните, как оптимизировать доступ с помощью системы хранилищ данных, такой как Amazon Redshift, которая предназначена для очень эффективной обработки данных этого типа.

...