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

Я не пойму, а дерево вы где будете хранить, и зачем.

База и так кеширует запросы, ваш кеш только лишнее место пожрет.

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

хранить естественно в оперативной памяти иначе смысла кеша нет никакого.

выборка из СУБД никогда не сравниться по скорости с выборкой из правильно построенного кеша.

neolord, кеш лучше еще прикрутить.

насчет деревьев в субд я тоже думаю гон.

реальне хорошо - 64байтная страка - сумма хешей хоста и урла. как уникальное или примари делаем и получаем нее**кую скорость

на строковом ключе н...я скорость это фантастика, также как и на 64 байтном ключе.

под кэшем вы оба подразумеваете memcached? Мне кажется это тухляк. Учитывая, сколько там будет данных, придется в озу выгрузить чуть ли не всю бд. Невелика вероятность что юзеры будут все время запрашивать один и тот же сайт. Разве что ЯК закешировать =) Такие вещи (поток и распределение юзеров) надо конечно сразу планировать и делать выводы.

neolord добавил 28.05.2009 в 17:19

и тут вы снова неправы.

Во-первых я думаю берман одумался - два склеенных md5 (хотя это тухляк, когда есть SHA-2 и md6, дающие сразу хеш нужной длины) занимают таки не 64 байта а 32, которые в числовое представление, увы, не засунешь. Ну а хеш 8байтный это слабовато конечно.

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

Хотя это в общем то пофиг. Так все равно никто не делает.

строка какой фиксированной длинны? 512 символов? это только 1Кб для url на запись или две.

да кеш, в мемкешед или подобном.

теперь по поводу кеша, в общем виде это:

16 байт - хеш (МД5)

16 байт - указатели на ветви

8 байт указатель на лист

1 байт ПР

41 байт для записи, т.е. на миллион записей нужно всего 41 мегабайт ОЗУ, с расчетом на то, что случаи наличия листев единичны.

либо вобще листья оставить в БД, тогда еще - 8 байт.

Все описанное верно для нормальных языков программирования, про размеры в ПХП судить не берусь.

да и систему такую я бы писал не на ПХП.

П.С. все это теоритические выкладки, базирующиеся на моем опыте, в котором практически отсутствуют практические знания по работе мускула, надо написать тесты.

вы все теоретизируете, а я обиваю очередной ддос. херня все ваши индексы)))))))))))) не херня - отбить хттп флуд на 5мбитном канале :-D

вбрасываю идею : композитный ключ по перевернутому имени хоста + ресурсу на хосте.

то есть если url http://company.yandex.ru/inside/partners.xml, нужно хранить имя хоста "ur.xednay.ynapmoc" и "inside/partners/xml". такие ключи должны хорошо упаковаться и заполнять дерево с дивной иерархичностью.

я что то совсем смысле не уловил, поясните пожалуйста.

Про упаковку ключей погуглите myisam pack keys.

про преимущества сгруппированного в одной ветке обновления индексов и так должно быть понятно из схемы хранения b-tree.