Хранение кеша PageRank - структура данных?

думаю что в бд не все так глупо)))

что значит глупо? это бинарные деревья и поиск с 32х битным ключом будет всегда значительна быстрее поиска с 128 битным.

А если вместо CRC32 использовать в качестве хэш-функции длину URL, то получится еще быстрее? 🚬

тогда на миллион урлов вы получите МАКСИМУМ 1000 разных значений хеша, и это уже не хеш, а откровенное гавно.

вы пытаетесь выиграть на операции инсерта (~0.0001 с. = md5 в худшем случае), но потом использовать дополнительный (select, который в лучшем случае 0.0001 с. будет выполняться) каждую выборку. вы не видите в этом глупость? я вижу. либо я вас недопонимаю :)

Меньше. Скорее всего порядка 500, за счет ограничений на длину URL. Эт я к тому написал, что уменьшение размера ключа не всегда означает увеличение скорости поиска конечного листа дерева (конкретного URL).

короче хватит сочинять. два хеша и 99.999% уникальность этой записи дана вам

Вот это опус. во первых бинарных деревьев там нет и никогда не было - это самая объемистая из всех древовидных структур. Почти все известные мне субд используют Б-деревья, глубина которых значительно меньше (нет, неправильно, вот так - ЗНАЧИИИИИТЕЛЬНО меньше). Кроме того, эти хеши никому нахрен не уперлись, когда над полем висит индекс. СУБД автоматически генерирует к индексному дереву еще и закрытое хеширование и сама использует хеш-доступ. Ваши текстовые поля ей только мешать будут. Вообще говоря, делать два уникальных поля в одной таблице - это высшая степень фимоза головного мозга. Вы думаете Primary key просто так называется праймари? Поиск по числу то еще быстрее чем по текстовому ключу, ага? ;)

bearman, ну тебя то куда понесло, а? =)

ЗЫ. Когда вижу этот ник, всегда вспоминаю сауспарк : "It's Manbearpig. Half a man, half a bear and half a pig".

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

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

далее наличие хешей значительно облегчит построение кеша в приложении.

MySQL опенсорсный, карты вам в руки =)

Зачем вводить хеши в базе для "кеша" в приложении? В базе есть PK, этого достаточно. А имена файлов с кешем - эт хоть обхешируйся, хотя тоже непонятно назначение. Можно применять и менее дорогостоящие функции - урл сам по себе уникален.

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

1) получили запрос на ПР для url

2) проверили дерево на надичие hash(url)

3) не нашли в дереве, берем из бызы выбюорку по hesh(url)

4) втыкаем результат выборки в дерево

а делать кеш с ключем в виде строки это равнозначно моментальному выстрелу в висок.