theunknown: То есть конкретно интересует логическая составляющая поиска
- как должен ходить бот, находя на странице новые ссылки(переходить на них сразу, либо искать не был ли он там ранее)
Всё, что может делаться в пакетном режиме, должно делаться в пакетном режиме. Сначала сервером-краулером запрашиваются страницы. Они складываются на спец. сервер для их разбора - сервер-парсер. На сервере-парсере эти страницы разбираются на части, включая список URL и тексты. Список URL отдаётся на сервер, управляющий краулером. Дальше ссылки могут просто складываться в базу для сервера-краулера, а могут складываться лишь те, которых в базе ещё нет. Зависит от реализации. Далее сервер-парсер берёт ещё не обойдённые URL и скачивает страницы с них, складывая на сервер-парсер. И так далее.
theunknown: - в каком виде хранить информацию (то есть именно построение наиболее оптимальной файловой структуры)
Для поиска - своя база данных. Для URL - можно MySQL или обычные текстовые файлы.
theunknown: - как обрабатывать накопленную информацию, дабы максимально оптимизировать её для выдачи
Для этого есть отдельный сервер, который строит индекс по всем словам в текстах (сервер-индексатор). По этому-то индексу и происходит поиск на сервере-поисковике.
theunknown: Прежде всего интересует сама методика ссылочного ранжирования, не в смысле определения авторитетности ресурса, а в смысле логического и физического представления модели связей между интернет-ресусами(то есть что на что ссылается). Самое простое логическое представление, которое приходит в голову это обычная матрица.
Второй вариант это хранение в базе пар отрезков с идентификаторами страниц "кто ссылается" - "на кого ссылается". По этим парам уже можно считать и число ссылок со страницы и число ссылок на страницу. Все пары можно держать в памяти. Иногда в памяти десятков серверов - по 250 млн. пар на сервер. Для 4 млрд. страниц это всего около тысячи серверов. Либо держать данные на быстрых жёстких дисках, но скорость будет значительно более медленной.
zexis: А как называются люди, которые отдают деньги в сомнительные проекты, не имея не каких гарантий, кроме сказок заемщика, и не имея ни каких эффективных рычагов давления на него?
У меня свои арендованные сервера. Дальше будете рассказывать про свою практику?
Brim.ru: что большинство владельцев сайтов предпочитает дешевые тарифные планы несмотря на имеющиеся на них ограничения, платить за дедик там где аналогичный по функционалу PHP-сайт работает на виртуальном хостинге, никто не хочет и я понимаю владельцев сайтов, которые не хотят хостить "гостевую книгу" на VPS из-за того что урод программист сэкономил свое время и написал сайт на JSF или использовал еще какие-то "мутные" технологии.
Это для хостинга не "урод программист", а "кормилец программист" - он заставляет пользователей покупать более дорогие и прибыльные для хостера тарифные планы. Если юзеру нужен дешёвый тарифный план - пусть ищет иной движок. Или допиливает имеющийся и оптимизирует его (сам или платит специалисту).
Brim.ru: Как правило фреймворки облегчающие разработку сайтов изолируют программиста от знания деталей и приучают его к "птичьему" языку.
Это палка о двух концах. Новичок будет клепать требовательные к железу сайты и откровенное УГ. Опытный же хорошо оплачиваемый программист будет разрабатывать достаточно производительные сайты значительно быстрее, чем он делал бы без фреймворка. В узких местах можно допилить на чём-то более быстром, чем фреймворк.
Кроме того, никто не мешает лично Вам использовать Вашу парадигму и писать скрипты на С, а данные держать в собственной базе хранимой в памяти (с копией на диске). Работать будет намного быстрее PHP. Правда вылавливать ошибки памяти будете долго, но ведь выдерживание нагрузки на P4 под 5-10 тыс. запросов в секунду того стоит?
Сервер стоит как зарплата хорошего программиста за две недели. Плюс его можно взять в лизинг или заложить.
Brim.ru: и как правило иллюстрирует слабые знания программиста в web-разработке (не зная специфики web-программирования используют фреймворки как костыли которые решают тривиальные для опытного web-разработчика задачи). Извините за офтоп.
Иногда использование фреймворка хорошо. Чем меньше строк кода и чем более он понятен, тем меньше там ошибок. При том, что программист обязан знать, что реально лежит под фреймворком и должен уметь всё написать без него и, более того, уметь использовать свои знания подноготной (языка, железа, базы данных и т.д.) для правильного использования фреймворка.
Умели раньше кино делать.
И сейчас умеют. Но не окупится. Капитализьм...
А расходы на содержание этого форума кто нибудь может прикинуть?
(Сервер, трафик....)
360 тыс. просмотров, т.е. 5 страниц в секунду? Какой трафик? Какой сервер? Да тут точно VDS 😂
То есть конкретно интересует логическая составляющая поиска
- как должен ходить бот, находя на странице новые ссылки(переходить на них сразу, либо искать не был ли он там ранее)
Всё, что может делаться в пакетном режиме, должно делаться в пакетном режиме. Сначала сервером-краулером запрашиваются страницы. Они складываются на спец. сервер для их разбора - сервер-парсер. На сервере-парсере эти страницы разбираются на части, включая список URL и тексты. Список URL отдаётся на сервер, управляющий краулером. Дальше ссылки могут просто складываться в базу для сервера-краулера, а могут складываться лишь те, которых в базе ещё нет. Зависит от реализации. Далее сервер-парсер берёт ещё не обойдённые URL и скачивает страницы с них, складывая на сервер-парсер. И так далее.
- в каком виде хранить информацию (то есть именно построение наиболее оптимальной файловой структуры)
Для поиска - своя база данных. Для URL - можно MySQL или обычные текстовые файлы.
- как обрабатывать накопленную информацию, дабы максимально оптимизировать её для выдачи
Для этого есть отдельный сервер, который строит индекс по всем словам в текстах (сервер-индексатор). По этому-то индексу и происходит поиск на сервере-поисковике.
Прежде всего интересует сама методика ссылочного ранжирования, не в смысле определения авторитетности ресурса, а в смысле логического и физического представления модели связей между интернет-ресусами(то есть что на что ссылается). Самое простое логическое представление, которое приходит в голову это обычная матрица.
Второй вариант это хранение в базе пар отрезков с идентификаторами страниц "кто ссылается" - "на кого ссылается". По этим парам уже можно считать и число ссылок со страницы и число ссылок на страницу. Все пары можно держать в памяти. Иногда в памяти десятков серверов - по 250 млн. пар на сервер. Для 4 млрд. страниц это всего около тысячи серверов. Либо держать данные на быстрых жёстких дисках, но скорость будет значительно более медленной.
А как называются люди, которые отдают деньги в сомнительные проекты, не имея не каких гарантий, кроме сказок заемщика, и не имея ни каких эффективных рычагов давления на него?
Венчурные инвесторы?
10 новых Гуглов
Ага ... "Вечный зов"
Жесть... С Зикамом поведёшься, у него и наберёшься...
"Мастеру" ... Гелла ... вообще был там какой-то ад.
А нужен был рай? У Воланда?
- наша практика показывает
У меня свои арендованные сервера. Дальше будете рассказывать про свою практику?
что большинство владельцев сайтов предпочитает дешевые тарифные планы несмотря на имеющиеся на них ограничения, платить за дедик там где аналогичный по функционалу PHP-сайт работает на виртуальном хостинге, никто не хочет и я понимаю владельцев сайтов, которые не хотят хостить "гостевую книгу" на VPS из-за того что урод программист сэкономил свое время и написал сайт на JSF или использовал еще какие-то "мутные" технологии.
Это для хостинга не "урод программист", а "кормилец программист" - он заставляет пользователей покупать более дорогие и прибыльные для хостера тарифные планы. Если юзеру нужен дешёвый тарифный план - пусть ищет иной движок. Или допиливает имеющийся и оптимизирует его (сам или платит специалисту).
Как правило фреймворки облегчающие разработку сайтов изолируют программиста от знания деталей и приучают его к "птичьему" языку.
Это палка о двух концах. Новичок будет клепать требовательные к железу сайты и откровенное УГ. Опытный же хорошо оплачиваемый программист будет разрабатывать достаточно производительные сайты значительно быстрее, чем он делал бы без фреймворка. В узких местах можно допилить на чём-то более быстром, чем фреймворк.
Кроме того, никто не мешает лично Вам использовать Вашу парадигму и писать скрипты на С, а данные держать в собственной базе хранимой в памяти (с копией на диске). Работать будет намного быстрее PHP. Правда вылавливать ошибки памяти будете долго, но ведь выдерживание нагрузки на P4 под 5-10 тыс. запросов в секунду того стоит?
получаются "тяжелые" сайты
Сервер стоит как зарплата хорошего программиста за две недели. Плюс его можно взять в лизинг или заложить.
и как правило иллюстрирует слабые знания программиста в web-разработке (не зная специфики web-программирования используют фреймворки как костыли которые решают тривиальные для опытного web-разработчика задачи). Извините за офтоп.
Иногда использование фреймворка хорошо. Чем меньше строк кода и чем более он понятен, тем меньше там ошибок. При том, что программист обязан знать, что реально лежит под фреймворком и должен уметь всё написать без него и, более того, уметь использовать свои знания подноготной (языка, железа, базы данных и т.д.) для правильного использования фреймворка.
Так Вам
качественный платный сервис ведущих специалистов в этой сфере.
или
которые возьмут раз в десять дешевле
?
какой прогноз на этот месяц? в чем лучше держать деньги ~ середины июня?
Половина в рублях, вторая половина - 45% в евро и 55% в баксах.