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

Сколько страниц? А вообще - не важно. Вам нужен memcached.

берешь бд.

в ней

url = varchar(1000);

hash = 32.

при рассчете вставляешь url = полный юрл без изменений, а hash = md5($url);

при поиске = select * from .. where hash=md5($needurl);

ну и если больше одного, то

select * from .. where url=$_GET and ID in ($hashIDs - результаты прошлого запроса)

дальше сами

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

1.не хранить адских имен файлов (ваше url = varchar(1000)) ;)

2.немножко обезопаситься от всякого рода инъекций и т.п. - чем делать кастрацию инъекций - проще сделать 1 раз md5 и не париться - время выполнения будет такое же

Но вот все равно, не лежит у меня душа к БД... что-то мне подсказывает что деревья - лучше будут. Может быть есть красивые решения хранения деревьев в БД?

Слава Шевцов, спасибо, буду курить. С первого взгляда - немного не то, (позволит ли хостер/нужно отдельный сервак, насколько быстро/медленно работает библиотека в рhp/perl/java/т.д.). Кроме того, это именно кеш (пользуем Ram серванта) - т.е. отдача наиболее часто требуемых данных, а я об этом собираюсь думать далее. Сейчас в приоритетах - именно структура хранения данных. Самое главное что мне понравилось в том что нашел про memcached - это то, что она сама по себе является некоей хеш-таблицей. Чувствую, надо хорошенько разобраться как она это делает. Спасибо за наводку!

мемкеш не подойдет по простой причине которую не назвал слава - перезагрузка и пока всем вашим данным в нем. мемкеш - обычный хештейбл в ОПЕРАТИВНОЙ памяти сервера. ПРИЧОМ если данные не влазят, то он будет выбрасывать из памяти те, которые непопулярны.

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

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

пр для любой ссылки будет искаться за абсолютный 0.

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

bearman, спасибо еще раз, становится все интереснее и интереснее....

Слава не назвал эту причину, но я уже разобрался ;)

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

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

Вот не уверен что за абсолютный 0 все - таки... Может завтра с утра и поставлю пару экспериментов. Мне все-таки кажется (ой, что-то мне много всякого кажется😂) что можно для этой конкретной задачи придумать схему хранения с более быстрым откликом.

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

еще пришла идея

2 таблицы - в одной первичный ключ - md5(url);

во второй - pr,md5,url,md5_id

на извлечение запрос вида

select * from results inner join(select id from md5table where hash=md5($url)) as `a` on results.md5id = `a`.id where results.url = $url.

в чем же скорость - в том, что используется select id from md5table where hash=md5($url), которая при примари кее по колонке хеш - будет возварщать ЛЮБУЮ строку за абсюлютный 0. - получаем мд5id, который ищем в таблице которая имеет индексом колонку мд5хеш. по инт11 тоже поиск будет происходить моментально.

поверьте, попробуйте - сгенерите таблицу на 5 млн записей и попробуйте выбирать из нее таким макаром. должно работать моментально, а как второй эшалон мемкеш кненчо нормально, н если сервер - один, я бы посоветовал попробовать поюзать apc cache, ибо скорость у него побыстрее изза убранной затраты времени на "соединение по сети/linuxсокету с мемкеш"

bearman, так подзапрос тут и не нужен

Беда с md5 в том, что такие индексы слишком случайны. При последовательном сканировании сайта вы получите массу операций на запись в разные участки диска. Но про запись в условии ничего не сказано. Математику-теоретику можно игнорировать такие вещи :)

Инженер-практик (который даже не сомневается, что сканирование сайта должно быть последовательным, ведь он помнит про HTTP/1.1) разбил бы поля на Host и что-там-осталось от url, и сделал бы составной индекс по двум хешам. Можно даже по первым нескольким байтам хеша Host. В этом случае последовательное сканирование сайта вызывало бы запись индекса хоть как то локализованную.

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

и что интересно : простой индекс по строке URL в myisam может оказаться лучше из-за того что он упакован. То есть в индексе не хранится все строка, а только разница.

Так что пробуйте все варианты.

netwind, кстати да, можно хеш от хоста + хешь от всего урла, такое то врядли совпадет)) и использовать эту хрень как примари кей.

Деревья в БД - google://MPTT

Для вас ИМХО - host + page и индекс по обеим полям решит проблему

На host + page разделить догадался, у меня этот разбор для других целей использовался, теперь и тут пригодится. У меня там еще и id-шки уникальные хостам в базе выданы - я прикидывал что страниц будет адски много, а вот хостов - все таки счетное количество.

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

Кстати, а может быть кто-то видел в сети документ по устройству Google датацентров?