Блог

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

Для некоторых таблиц данных у нас есть столбцы, содержащие десятичные значения (например, тип данных DECIMAL (18,1)). Если я посмотрю, что хэши md5 генерируются для одного целого числа, одного текста и одного десятичного столбца, я бы ожидал, что эти три строки имеют разные хэши, сгенерированные в потоках данных Azure:

Однако эти три строки получают один и тот же хэш, что означает, что мы не можем обнаружить изменение в поле [значение] для записей с [id] = 1 . Если десятичные значения хранятся в базе данных в виде текста (или преобразуются в строку в функции md5), хэши отличаются:

Это привело к тому, что некоторые из наших таблиц истории не вели точную запись данных, в которых изменилось только значение в десятичном столбце.

Мой вопрос: кто-нибудь знает, разработано ли это «специально» для потоков данных Azure или это ошибка, которую необходимо исправить Microsoft?

Обновление: это уже было исправлено в прошлом году, и производительность достаточно приличная, чтобы прекратить использование toString

Да, это сделано специально, и в то же время это ошибка.

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

После примерно 1 часа обсуждения Microsoft мы выяснили, что:

• значения с плавающей запятой не затрагиваются
• это влияет на типы данных, которые определяют точность и масштаб
• поведение md5 и последнее — округление его до целого числа и применение к нему md5.

MD5 вернет то же самое для этих значений:

• 0
• 0.1
• 0.4

То же самое поведение для значений ниже:

• 0.5
• 0.6
• 1

Для:

• 0.4
• 0.9
• 1.5
• 2.5

Мне сказали, что исправление прогнозируется на февраль.

Если вы не используете функции столбцов, такие как me (byNames), вы можете умножить свое значение на степень основания 10 с масштабом в качестве экспоненты.

Это будет быстрее, чем toString .