Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / OLAP и DWH Новый топик    Ответить
 Hash vs Surrogate keys  [new]
Владимир Штепа
Member

Откуда: Hannover
Сообщений: 5997
Коллеги,

Кто использовал в своих проектах хэш ключи вместо суррогатных ключей, поделитесь впечатлениями, пожалуйста. На сколько садится производительность джойнов и растёт размер базы по сравнению с возможностью грузить одновременно измерения и факты
18 июл 17, 09:05    [20652399]     Ответить | Цитировать Сообщить модератору
 Re: Hash vs Surrogate keys  [new]
Полковник.
Member

Откуда:
Сообщений: 1611
Владимир Штепа
Коллеги,

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


Я использую на проектах с DV 2.0 и ms sql. Ключ MD5 преобразован в char(32) Производительность садится очень сильно особенно на загрузке данных при перестройках индексов. Играл с разными хеш-функциями в т.ч. и не криптографическими, которые можно преобразовать и хранить в bigint, результат тестов разница в два раза по скорости вставки в таблицу. Вставка через left join, соединение источника с целевой таблицей по ключевым полям.

одна из рекомендаций - нельзя использовать кластерный индекс по полю с хеш-ключем

На оракле пока не пробовал.
18 июл 17, 10:50    [20652828]     Ответить | Цитировать Сообщить модератору
 Re: Hash vs Surrogate keys  [new]
Владимир Штепа
Member

Откуда: Hannover
Сообщений: 5997
Полковник.,

меня интересует производительность join при выполнении аналитических запросов а также, если вы строите SSAS куб, то что вы используете в качестве ключей измерения?

У меня создается впечатления, что на хэш ключах можно построить надежный сундук (Vault) но он "чемодан без ручки", так как витрины (StarSchema ROLAP) и кубы на таких ключах будут черепахой, тяжелой и неповоротливой.
18 июл 17, 14:27    [20654164]     Ответить | Цитировать Сообщить модератору
 Re: Hash vs Surrogate keys  [new]
Полковник.
Member

Откуда:
Сообщений: 1611
Владимир Штепа
Полковник.,

меня интересует производительность join при выполнении аналитических запросов а также, если вы строите SSAS куб, то что вы используете в качестве ключей измерения?

У меня создается впечатления, что на хэш ключах можно построить надежный сундук (Vault) но он "чемодан без ручки", так как витрины (StarSchema ROLAP) и кубы на таких ключах будут черепахой, тяжелой и неповоротливой.


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

Рекомендаций не даю, только проверять на конкретном железе на своем объеме данных. Коллега мой бывший в Германии смотрит в сторону мемориоптимайзед таблиц для ускорения DV 2.0, я пробовал, возможно что то делаю не так но грузятся такие таблицы очень долго, отказался.

Линстедт рекомендует MPP архитектуру для виртуализации витрины на DV 2.0, но она стоит как самолет, никто в России на такое не пойдет.
18 июл 17, 15:08    [20654424]     Ответить | Цитировать Сообщить модератору
 Re: Hash vs Surrogate keys  [new]
RioMare
Member

Откуда: EU
Сообщений: 269
Владимир Штепа,
В прямом виде чистый hash очень медленно работает. Немного преобразованный в bigint из SHA1 вроде более-менее ( правда проект был на MOLAP ).
18 июл 17, 15:18    [20654466]     Ответить | Цитировать Сообщить модератору
 Re: Hash vs Surrogate keys  [new]
RioMare
Member

Откуда: EU
Сообщений: 269
Владимир Штепа
возможностью грузить одновременно измерения и факты


Это и была основная проблема : правда грузить надо было не одновременно, а по-отдельности и в разное время : измерения приходили из одной системы, а факты - из 3 и чисто технически факты прийти раньше измерений
18 июл 17, 15:32    [20654524]     Ответить | Цитировать Сообщить модератору
 Re: Hash vs Surrogate keys  [new]
Полковник.
Member

Откуда:
Сообщений: 1611
RioMare,

Длинна ключа MD5 не позволяет его в bigint преобразовать, а другой алгоритм вычисления может давать коллизии.

