Каким будет наиболее эффективный тип индекса и механизм таблиц для поиска в md5?

Question

У меня есть таблица, которая содержит несколько столбцов, и один из них - хеш md5, который является уникальным ключом в таблице.

Каким будет наиболее эффективный механизм и тип индекса (hash / b-tree) для определения того, существует ли уже хеш в таблице или нет? Я ожидаю иметь миллиарды строк на 200 разделах (mysql5.1)

Сейчас у меня есть myisam с уникальным индексом btree в этом столбце хэша, однако меня беспокоит постоянная перебалансировка b-дерева со случайными хэшами, вставляемыми постоянно.

псевдокод:

if hash not in table:
  process
else:
  skip, record already exists

Answer 1

хорошо хэши md5 имеют 128-битный двоичный файл.Обычно их записывают в шестнадцатеричном формате из 32 цифр.поэтому переход к любому полю char и сохранение шестнадцатеричной строки в шестнадцатеричном формате (например, char 32) будет просто глупым, только простым.Вы могли бы пойти на два комбинированных bigint 64 без знака, что было бы хорошо, если бы вам нужна была какая-то сортировка - чего вы не делаете.Таким образом, победителем является: двоичный (16) ... который ровно 128 и именно то, что вам нужно.

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

Я бы больше беспокоился о ядре базы данных.myisam обычно работает быстрее, потому что ему не хватает определенных функций, которые есть в innodb (например, откат ...), но он имеет только блокировку таблицы.inndbo может блокировать строки, и если у вас много обновлений и записей, возможно, он будет работать лучше.

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

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

Все, что заканчивается на 00, отправляется на сервер 1, 01-> сервер 2, 10-> 3,11-> 4 и т. Д. (Используйте для этого арифметику по модулю, она самая быстрая!) И т. Д. ... если вы сейчас проверяете хэш md5 в базе данных, вы точно знаете, какой сервер искать, и наоборот, где его хранить!затем вы можете разделить свои базы данных на столько серверов, сколько захотите, вам даже не нужно больше их реплицировать, и таким образом вы устраняете любые узкие места ...

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

Answer 2

1. Вы беспокоитесь о перебалансировке индекса BTree, это означает, что у вас частые вставки или обновления, поэтому вам следует избегать MyISAM (из-за блокировки на уровне таблицы).

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