Ограничения использования binary_checksum () для представления URL или аналогичной строки?

Question

У меня действительно огромный журнал. (миллионы строк)

LogTable
-------
ID    
DATE   
BASEURL
QUERYSTRING
USER   
REFERRER  
USERAGENT
SERVER

Я хочу уменьшить эту таблицу путем нормализации данных. (уменьшите размер)

Я знаю! Я знаю! Журнал должен быть супер-быстрой вставкой. С другой стороны, таблица журнала настолько велика, что план обслуживания становится ужасным. Поэтому меня интересуют только повторяющиеся столбцы, такие как BASEURL, USER, SERVER и USERAGENT.

Теперь я знаю, что ведение журнала должно быть быстрым, поэтому я не хочу сравнивать строки, что приводит к моему вопросу:

Могу ли я рассчитывать на хранение

binary_checksum(COLUMN_VALUE) 

в LogTable и сохранить сопоставление COLUMN_VALUE с его контрольной суммой в отдельной таблице?

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

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

Вот простой запрос, например:

select 
   count(1)
,  [user] /* This is a checksum value, which I can lookup in my cache */
from
   LogTable
where date between @from and @to
group by [user]

Что ты думаешь? Это контрольная сумма подходит?

Редактировать

• Все мои столбцы varchar (2000) или меньше.
• Я бы предположил, что это также позволяет мне быстрее индексировать данные? (Я бы проиндексировал автономную / трансформационную копию)

Answer 1

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

Например, USERAGENT является основным кандидатом для измерения (возможно, в виде снежинки), заменяя вашу длинную строку суррогатным целым числом.

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

Answer 2

Какова ваша стратегия коллизий хешей? Контрольная сумма, которая приводит к 32-разрядному дайджесту, имеет вероятность столкновения 50% только после 65 тыс. Записей. Это из-за столкновений Встреча в середине . Для миллионов строк у вас будет очень высокая вероятность коллизии хеша.