Как выбрать между хеш-таблицей и Trie (префиксным деревом)?

Так что, если мне придется выбирать между хеш-таблицей или деревом префиксов, каковы различающие факторы, которые заставили бы меня выбрать один из других. С моей наивной точки зрения кажется, что использование trie имеет некоторые дополнительные издержки, поскольку оно не хранится в виде массива, но что с точки зрения времени выполнения (при условии, что самый длинный ключ - самое длинное английское слово), это может быть по существу O (1) (по отношению к верхней границе). Может быть, самое длинное английское слово состоит из 50 символов?

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

Может ли кто-нибудь дать мне более опытный взгляд на это? Спасибо!

Преимущества попыток:

Основы:

• Предсказуемое время поиска O (k), где k - размер ключа
• Поиск может занять меньше k времени, если его там нет
• Поддерживает упорядоченный обход
• Нет необходимости в хэш-функции
• Удаление просто

Новые операции:

• Вы можете быстро искать префиксы ключей, перечислять все записи с заданным префиксом и т. Д.

Преимущества связанной структуры:

• Если существует много общих префиксов, пространство, которое им требуется, используется совместно.
• Неизменные попытки могут разделить структуру. Вместо обновления дерева на месте, вы можете построить новый, отличающийся только на одной ветви, в другом месте, указывая на старое дерево. Это может быть полезно для параллелизма, нескольких одновременных версий таблицы и т. Д.
• Неизменяемое дерево сжимаемо. То есть, он может разделять структуру суффиксов , используя хэш-символы.

Преимущества хеш-таблиц:

• Все знают хеш-таблицы, верно? Ваша система уже будет иметь хорошую, хорошо оптимизированную реализацию, более быструю, чем попытки для большинства целей.
• Ваши ключи не должны иметь какой-либо специальной структуры.
• Более компактный, чем очевидная связанная структура дерева ( см. Комментарии ниже )

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

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

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

Очень хорошим примером, когда Trie лучше соответствует требованиям, является промежуточное программное обеспечение для обмена сообщениями. У вас есть миллион подписчиков и издателей сообщений разных категорий (в терминах JMS - темы или обмены), в таких случаях, если вы хотите отфильтровать сообщения по темам (которые на самом деле являются строками), вам определенно не нужно создавать хеш-таблицу за миллион подписок с миллионами тем. Лучшим подходом является сохранение тем в три файла, поэтому, когда фильтрация выполняется на основе совпадения тем, ее сложность не зависит от количества тем / подписок / издателей (зависит только от длины строки). Мне это нравится, потому что вы можете проявлять творческий подход с этой структурой данных, чтобы оптимизировать требования к пространству и, следовательно, уменьшить количество кэш-памяти

Используйте дерево:

1. Если вам нужна функция автозаполнения
2. Найдите все слова, начинающиеся с «а» или «топор» и так далее.
3. Дерево суффиксов - это особая форма дерева. Суффикс-деревья имеют целый ряд преимуществ, которые хеш не может охватить.

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

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

Вставка и поиск по дереву линейны с длиной входной строки O (s).

Хеш даст вам O (1) для поиска и вставки, но сначала вы должны вычислить хеш на основе входной строки, которая снова равна O (s).

Заключение, асимптотическая сложность по времени линейна в обоих случаях.

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

Чтобы разорвать связь, задайте себе вопрос: мне нужно искать только полные слова? Или мне нужно вернуть все слова, соответствующие префиксу? (Как и в системе интеллектуального ввода текста). Для первого случая перейдите к хешу. Это более простой и понятный код. Проще протестировать и поддерживать. Для более продуманного варианта использования, где префиксы или суффиксы имеют значение, попробуйте еще раз.

И если вы сделаете это просто для удовольствия, реализация trie будет полезным в воскресенье днем.

Реализация HashTable экономит место по сравнению с базовой реализацией Trie . Но со строками упорядочивание необходимо в большинстве практических приложений. Но HashTable полностью нарушает лексографический порядок. Теперь, если ваше приложение выполняет операции, основанные на лексографическом порядке (например, частичный поиск, все строки с заданным префиксом, все слова в отсортированном порядке), вы должны использовать Tries. Только для поиска следует использовать HashTable (поскольку, возможно, он дает минимальное время поиска).

PS: кроме них, троичные поисковые деревья (TSTs) были бы отличным выбором. Его время поиска больше, чем у HashTable, но экономит время во всех других операциях. Кроме того, это более эффективное пространство, чем пытается.

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