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

От url считать хешь, хешь с PR кидать в отдельную таблицу. В итоге будет поиск по таблице с постоянной шириной полей ;)

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

наличие первого прохода (операции над host) в данной задачке не критично, но фишка в том, что эти операции у меня в любом случае производятся (для других целей), так почему бы и нет? Меньше вероятность совпадений опять же 😂

TimeBomb добавил 27.05.2009 в 13:53

Посмотрел. Классика в общем.

Однако мысль появилась такая: если взять вариант с файловой системой там есть один бонус - можно моментально получать (значение из файла)/(ошибку если файл не существует) если пользовать при обращении полный путь (вот та перевернутая конструкция из первого поста). логика будет элементарная - тупо на if exist

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

TimeBomb, а как быть с параметрами гет у ссылок?)) или так и создавать файлы в файл системе с гигансткими именами?

А вы думаете БД работает без файлов? Создаете одну таблицу, вешаете на урл INDEX, и он сам делает дерево (Б-Дерево если точнее), только на урл ограничение длины придется делать. А еще с учетом отстутствия повторений это не очень разумно. Для ускорения вывода (жертвуя скоростю формирования ессно) можно добавить второе поле где хранить только хост сайта, и вот на него повесить индекс (длина то ограничена железно). Я вам гарантирую что даже для 50 миллионов записей выборка select url,pr from pr_table where host='forum.searchengines.ru' будет работать доли секунды. Коль данные обновляться будут редко, табличку MyISAM (если муська) и индекс. Ну места правда много будет жрать, да. А кеш запросов у муськи и так есть. Я бы правда предпочел постгрю

Конечная реализация конечно зависит от того, какие данные должны выводиться и в каком соотношении.

Вот тут товарищ так и сделал ;) http://www.phpclasses.org/browse/package/2682.html

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

Раздули из мухи слона...

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

Темболее что это в любом случае повлияет на вставку, а не на выборку!

Я бы не использовал МД5 из за того, что он медленный и длинный, есть более короткие альтернативы.

И так нужно:

1) БД: id, hash, url, pr

2) Кеш в общей памяти с часто используемыми данными.

это ВСЕ!

и какая альтернатива для 10 клн записей чтобы значения хеша не пересеклись? просто интересно.

а зачем им не пересекаться? пусть пересекаются, после пересечения их отсеять по url.

ведь MD5 тоже допускает пересечение, следовательно всеравно придется делать комбинированный индекс с url

ну я могу предоложить что мд5 даст разброс побольше, чем какой нить срс32

да но для поиска значения по ключу крк 32 надо 32 шага, а по мд5 128.