DynamicsAxSCM: Avoid index length issues with InventDim

[Blog bot]

Источник: http://blogs.msdn.com/b/dynamicsaxsc...inventdim.aspx
==============

In Microsoft Dynamics AX we use indexes to ensure uniqueness.
An example of this is the DimIdx index in InventDim, where all dimension fields are included to ensure that only a single record exists for a given set of dimensions.

However, the SQL Server has a limitation of 16 fields in an index.
With the first versions of InventDim (which was introduced in Axapta 2.0) this was rarely a problem since only a few dimensions where shipped out-of-the-box.
So partners and customers could still add more dimensions. Over time, numerous dimensions have been added in the standard version and in country specific solutions.
As a result, we are now very close to the 16 field limit. With the Dynamics AX2012 Feature Pack and Russian functionality installed we have 14 fields in the index and more to come in future releases.

We have received an increasing amount of questions about how to get around this issue so we have implemented a solution which allows you to add custom inventory dimensions and still have the uniqueness validated and enforced.

In our investigation of possible solutions we have tried to find a balance between simplicity, maintainability, and performance.
What we found to be the best solution can be described as follows:

- Introduce a new field based on the Sha1HashCode data type.
- Remove some of the least used dimensions from the DimIdx index and add the new field instead. The removed fields must be hashed in the new field during the insertion.
- Calculate the hash and use it in the findDim method when looking for an existing dimension.
- Create a new InventDimIdAllDimensions field in the InventSumDeltaDim table (I guess the name says what it contains) and replace all the dimension fields in the TTSItemCheckDimIdx index with this new field.

This solution will be available in an upcoming release of Microsoft Dynamics AX so if you cannot wait for this release, feel free to be inspired by our findings – hopefully it will also make it easier for you to upgrade your data.




Источник: http://blogs.msdn.com/b/dynamicsaxsc...inventdim.aspx

[sukhanchik]

О! А можно не забыть еще InventDim (ее правда упомянули) и InterCompanyInventDim ? И тогда можно будет с чистой совестью забыть про ограничение по количеству складских аналитик. Оно ж по сути искусственное.

[gl00mie]

Круто... интересно, насколько расчет криптографической хеш-функции тормозит обращение к InventDim? Ее потом, как классы работы с XML, в ядро куда-нить включат для ускорения? Вообще, конечно, занятная идея сделать индекс по хешу

[sukhanchik]

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

[fed]

Надо помнить, что уникальность индекса нужна не только для проверки при вставке, но и для кэширования. То есть - если индекс по полям a,b,c уникален и включено кэширование, то запрос с условием по полям a,b,c будет отработан из кэша. А если индекс неуникален - то кэширование не работает. (За исключением full table cache, видимо).
До 2009ой для кэширования использовался только PrimaryIndex. Начиная с 2009ой - любой уникальный индекс. Причем в первую очередь, это было сделано для повышения производительности InventDim::findDim()...

[sukhanchik]

Цитата:

Сообщение от fed

Надо помнить, что уникальность индекса нужна не только для проверки при вставке, но и для кэширования.

Ну да, тогда в таком ключе - хеш-функция получается наиболее оптимальным вариантом. Спасибо за разъяснения

[Vadik]

Цитата:

Сообщение от gl00mie

Круто... интересно, насколько расчет криптографической хеш-функции тормозит обращение к InventDim? Ее потом, как классы работы с XML, в ядро куда-нить включат для ускорения?

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

Цитата:

Вообще, конечно, занятная идея сделать индекс по хешу

Да техника-то в принципе не новая - главное чтобы продумали как быть в случае если для разных комбинаций аналитик значения хэша все-таки будут периодически генерироваться одинаковые на инсталляциях с миллионами используемых записей в InventDim в пределах одной компании

[gl00mie]

Цитата:

Сообщение от Vadik

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

Так пишут же - SHA1.

Цитата:

Сообщение от Vadik

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

ну а как SQL-сервера при hash-join'ах коллизии разруливают? Видимо, никак.

[fed]

В общем замена индекса по комбинации полей на индекс по хэшу, скорее всего приведет к падению производительности. Если индекс не сделать уникальным - то кэширование перестанет работать. А если сделать - время от времени будет hash collision случаться и запись невозможно будет вставить.

[sukhanchik]

Цитата:

Сообщение от fed

время от времени будет hash collision случаться и запись невозможно будет вставить.

А можно для чайников просветить - почему должны случаться hash collision на разных комбинациях? Или это связано именно с алгоритмом SHA1, допускающего такое поведение?

[fed]

Цитата:

Сообщение от sukhanchik

А можно для чайников просветить - почему должны случаться hash collision на разных комбинациях? Или это связано именно с алгоритмом SHA1, допускающего такое поведение?

Во первых - вероятность hash collision всегда не нулевая. Во вторых - если я правильно помню, SHA1 сжимает 512 бит в 160. То есть коэфициент сжатия порядка 70%. Не бывает таких алгоритмов, которые бы любой поток гарантированно сжимали на 70% с сохранением однозначности.

Кстати посмотрел - в 2012ой, расширенный тип S1HASCODE основан на контейнере. То есть - хранится он будет в поле типа VARBINARY(MAX) (как я понимаю), и я пока не очень понял может ли сиквел по таким полям индексы строить вообще...

[oip]

Цитата:

Сообщение от fed

Во первых - вероятность hash collision всегда не нулевая. Во вторых - если я правильно помню, SHA1 сжимает 512 бит в 160. То есть коэфициент сжатия порядка 70%. Не бывает таких алгоритмов, которые бы любой поток гарантированно сжимали на 70% с сохранением однозначности.

Так ведь у SHA1 такое огромное кол-во различных хэшей, что даже на миллиардах записей вероятность коллизий де-факто равна нулю. Упрощенно вероятность вычислается как в парадоксе дней рождения. Если я правильно посчитал, то для 10^18 записей вероятность коллизии примерно 10^(-13) (по ссылке прямо приведено, что для 10 миллиардов записей в случае 128, а не 160 бит как у SHA1, вероятность хоть одной коллизии равна 10^(-18)). Это если SHA1 совсем рандом. И хотя это не так, Вики говорит, что это не сильно мешает.