Я пробовал не криптографические Fowler–Noll–Vo и MurmurHash3 в BIGINT разница по скорости в два раза по сравнению с MD5 в char(32).

Дальше нужно было исследовать на предмет коллизий, но времени не было, проект шел уже полным ходом, на том этапе было поздно что либо переделывать.
18 июл 17, 15:33    [20654528]     Ответить | Цитировать Сообщить модератору
 Re: Hash vs Surrogate keys  [new]
Владимир Штепа
Member

Откуда: Hannover
Сообщений: 5997
Полковник.,

автор
Коллега мой бывший в Германии смотрит в сторону мемориоптимайзед таблиц


Если вы имеете ввиду column store, то на них JOINS при высокой кардинальности работают архимедленно, так как batchmode выполнения запросов вываливается в row mode, со всеми присущими побочными негативами.

Т.е. получается, что ничего, чем можно гордится, на HashKey пока еще не вышло.
18 июл 17, 15:58    [20654654]     Ответить | Цитировать Сообщить модератору
 Re: Hash vs Surrogate keys  [new]
RioMare
Member

Откуда: EU
Сообщений: 269
Полковник.,
MD5 сам по себе даёт коллизии, преобразовывалось SHA1 ( обычный CONVERT(bigint, HASHBYTES(SHA1, compound_key ) )).
Как я понял для MSSQL всё то, что не INT работает медленно или очень медлено, может на ORA по-другому.
18 июл 17, 16:44    [20654847]     Ответить | Цитировать Сообщить модератору
 Re: Hash vs Surrogate keys  [new]
Критик
Member

Откуда: Москва / Калуга
Сообщений: 30752
Блог
Владимир Штепа
грузить одновременно измерения и факты


почему бы и не грузить вместе?
просто для фактов налету формировать необогащенные элементы измерения,
когда справочники приедут - просто дообогатить
18 июл 17, 21:48    [20655656]     Ответить | Цитировать Сообщить модератору
 Re: Hash vs Surrogate keys  [new]
Voyager_lan
Member

Откуда:
Сообщений: 1429
Владимир Штепа,

Если только для OLAP, то указанный CONVERT(bigint, HASHBYTES(SHA1, compound_key ) ) вполне себе устроит. Что вполне актуально для пилотного решения. Если и добавит объем то не более 20%. По скорости на MD SSAS не заметите.
Если же еще SQL adhoc-запросы пулять к ТФ, то не стоит. Всяко медленнее.
B про Tabular думаю стоит упоминуть: bigint вместо int/smallint....Размер имеет значение
19 июл 17, 14:08    [20657681]     Ответить | Цитировать Сообщить модератору
 Re: Hash vs Surrogate keys  [new]
Ivan Durak
Member

Откуда: Minsk!!!
Сообщений: 3247
Критик
Владимир Штепа
грузить одновременно измерения и факты


почему бы и не грузить вместе?
просто для фактов налету формировать необогащенные элементы измерения,
когда справочники приедут - просто дообогатить

ну так все и делают. Может тут пытаются блокировок избегать.
19 июл 17, 17:24    [20658518]     Ответить | Цитировать Сообщить модератору
 Re: Hash vs Surrogate keys  [new]
Юрий Кудрявцев
Member

Откуда: Сидней, Австралия
Сообщений: 755
Владимир Штепа
Полковник.,

автор
Коллега мой бывший в Германии смотрит в сторону мемориоптимайзед таблиц


Если вы имеете ввиду column store, то на них JOINS при высокой кардинальности работают архимедленно, так как batchmode выполнения запросов вываливается в row mode, со всеми присущими побочными негативами.

Т.е. получается, что ничего, чем можно гордится, на HashKey пока еще не вышло.


Проект тут на Vertica со всем этим DV 2.0 на md5 ключах, очень жалко смотреть как хорошая база убивается на этих джойнах, причем данных с одной стороны ~20Tb, с другой стороны всего 20 Тб ) Причем загрузка здесь последовательная (измерения и потом факты), так что смысл вообще потеряли по пути )
Я пока не видел места, где бы md5 сильно помогал бы, не видел места где нельзя было бы "дообогатить" измерения потом. Это надо совсем непрерывный поток иметь без окон, не доводилось пока.
25 июл 17, 03:55    [20671603]     Ответить | Цитировать Сообщить модератору
 Re: Hash vs Surrogate keys  [new]
