Производительность SQL при поиске длинных строк

Мне нужно хранить строки пользовательского агента в базе данных для отслеживания и сравнения поведения клиентов и показателей продаж в разных браузерах. Довольно простая строка пользовательского агента имеет длину около 100 символов. Было решено использовать varchar (1024) для хранения данных агента пользователя в базе данных. (Я знаю, что это перебор, но идея такова; предполагается, что в нем будут размещаться данные агента пользователя на долгие годы, а некоторые устройства, панели инструментов и приложения уже имеют длину 500 символов.) Таблица, содержащая эти строки, будет нормализована (для каждого отдельного пользователя строка агента будет сохранена только один раз) и будет обрабатываться как кеш, поэтому нам не придется интерпретировать пользовательские агенты снова и снова.

Типичный вариант использования:

• Пользователь заходит на наш сайт, определяется как новый посетитель
• Для этого пользователя создается новая информация о сеансе
• Определите, нужно ли нам анализировать строку пользовательского агента или если у нас есть достоверный анализ для этого файла
• Если он у нас есть, отлично, если нет, проанализируйте его (в настоящее время мы планируем вызвать сторонний API)
• Сохраните соответствующую информацию (имя браузера, версия, os и т. д.) в объединенной таблице связали информацию о существующем сеансе пользователя и указали на запись в кеше

Примечание: У меня есть тенденция говорить «поиск» строки пользовательского агента в базе данных, потому что это не просто Погляди.Но для ясности: в запросах будут использоваться операторы '=', а не регулярные выражения или синтаксис LIKE%.

Таким образом, скорость поиска строки пользовательского агента имеет первостепенное значение. Я изучил несколько методов, чтобы убедиться, что он будет иметь хорошую производительность. Индексирование всего столбца прямо из соображений размера. Частичный индекс - не такая уж хорошая идея, потому что большинство пользовательских агентов имеют отличительную информацию в конце; частичный индекс должен быть достаточно длинным, чтобы он имел смысл, к тому моменту, когда его размер вызывает проблемы.

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

Хеширование до целочисленного значения обеспечит лучшую производительность при риске более высоких коллизий. Я ожидаю увидеть самое большее тысячи или десятки тысяч пользовательских агентов; даже 100000 пользовательских агентов достаточно хорошо впишутся в целое число размером 2 ^ 32 с очень небольшим количеством конфликтов, которые могут быть расшифрованы веб-сервисом с минимальным влиянием на производительность. Даже если вы думаете, что целочисленный хеш - не такая уж хорошая идея, использование дайджеста из 32 символов (например, SHA-1, MD5) должно быть намного быстрее для выборок, чем необработанная строка, верно?

Моя база данных - это движок MySQL InnoDB .Сначала веб-код будет поступать с C #, а позже - с php (после того, как мы объединим часть хостинга и аутентификации) (не то чтобы веб-код имел большое значение).

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

• Какой хэш вы бы использовали для этого приложения?
• Вы бы вычислили хеш в коде или позволили бы базе данных обрабатывать его?
• Есть ли радикально другой подход для хранения / поиска длинных строк в база данных?