Быстрый алгоритм/структура данных, обеспечивающая линейную компоновку?

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

Data list:
    0: { "somekey", somevalue }
    1: { "someotherkey", someothervalue }
    ...
    n: { "justanotherkey", justanothervalue }

Я разработал такую ​​систему, чтобы при поиске ключа его индекс можно было кэшировать, а затем получить к нему доступ с постоянным временем. Теперь, поскольку у меня нет возможности предсказать порядок или объем данных, и я не могу их отсортировать, мне нужны идеи об алгоритмах или структурах данных, которые были бы лучше, чем просто линейный поиск, но при этом сохраняли бы ограничения. мне нравится.

У кого-нибудь есть идеи? Сомневаюсь, что смогу сильно его ускорить, но каждая мелочь помогает, так как это будет ядром моей системы. Заранее спасибо!

==EDIT==

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

struct Entry {
    /* Key is actually a complex struct itself with string, and params */
    Key key;
    Data* data; 
}

person Miguel    schedule 03.02.2012    source источник
comment
Зачем нужно кэшировать индекс? Смысл хеш-таблиц в том, чтобы предоставить вам O(1) доступ по ключу.   -  person Mike Dunlavey    schedule 03.02.2012
comment
@MikeDunlavey Ключ довольно сложный (это будет строка произвольной длины и массив настроек. Несколько ключей могут иметь одну и ту же строку, но отличаться настройками.) В этом случае, что было бы хорошим хэшем без коллизий Алгоритм таблицы, который можно использовать?   -  person Miguel    schedule 03.02.2012
comment
Ну, я бы просто взял этот большой длинный ключ и смешал его во что-то короткое (например, взял 32- или 64-битную контрольную сумму или, может быть, дайджест сообщения), или, может быть, просто преобразовал его в длинную строку битов, или длинная строка. Все, что хочет хэш-функция. Это не должно быть слишком дорого с точки зрения циклов по сравнению с циклами, необходимыми для запуска хэша, и в зависимости от того, сколько раз в секунду вам нужно это делать.   -  person Mike Dunlavey    schedule 03.02.2012
comment
... если вы сделаете это, а не кэшируете индексы в таблице, хэш-карта не должна быть без коллизий.   -  person Mike Dunlavey    schedule 03.02.2012


Ответы (2)


Одним из вариантов может быть использование комбинации хеш-таблицы и динамического массива. Идея заключается в следующем: всякий раз, когда вы вставляете элемент в структуру данных, вы добавляете его в динамический массив, затем вставляете ключ в хэш-таблицу, связанную с индексом в динамическом массиве, в котором находится пара ключ/значение. Таким образом, для поиска по индексу вы можете просто просмотреть динамический массив, а для поиска по имени вы ищете индекс в хэш-таблице, а затем запрашиваете этот индекс. Это занимает ожидаемое время O (1) для вставки, удаления и доступа, что намного быстрее, чем линейный поиск.

Надеюсь это поможет!

person templatetypedef    schedule 03.02.2012
comment
Я не думаю, что это сработает для меня, так как я не могу отделить ключ от данных. См. правки к вопросу, пожалуйста :) - person Miguel; 03.02.2012
comment
@athlon32- Я не уверен, что понимаю, почему это не сработает. Если ваш массив содержит ключ и значение, а хеш-таблица просто хранит ключ, почему эта структура данных не работает? - person templatetypedef; 03.02.2012
comment
Что ж, это будет работать, но может быть немного излишним, если у меня, скажем, тысячи записей, и хотя я мог бы просто сохранить указатели на ключ, это все равно было бы немного больше, чем мне хотелось бы. :/Тем не менее, я не ожидаю получить гораздо больше от этого вопроса, поэтому мне, вероятно, придется использовать этот метод... - person Miguel; 03.02.2012
comment
@ athlon32- Накладные расходы на самом деле не так уж велики по сравнению с производительностью, которую вы получаете. Вы будете использовать примерно в 2 раза больше исходной памяти для хранения хеш-таблицы, а выигрыш в производительности будет только увеличиваться по мере увеличения количества записей. - person templatetypedef; 03.02.2012
comment
Вам не нужно отделять ключ от данных. Если вы реализуете хеш-функцию для своего ключа, вы можете сохранить свой хэш-индекс в форме (hash_value->list_index) для минимальных накладных расходов. - person comingstorm; 03.02.2012

Как насчет ключа хеш-таблицы -> индекс в массиве?

person Marcin    schedule 03.02.2012