2016-02-22 3 views
0

Я работаю над системой базы данных, где находится один мастер bd & таблица и много подчиненных, а также для продажи необходимо синхронизировать свои данные с мастером.Строка MySQL Хеширование

Некоторые моменты об этом соглашении: 1) slave db (S) будет время от времени автономно работать, поэтому, когда они снова встанут, служба «синхронизирует» их. (Итак, нет репликации) 2) Я не могу изменить master db, так что не триггеры. (представьте себе, что мастер db не принадлежит мне) 3) Синхронизация произойдет в сервисе, и скорость не важна. 4) Нет большого количества данных, поэтому я мог бы даже ходить по каждой строке. 5) Данные в строках сильно варьируются: от varchar (3) до varchar (500)

Я оглядывался и нашел Md5() - это я считал отличным, потому что тогда я мог просто CONCACT() значения строк и сравнение строк и строк. Проблема, которую я обнаружил, заключалась в том, что CONCAT (AND GROUP_CONCAT) немного ограничивает, поскольку он имеет ограничение на характер.

Каков наилучший способ получить «строку» CHECKSUM или HASH?

CHECKSUM ROW WHERE id = 1 будет здорово ... что ближе всего к этому?

UPDATE: мне удалось добраться до этого "SELECT @@ group_concat_max_len;" возвращает max (4294967295). Но этот код все еще не работает:

SELECT id, MD5(GROUP_CONCAT(MD5(`id`), ...many columns here... ,MD5(`col30`))) AS 'md5Hash' FROM company_table GROUP BY id; 

Он по-прежнему работает только на нескольких столбцах.

+1

Вы можете увеличить лимит символов для 'group_concat' с помощью переменной' group_concat_max_len', эффективно сделав ее такой же большой, как ваша система будет максимально поддерживать. – bishop

+0

Если это услуга, вы можете обрабатывать все внутри службы и запускать хэш на возвращаемых результатах, которые вы объединяете в код, если вы не можете установить 'group_concat_max_len', как было предложено епископом. Как вы сказали, скорость не вызывает беспокойства, и это принесет вам желаемые результаты. –

+0

Учитывая ваши требования и ограничения, хеширование с помощью MD5 (GROUP_CONCAT (..))) кажется мне разумным. В частности, см. [Этот ответ] (http://stackoverflow.com/a/26733784/2908724). Решение уровня кода, предлагаемое в качестве @FrankJ, может в конечном итоге стать наилучшим подходом, поскольку оно будет более гибким, чем линейный уровень базы данных. – bishop

ответ

0

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

Так что получается что-то вроде этого:

SELECT id, MD5(CONCAT(IF(col1,CRC32(col1),CRC32('')), ... ,IF(col20,CRC32(col20),CRC32('')))) AS 'md5has' FROM table 

в результате наименьшее количество строки в Concat, поскольку CRC32 может производить только до значения 10 цифр (4294967295), так что даже если CONCAT или group_concat max - 1024, мы можем создать 10-значный CRC, тогда мы можем хэш-строку с 102 столбцами за один проход.

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

Маленькая талия, но все же лучше, чем хеширование на стороне клиента ... сохранение IO по-прежнему массивно, и кроме того, кто делает таблицы с 102 столбцами ?!

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