2009-11-12 6 views
2

Мы начинаем загружать хранилище данных с данными из журналов событий. У нас есть нормальная звездная схема, где строка в таблице фактов представляет одно событие. Наши таблицы измерений представляют собой типичное сочетание USER_AGENT, IP реферала, страница, и т.д. Один размера таблицы выглядит следующим образом:DataOverhouse duplicate rows rows

create table referal_dim(
    id integer, 
    domain varchar(255), 
    subdomain varchar(255), 
    page_name varchar(4096), 
    query_string varchar(4096) 
    path varchar(4096) 
) 

Где мы автоматическая генерация идентификатора, чтобы в конечном итоге присоединиться к таблице фактов. Мой вопрос: какой лучший способ идентифицировать дубликаты записей в нашем процессе массовой загрузки? Мы загружаем все записи для файла журнала в таблицы temp, прежде чем делать фактическую вставку в постоянное хранилище, однако идентификатор просто автоматически увеличивается, поэтому две идентичные записи с двумя днями будут иметь разные идентификаторы. Будет ли целесообразно создавать хэш столбцов значений, а затем попытаться сравнить на этом? Кажется, что попытка сравнения на каждом столбце значения будет медленным. Есть ли какая-либо передовая практика для такой ситуации?

+0

Какая платформа вы используете, sql-сервер? Oracle? MySql? Версия? – chadhoc

+1

Он использует Vertica, но я считаю, что он спрашивает, как нормализовать входящие данные в его таблицу измерений, сохраняя ссылку в таблицах фактов. Если он выполняет поиск по каждой строке, чтобы узнать, существует ли измерение для данного факта, тогда, когда вы попадаете в миллионы строк, он будет очень медленным. Хеширование столбцов для создания первичного ключа может быть жизнеспособным решением, но вам нужно тогда беспокоиться о парадоксальности дня и возможных столкновениях. –

ответ

5

Целое число с автоматическим приращением для суррогатного ПК в порядке, но (по словам г-на Кимбалла) таблица измерений также должна иметь естественный ключ. Таким образом, столбец хеша NaturalKey будет в порядке, также может быть столбец Status для «текущего» или «истекшего» может использоваться для использования SCD типа 2.

+0

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

+0

Чтобы повысить производительность загрузки, вы можете поддерживать (воссоздавать после каждой загрузки) таблицу соответствия ключей для такого размера (NaturalKey, PrKey), которое соответствует естественным клавишам с последним первичным ключом для таблицы. Во время загрузки добавьте хэш-столбец к вашим записям, а не просмотрите первичный ключ из KeyMatchingTable. Если не найдено, значит, это новая запись, так что создавайте те, которые используются для вставок. Если он найден, значит, он уже существует, поэтому решите, что делать (отменить, SC1 или SC2). Затем загрузите таблицу размеров. –

 Смежные вопросы

  • Нет связанных вопросов^_^