Полковник.
Member

Откуда:
Сообщений: 1611
Юрий Кудрявцев

Проект тут на Vertica со всем этим DV 2.0 на md5 ключах, очень жалко смотреть как хорошая база убивается на этих джойнах, причем данных с одной стороны ~20Tb, с другой стороны всего 20 Тб ) Причем загрузка здесь последовательная (измерения и потом факты), так что смысл вообще потеряли по пути )
Я пока не видел места, где бы md5 сильно помогал бы, не видел места где нельзя было бы "дообогатить" измерения потом. Это надо совсем непрерывный поток иметь без окон, не доводилось пока.

Я имел некоторый опыт с vertica в т.ч и на DV 2.0. Скажу так эта база для джойнов вообще не предназначена, она для другого. Если хотите джойнов на вертике увеличивайте кол-во узлов и готовьтесь покупать хорошее железо.
Вы пишите про загрузку последовательную загрузку измерений и фактов, вы что то напутали - в DV нет измерений и фактов, или вы про загрузку из DV датамарта? Ну это скорее особенности вашей реализации. Я например в текущем проекте с DV 2.0 измерения вообще не гружу, они виртуальные, гружу только таблицы фактов
25 июл 17, 07:30    [20671702]     Ответить | Цитировать Сообщить модератору
 Re: Hash vs Surrogate keys  [new]
Юрий Кудрявцев
Member

Откуда: Сидней, Австралия
Сообщений: 755
Полковник.
Я имел некоторый опыт с vertica в т.ч и на DV 2.0. Скажу так эта база для джойнов вообще не предназначена, она для другого. Если хотите джойнов на вертике увеличивайте кол-во узлов и готовьтесь покупать хорошее железо.
Вы пишите про загрузку последовательную загрузку измерений и фактов, вы что то напутали - в DV нет измерений и фактов, или вы про загрузку из DV датамарта? Ну это скорее особенности вашей реализации. Я например в текущем проекте с DV 2.0 измерения вообще не гружу, они виртуальные, гружу только таблицы фактов


Спасибо за совет, если можно было бы избавиться от джойнов, избавились бы ) Но, как часто в больших компаниях / проектах, я делаю свой маленький кусок (и там есть pre-joined projections), а караван уже 10 лет идет. К тому же сидит команда поддержки в 20 человек, что они делать будут, если все заработает? )

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

Т.е. вы тоже таблицы фактов из DV пересобираете для репортинга? Оставляя md5 ключи к измерениям? Я до сих пор не вижу ничего такого в md5, что компенсировало бы потери производительности на витринах.
27 июл 17, 02:43    [20678374]     Ответить | Цитировать Сообщить модератору
 Re: Hash vs Surrogate keys  [new]
Полковник.
Member

Откуда:
Сообщений: 1611
Юрий Кудрявцев,

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

Да, грузим звёзды из DV, оставляем суррогатные ключи md5, потери есть но не значительные, и больше потерь на загрузке индексов, чем на чтении.

Вы в Австралии? Там самое сильное комьюнити DV 2.0
27 июл 17, 20:20    [20680936]     Ответить | Цитировать Сообщить модератору
 Re: Hash vs Surrogate keys  [new]
Юрий Кудрявцев
Member

Откуда: Сидней, Австралия
Сообщений: 755
Полковник.
Юрий Кудрявцев,

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


Тут помогают. Но да, в идеале надо грузить простыню уже преджойненную, так лучше всего.



Полковник.
Вы в Австралии? Там самое сильное комьюнити DV 2.0


Да, тут в CommBank DV сам Линдстедт настроил в свое время таких масштабов, что по всему рынку волнами расходится ) Там все навороченно (hadoop + terradata), 200+ человек занимаются.
28 июл 17, 02:18    [20681285]     Ответить | Цитировать Сообщить модератору
Все форумы / OLAP и DWH Ответить