- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
VK приобрела 70% в структуре компании-разработчика red_mad_robot
Которая участвовала в создании RuStore
Оксана Мамчуева
Back Door Man, нет.
В данном случае используется иная технология. Идет банальное кеширование.
Во время апдейта идет простой обсчет того кто за кем идет, и выведение этой информации в отдельную таблицу. Из которой уже она берется для выдачи на serp.
Плохо и мало рефрешили :)
Дык я тоже не инсайдер, но как у разработчика в прошлом немаленьких БД возникают некоторые решения
Даже если эти поля индексные, то пересчет их сумм на нескольких машинах займет нереально долгое время. Нереальное - в смысле пользователя, который ждет готовый SERP, тут нужны доли секунды.
Алгоритм с дублированием информации имеет два больших минуса:
1. Увеличение объема информации
2. Усложнение алгоритмов пересчета
Но они оба перевешиваются огромным жирным плюсом, который в случае с поисковой системой наиболее важен - быстродействием.
Дисковые массивы дешевеют, а время как всегда дорожает. Не грех и продублировать.
Учитывая Ваш опыт я могу согласиться с предположением, что часть информации может находиться в базе в двух и более экземплярах. Но, конечно, хотелось бы иметь более компетентную информацию или из первоисточников или хотя бы от [бывших] инсайдеров других поисковых систем, как например от Славы Тихонова или Андрея Коваленко.
Хотя 17,4Тб проиндексированной информации + бэкапы + другие службы + [остальное] на 500 серверах...
Порефрешил, подождал, еще порефрешил - не поменялось. Привязка меня как пользователя к конкретной машине кластера не поменялась.
Оно меняется.
Вопрос: как Вы определили, что Ваша привязка не поменялась? Снаружи этого не видно, по урлу тоже. Да и привязка идет не к машине кластера, а к фронтальному веб-серверу, к которому Вас привяжет применяемое в Яндексе устройство балансировки нагрузки Cisco 7200 (может сейчас уже что-то посовременнее стоит - не знаю). Именно эти фронтальные сервера отправляют запросы на поисковые кластеры и осуществляют слияние результатов от Веба и от остальных поисковых источников.
Ну да, а что Вас смущает? Три поля в таблице: id, кто ссылается, на кого ссылается. Просто как две копейки, и работает быстро
На досуге я подумаю над этим вопросом. Но все равно, разростание базы меня смущает...
Имхо, это самый серьезный аргумент. Но и тут может быть своя фишка. При первоначальном запросе "link=" выдается некоторая заранее просчитанная сумма ссылок. Если пользователь тыкает на страницу 2, то идет уже выборка самих ссылок из базы и новым пересчетом их количества (забавно, но без апдейта предыдущего поля).
Здесь имхо дело в другом.
Выдача бэклинков это не столь популярный запрос, чтоб его кэшировать отдельно, хотя может быть я что-то не так понимаю в технологии кеширования Яндекса.
При запросе #link="www.yandex.ru" фронтальные вебсервера направят запрос на кластеры, которые в свою очередь соберут максимально возможное количество бэклинков (с допуском на определенные технические особенности, как неотклик или таймаут сервера). Фронтовики соберут бэки и по определенной последовательности (имхо по порядковым номерам серверов кластеров) выдадут результат с числом ссылок на странице, установленном в Ваших настройках. Если Вы захотите посмотреть вторую страницу результатов - опять фронтовой сервер отправит запросы на кластера с просьбой выдачи. Но тут уже вопрос: как удалить из заново полученной выборки бэков уже показанные? Это будет делать фронтовой сервер, главный метапоисковой сервер на каждом кластере или каждая конечная машина?.. В любом случае - помимо технической возможности неотклика или тауймаута по выборке добавится также возможность таймаута по время фильтра выборки с удалением показанных результатов. Это может стать причиной тренденциально уменьшиющегося количества бэков в зависимости от номера страницы результата выдачи.
С уважением,
Сергей Пасечник
Хотя 17,4Тб проиндексированной информации + бэкапы + другие службы + [остальное] на 500 серверах...
Оно меняется.
А что? Разве 17 Тб информации это так много?
У меня в локальной сети стоит сервер с 4 Тб информации. Конечно, это не БД, большая часть информации из которой постоянно гоняется туда-сюда, но это не так много. Другое дело, что обрабатывать такие большие объемы текста с целью получить из них релевантную выдачу и много чего еще, нужны большие мощности. И 500 серверов - как раз то самое.
Дима, рефрешатся данные :) При том по выдаче (по бэкам не смотрел, ибо нафиг влом) эти рефреши укладываются аккурат в рамках 4х возможных значений :) уже писал достаточно давно на Форуме об этом :)
Вопрос: как Вы определили, что Ваша привязка не поменялась? Снаружи этого не видно, по урлу тоже. Да и привязка идет не к машине кластера, а к фронтальному веб-серверу, к которому Вас привяжет применяемое в Яндексе устройство балансировки нагрузки Cisco 7200 (может сейчас уже что-то посовременнее стоит - не знаю).
Скажем так, "не поменялось" - это предположение, основанное на том, что не поменялась выдача за период наблюдений (около получаса). Если период наблюдений увеличить - начнут примешиваться результаты "быстроробота". Охотно верю, что выдача меняется, но мне почему то не удалось этого увидеть.
Кроме того, не вижу смысла менять привязку. Я где-то встречал указание, что она идет по кукису (пользователь закрепляется за конкретной машиной), но за достоверность этой информации ручаться не буду.
Выдача бэклинков это не столь популярный запрос, чтоб его кэшировать отдельно, хотя может быть я что-то не так понимаю в технологии кеширования Яндекса..[skipped]
Сергей, изложенная Вами схема работы безусловно имеет право на существование. А вот как реально на деле происходит мы, видимо, без сотрудников Яндекса не угадаем :)
Определенное кеширование, все-таки существует, даже для таких редких запросов.
Провел небольшой эксперимент, запрос "link=somesite.ru"
После "прогона" нескольких страниц число ссылающихся сайтов стало неизменным. Открыл другой броузер, стер кукисы, выставил прокси - получил тот же самое количество беклинков. 🚬
Во время апдейта идет простой обсчет того кто за кем идет, и выведение этой информации в отдельную таблицу. Из которой уже она берется для выдачи на serp.
Spectre, с кешированием согласен.
Насчет хранения СЕРПа целиком в таблице - ну никак. :)
Я так думаю, что число запросы к поисковику подчиняются пресловутому "правилу 80/20", т.е. 20% уникальных запросов, покрывают 80% общего числа запросов. Вот эти 20% уместно кешировать, и делать для них СЕРПы прямо при апдейте. А остальные 80% запрашиваются слишком редко.
Провел небольшой эксперимент, запрос "link=somesite.ru"
После "прогона" нескольких страниц число ссылающихся сайтов стало неизменным. Открыл другой броузер, стер кукисы, выставил прокси - получил тот же самое количество беклинков.
А у меня все же менялись...
http://www.yandex.ru/yandsearch?Link=www.yandex.ru
Результат поиска: страниц — 55 268 977, сайтов — не менее 5 736
http://www.yandex.ru/yandpage?&q=181445077&p=6&ag=d&qs=Link%3Dwww.yandex.ru
Результат поиска: страниц — 55 268 870, сайтов — не менее 5 629
http://www.yandex.ru/yandpage?&q=181445077&p=13&ag=d&qs=Link%3Dwww.yandex.ru
Результат поиска: страниц — 55 268 870, сайтов — не менее 5 629
http://www.yandex.ru/yandpage?&q=181445077&p=44&ag=d&qs=Link%3Dwww.yandex.ru
Результат поиска: страниц — 55 268 743, сайтов — не менее 5 502
http://www.yandex.ru/yandpage?&q=181445077&p=51&ag=d&qs=Link%3Dwww.yandex.ru
Результат поиска: страниц — 55 268 743, сайтов — не менее 951
и на этом все закончилось...
Потом, оставаясь на последней странице http://www.yandex.ru/yandpage?&q=181445077&p=51&ag=d&qs=Link%3Dwww.yandex.ru нажал Crtl+F5 и получил
http://www.yandex.ru/yandpage?&q=181445077&p=51&ag=d&qs=Link%3Dwww.yandex.ru
Результат поиска: страниц — 55 268 714, сайтов — не менее 922
Вот и все выводы... 🚬
С уважением,
Сергей Пасечник.