на строковом ключе н...я скорость это фантастика, также как и на 64 байтном ключе.
хранить естественно в оперативной памяти иначе смысла кеша нет никакого.
выборка из СУБД никогда не сравниться по скорости с выборкой из правильно построенного кеша.
Зависит от реализации кеша приложения, я бы делал дерево, без использования стандартных хештаблиц. А вэтом случае налицие ключа фиксированной длинны и имеющегося в базе очень положительно скажется на производительности.
1) получили запрос на ПР для url
2) проверили дерево на надичие hash(url)
3) не нашли в дереве, берем из бызы выбюорку по hesh(url)
4) втыкаем результат выборки в дерево
а делать кеш с ключем в виде строки это равнозначно моментальному выстрелу в висок.
ваш опус мне тоже понравился, осбенно про закрытое хеширование, ну покрайней мере я никогда такого не слышал и очень сильно сомневаюсь в реальности данного заявления.
далее никто не предлагал хранить хеш ключи как строки, это был бы верх идеотизма на мой взгляд.
далее наличие хешей значительно облегчит построение кеша в приложении.
гопнеги на улицах достали так еще и в сеть лезут, тьфу...
думается после этого поста, 99% потенциальных клиентов даже не поинтересуются товаром.
что значит глупо? это бинарные деревья и поиск с 32х битным ключом будет всегда значительна быстрее поиска с 128 битным.
да но для поиска значения по ключу крк 32 надо 32 шага, а по мд5 128.
а зачем им не пересекаться? пусть пересекаются, после пересечения их отсеять по url.
ведь MD5 тоже допускает пересечение, следовательно всеравно придется делать комбинированный индекс с url
Раздули из мухи слона...
Дробление путей, оно не нужно, если нет задачи делать выборку всех страниц хоста например, все выкладки про вроде как разнесенную запись, это бред ибо для составных индексов вы получите тожесамое, причем трижды, первый раз будите пистаь в индекс хоста, второй в индекс страницы, третий в комбинированный.
Темболее что это в любом случае повлияет на вставку, а не на выборку!
Я бы не использовал МД5 из за того, что он медленный и длинный, есть более короткие альтернативы.
И так нужно:
1) БД: id, hash, url, pr
2) Кеш в общей памяти с часто используемыми данными.
это ВСЕ!
