Эффективное хранение внешнего индекса строк - PullRequest
2 голосов
/ 03 ноября 2009

Скажем, у вас есть большая коллекция с n объектами на диске , и у каждого есть строка переменного размера. Каковы общие практики эффективных способов составления индекса этих объектов с простым сравнением строк. Хранение целых строк в индексе было бы непомерно длинным в зависимости от размера и ввода-вывода, но поскольку диски имеют большую задержку, хранение только ссылок также не является хорошей идеей.

Я думал об использовании B-Tree-like дизайна с пытается , но не могу найти ни одной реализации базы данных с использованием этого подхода. На самом деле, трудно понять, как крупные базы данных реализуют индексы для строк (это, вероятно, теряется в огромных результатах для информации уровня SQL).

ТИА!

РЕДАКТИРОВАТЬ: изменение заголовка с «Эффективная внешняя сортировка и поиск хранимых объектов с большими строками» на «Эффективное хранение внешнего индекса строк».

Ответы [ 3 ]

4 голосов
/ 03 ноября 2009

Здесь может быть полезно «префикс B-дерево» или «простой префикс B-дерево».

«Простой префикс B-дерево» немного проще, просто хранится самый короткий префикс, который разделяет два элемента, без попытки устранить избыточность в этих префиксах (например, для «астрономии» и «азимута», он будет хранить просто « как 'и' az ', но не пытайтесь избежать дублирования' a ').

«Префикс B-дерева» близок к тому, что вы описали - что-то вроде дерева, но в структуре B-дерева, чтобы дать хорошие характеристики при хранении в основном на диске. Тем не менее, он предназначен для удаления (большей части) избыточности внутри префиксов, образующих индекс.

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

Что касается реального использования, то основные СУБД и СУБД-подобные системы используют все вышеперечисленное. Варианты B-дерева, вероятно, наиболее распространены на рынке СУБД общего назначения (например, Oracle или MS SQL Server). Расширяемое хеширование используется в значительном количестве более специализированных продуктов (например, Lotus Domino Server).

0 голосов
/ 03 ноября 2009

Начните с ясного понимания, чего вы хотите. Вы хотите отсортировать или проиндексировать их? Сортировка, вероятно, потребует перемещения по крайней мере некоторых элементов на диске, но индексация, скорее всего, оставит их там, где они есть.

Если вы действительно хотите их отсортировать, Кнута, «Искусство компьютерного программирования» , третий том посвящен сортировке и поиску примерно столько деталей, сколько вы, вероятно, захотите.

0 голосов
/ 03 ноября 2009

Что вы делаете с объектами?

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

СУБД также имеют кэширование и различные другие функции, которые могут сделать вашу жизнь проще.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...