Влияет ли размер строки на скорость запроса выбора в MySQL?
В настоящее время я разрабатываю структуру моей базы данных. Планируется создать огромную таблицу (назовем ее таблицей кликов) с сотнями миллионов строк. На многие ее столбцы будут ссылаться с помощью внешнего ключа в других таблицах, чтобы уменьшить размер этой огромной таблицы и сократить время запроса.
В этих других «справочных таблицах» я планирую хранить большую часть данных о кликах. Поэтому, когда я просматриваю таблицу кликов, я просто присоединяюсь к нескольким из этих справочных таблиц, чтобы получить то, что я хочу знать о кликах.
1-й вопрос: Является ли это хорошей практикой с точки зрения скорости — если я собираюсь сделать много выборов на этой огромной таблице кликов позже?
Эти меньшие справочные таблицы будут иметь несколько тысяч строк, в основном по 1 столбцу с типом строки. Эти строки будут где-то между 5-50 символов.
Что я планирую сделать, так это то, что при щелчке я проверю эти небольшие таблицы, если такое же значение уже существует или нет, а если нет, то я их вставлю.
Это потребует SELECT.
2-й вопрос: Лучше ли выполнять поиск по самой строке и индексировать ее, или я должен иметь другой столбец с результатом MD5 строки и вместо этого искать строку MD5 (с индексом)? Другими словами, влияет ли размер строки на длину поиска строки в простом выборе?
Я планирую сделать SELECTs, как это:
SELECT id FROM table1 WHERE string = $string
Есть ли лучший способ достичь любого из вышеперечисленного?
Решение
Ваш дизайн звучит хорошо. Требуется вторичный индекс для строки в каждой из справочных таблиц.
Ваше описание неясно, выполняете ли вы этот «клик» за раз или в пакетном режиме.
Я бы порекомендовал пакетный подход для этой операции, если у вас нет острой необходимости в данных в реальном времени. Если вам нужны данные в режиме реального времени, я бы предпочел использовать метод потоковой передачи, при котором новые данные добавляются путем вставки в существующие таблицы, а не с обновлениями.
Если вы обновляете миллионы строк каждый день индивидуально, то операции блокировки во время пиковой обработки могут быть дорогостоящими. Если таблица используется для аналитики или создания отчетов, загрузка запросов из этой обработки также может помешать обновлениям.
Другие решения
Если вы их хешируете, то, вероятно, сам хеш будет длиннее, чем строки, которые вы хэшируете, что делает его контрпродуктивным. Вы захотите хешировать для вещей, которые постоянно больше и часто на порядок или более. Например, строка JSON размером 7 КБ является хорошим кандидатом. Вычисление хэша и поиск его в индексе будет быстрее, чем сравнение строк в индексе.
Что вам нужно сделать, так это создать прототип, заполнить его представительным объемом данных и посмотреть, как он работает. Ваша база данных должна быть настроена для обработки вашей рабочей нагрузки, а ваша схема должна быть доведена до критического уровня, чтобы вы знали, сколько данных вы можете обработать, прежде чем ваш подход ослабнет.
Может быть, этот переломный момент составляет 100 миллионов записей. Может быть, это 50 миллиардов. Никто не знает, как это будет работать на вашем оборудовании, и только вы можете узнать, протестировав.
detector