Передача тИЦ и вИЦ с бесплатных хостингов. Хочется все-таки прояснить

Но там зачем-то написано: Отсортировано по релевантности по дате

Адепт, а не находите, что это в яндексе на всех страницах выдачи написано, независимо от того, что он выдает ?

У них система самописная. Как выводит, честно говоря, не знаю.

Раз уж вытащили топик, дублирую пропавшую ссылку.

http://dubr.com.ru/freehost.html

Что-то мне подсказывает, что беки одного сайта должны лежать на одной машине, так что кластерность не должна влиять.

Я сильно в этом сомневаюсь.

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

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

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

В четвертых - другие причины

С уважением,

Сергей Пасечник.

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

Мои аргументы просты. Хранение беков на страницу Х на одной машине существенно увеличивает быстродействие:

а) при пересчете вИЦ, тИЦ, ссылочного ранжирования, наложения фильтров

б) при выдаче по запросу Link=www.site.com

Back Door Man, согласен. Мало того что быстродействие существенно повышается, но и объемы избыточной информации не такие уж и большие получатся.

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

Вот и не факт.

Забейте в строку поиска вот это #link="www.yandex.ru" и понажимайте Ctrl+F5 с десяток раз. Ежели бы все лежало на одной машине, то цифры бы не прыгали, так как операция выборки из БД выполнилась бы полностью. Это раз. А что, если страничка будет ссылаться на какую-то еще. Что, продублируем в базе столько раз, сколько она на кого-то ссылается? Это два. Когда начинаешь щелкать по номерам страниц в списке бэклинков - число уменьшается. Если бы вся выборка велась с одной машины - оно бы имхо не стало уменьшаться. Это три.

Дык я тоже не инсайдер, но как у разработчика в прошлом немаленьких БД возникают некоторые решения 🚬

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

Алгоритм с дублированием информации имеет два больших минуса:

1. Увеличение объема информации

2. Усложнение алгоритмов пересчета

Но они оба перевешиваются огромным жирным плюсом, который в случае с поисковой системой наиболее важен - быстродействием.

Дисковые массивы дешевеют, а время как всегда дорожает. :) Не грех и продублировать. :)

Порефрешил, подождал, еще порефрешил - не поменялось. Привязка меня как пользователя к конкретной машине кластера не поменялась.

Ну да, а что Вас смущает? Три поля в таблице: id, кто ссылается, на кого ссылается. Просто как две копейки, и работает быстро

Имхо, это самый серьезный аргумент. Но и тут может быть своя фишка. При первоначальном запросе "link=" выдается некоторая заранее просчитанная сумма ссылок. Если пользователь тыкает на страницу 2, то идет уже выборка самих ссылок из базы и новым пересчетом их количества (забавно, но без апдейта предыдущего поля).