- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Маркетинг для шоколадной фабрики. На 34% выше средний чек
Через устранение узких мест
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Необходимо определиться со структурой хранения данных.
Кто сможет помочь?
Если уж совсем подробно, то хранить предполагается кеш Google PageRank.
Задачка такая:
Забирать PR страниц с датацентров можно не спеша (не попадая под бан по IP), а вот отдавать его придется быстро-быстро, поэтому нужно кешировать (даже не кешировать, а хранить) полученные данные. Поскольку подобный "кеш" будет валидным до следующего пересчета PR то это уже наверное и не кеш, а именно хранение.
Хранить PR нужно для каждой страницы каждого сайта (подразумевается очень много). :)
Вопрос состоит в том, какой принцип организации данных выбрать для того чтобы максимально быстро забирать данные?
Чувствую, что хранить в БД будет хуже чем например создавать дерево прямо в файловой системе и записывать/считывать PR страницы в/из файла типа /ru/searchengines/forum/forumdisplay.php?f=60 (для любимой тут ветки "апдейты Яндекса", имеющей PR4)
(ее URL: /ru/forum/search-engines/yandex);)
Может кто-нибудь подведет под мои подозрения математическую базу, или делал подобное, в общем посоветуйте!
Сколько страниц? А вообще - не важно. Вам нужен 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 - это то, что она сама по себе является некоей хеш-таблицей. Чувствую, надо хорошенько разобраться как она это делает. Спасибо за наводку!
bearman, идея абсолютно ясна, "дальше сам" - могу, чай инженер-математик. Пользовать хеши я в любом случае собирался, правда в привязке к файлам, чтобы:
1.не хранить адских имен файлов (ваше url = varchar(1000)) ;)
2.немножко обезопаситься от всякого рода инъекций и т.п. - чем делать кастрацию инъекций - проще сделать 1 раз md5 и не париться - время выполнения будет такое же
Но вот все равно, не лежит у меня душа к БД... что-то мне подсказывает что деревья - лучше будут. Может быть есть красивые решения хранения деревьев в БД?
Слава Шевцов, спасибо, буду курить. С первого взгляда - немного не то, (позволит ли хостер/нужно отдельный сервак, насколько быстро/медленно работает библиотека в рhp/perl/java/т.д.). Кроме того, это именно кеш (пользуем Ram серванта) - т.е. отдача наиболее часто требуемых данных, а я об этом собираюсь думать далее. Сейчас в приоритетах - именно структура хранения данных. Самое главное что мне понравилось в том что нашел про memcached - это то, что она сама по себе является некоей хеш-таблицей. Чувствую, надо хорошенько разобраться как она это делает. Спасибо за наводку!
мемкеш не подойдет по простой причине которую не назвал слава - перезагрузка и пока всем вашим данным в нем. мемкеш - обычный хештейбл в ОПЕРАТИВНОЙ памяти сервера. ПРИЧОМ если данные не влазят, то он будет выбрасывать из памяти те, которые непопулярны.
можешь мой метод, только хранить в файлах, я просто тебе это не предложил, но это тоже вариант, который я отказал по причине того, что будет ппц тяжело это удалять/переносить. Но если будешь делать на файлах, то тебе надо использовать вложенность папок, дабы не создавать нагрузку на файлсистему, которая может в один прекрасный момент крашнуться и пока все данные.
бд. если расставить индексы в моем варианте правильно, то по 3-30 млн записей таблице у тебя
пр для любой ссылки будет искаться за абсолютный 0.
еще как вариант можешь использовать sphinx. может приглянется :) правда он чуток для другого, но и для этой цели думаю может подойти. но с ним у тебя будут неокторые неудобства о окторых я промолчу(намек - ребилд базы надо делать чтобы поиск выдача менялась).
bearman, спасибо еще раз, становится все интереснее и интереснее....
мемкеш не подойдет по простой причине которую не назвал слава - перезагрузка и пока всем вашим данным в нем. мемкеш - обычный хештейбл в ОПЕРАТИВНОЙ памяти сервера.
Слава не назвал эту причину, но я уже разобрался ;)
В любом случае, для моей задачи скорее всего потребуется "второй эшелон", для которого memcached будет как нельзя кстати.
тебе надо использовать вложенность папок, дабы не создавать нагрузку на файлсистему, которая может в один прекрасный момент крашнуться и пока все данные.
Вариант описанный мной, (подредактировал первый пост - добавил урл для понимания его раскладки по файловой системе) вроде бы подразумевал вложенность папок... Или мы о разных вещах вещах говорим? Или я чего-то про файлы не знаю? Вы если что - про подводные камни не молчите. ;)
бд. если расставить индексы в моем варианте правильно, то по 3-30 млн записей таблице у тебя
пр для любой ссылки будет искаться за абсолютный 0.
Вот не уверен что за абсолютный 0 все - таки... Может завтра с утра и поставлю пару экспериментов. Мне все-таки кажется (ой, что-то мне много всякого кажется😂) что можно для этой конкретной задачи придумать схему хранения с более быстрым откликом.
еще как вариант можешь использовать sphinx. может приглянется правда он чуток для другого, но и для этой цели думаю может подойти. но с ним у тебя будут неокторые неудобства о окторых я промолчу(намек - ребилд базы надо делать чтобы поиск выдача менялась).
Про 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 и индекс по обеим полям решит проблему
netwind, кстати да, можно хеш от хоста + хешь от всего урла, такое то врядли совпадет))
Для вас ИМХО - host + page и индекс по обеим полям решит проблему
На host + page разделить догадался, у меня этот разбор для других целей использовался, теперь и тут пригодится. У меня там еще и id-шки уникальные хостам в базе выданы - я прикидывал что страниц будет адски много, а вот хостов - все таки счетное количество.
TimeBomb добавил 27.05.2009 в 13:32
Кстати, а может быть кто-то видел в сети документ по устройству Google датацентров?