Разработка таблицы фактов в хранилище данных SQL Azure - PullRequest
Новая
       42

Разработка таблицы фактов в хранилище данных SQL Azure

0 голосов
/ 06 марта 2019

Что является лучшим дизайном индекса и распределения для сравнительно небольших таблиц фактов (в среднем 30 миллионов строк на таблицу). Структура каждой таблицы похожа на следующую: 

CREATE TABLE FactTable (
    TimeDimensionID INT NOT NULL,
    DimensionID1 VARCHAR (10) NOT NULL,
    DimensionID2 VARCHAR (10) NOT NULL,
    DimensionID3 VARCHAR (10) NOT NULL,
    DimensionID4 VARCHAR (10) NOT NULL,
    Measure1 INT,
    Measure2 FLOAT,
    Measure3 DECIMAL (10.2),
    Measure4 DECIMAL (10,2)
)

Объединение TimeDimensionID, DimensionID1, DimensionID2, DimensionID3 и DimensionID4 уникально в таблице фактов. В настоящее время у нас есть кластерный и уникальный первичный ключ в 5 полях.

  • Как лучше всего выполнить индексацию и распространение для переноса этих таблиц в хранилище данных SQL Azure? Мы думаем об использовании CLUSTERED INDEX (DimensionID1, DimensionID2, DimensionID3 и DimensionID4) для индекса и распределения хеша с использованием поля TimeDimensionID.
  • КЛАСТЕРНЫЙ ИНДЕКС должен включать поле TimeDimensionID, даже если распределение хеша предназначено для этого поля?
  • Правильно ли это оформление, или мы должны использовать COLUMN STORE INDEX, даже если в действительности таблицы содержат менее 100 миллионов строк?
  • Мы должны рассмотреть возможность использования реплицированных таблиц для таблиц фактов?

1 Ответ

0 голосов
/ 07 марта 2019

Некоторые рекомендации:

  • Если возможно, переместите ваши DimensionID с varchar на int / bigint.Вы получите более высокую производительность, меньше места для хранения и меньшие затраты.
  • Забудьте о кластеризованных индексах на данный момент.
  • Создайте таблицу с хэш-распределением, но не по дате, которая будет перегружать ваши данные.
  • Создайте свою таблицу как индекс кластерного хранилища
  • Не копируйте свою таблицу FACT, а вместо этого копируйте свои РАЗМЕРЫ.
...