mysql 7columns pk против уникального ограничения md5 на 1 столбец

У меня очень большая таблица, которая в настоящее время составляет около 70 миллионов строк и растет ежедневно тысячами, эта схема теперь опрокидывается каждый день, поэтому я перехожу к секционированной таблице и переделываю ddl.

таблица в основном представляет собой набор NOT NULL INTEGERS (некоторые средние, некоторые INT некоторые крошечные), которые должны иметь уникальное ограничение для набора из 7 столбцов (в таблице больше столбцов), это очень дорого для вычисления для каждой вставки и увеличивается размер индексного файла намного больше, так как я никогда не извлекаю его, я бы предпочел отказаться от него и каким-то образом md5 /, возможно, просто конкатенировать значения ... пока не знаю.

проблема в том, что единственный тип столбца, который может содержать такое большое уникальное число, - это varchar, я сомневаюсь, будет ли этот PK на самом деле лучше? все так, поскольку у меня будет ПЕРВИЧНЫЙ КЛЮЧ 'part_key' (site_id, id), мне придется принять уникальное ограничение при проектировании раздела, чтобы подвести итог ... я уверен, что это не новая проблема, но я не был не удалось найти какие-либо тесты / документы, сравнивающие их, есть ли у кого-нибудь опыт решения этой проблемы? вопрос действительно, должен ли PK быть целыми 8 полями (имейте в виду, что эта таблица, вероятно, будет иметь более 100M строк), когда я никогда не получаю с помощью pk или просто хешированного значения уникальных полей PS: получение в основном сделано двумя из 7 столбцов. Размер диска не является проблемой, спасибо.


mysql indexing unique varchar
person Amnon    schedule 14.10.2009    source источник

Ответы (2)


arrow_upward
0
arrow_downward

пока mysql не получит сокращение разделов, я предлагаю (gulp) денормализовать ваши таблицы до фальшивого разделения. сделайте что-то вроде того, что взяли по модулю 32 вашего первого значения и составили 32 таблицы.

обновление: очевидно, что mysql 5.1.6 и более поздние версии поддерживают сокращение (http://dev.mysql.com/doc/refman/5.1/en/partitioning-pruning.html), поэтому мой более сильный совет - обновить, а затем разрешить mysql обрабатывать разделы для вы, возможно, используя хеш-значение одного из ваших 7 столбцов.

person longneck    schedule 14.10.2009

arrow_upward
0
arrow_downward

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

Я застрял на MySQL 5.0. Мне нужно вручную разбить несколько таблиц на 40 миллионов строк. У меня есть идентификатор документа, который я могу использовать в своем приложении: floor(docID/10)%100. Это может дать мне 100 разделов, и это должно значительно уменьшить размер индекса. Я сделал запрос по таблице и подсчитал количество строк по хешу:

select count(docID), floor(docID/10)%100 as partno
from documents 
group by partno

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

Если вы можете воспользоваться преимуществами разделения MySQL, это будет более мощным и меньшим влиянием на ваше приложение.

person memnoch_proxy    schedule 05.11.2009