Минусинск заработал: часть 11

А в них, наверное, естественные, непокупные ссылки. Вот они какие. Вот они где.

Цифры - могли скакать, видимо так база работает, быстрее выдать любую близкую цифру, чтобы не нагружать. А вот список. У меня есть проект, в котором очень мало ссылок и они видны, и там этот список на глазах менялся. И да, обычно в вебмастере ссылки менялись от апдейта к апдейту.

Уже забыл когда только в апы появлялись новые, как минимуму не саповские, так как с сыпы могли влетать и вылетать, их не упомнишь сильно.

Вы понимаете, как работает программа? Она берет данные из ячейки и показывает их на сайте. Сама программа не может ничего придумать.

Теперь вопрос - как программа определяет "близкую цифру"? Близкую к чему? К нулю или миллиону? Если близкую к той, что содержится в базе, то ее для начала нужно взять из этой самой базы.

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

A007MP, +1.

учитывая, что цифры повторяются, как было отмечено незмечено и количество вариантов ограничено.

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

---------- Добавлено 21.08.2015 в 22:28 ----------

Возьмите любую запросную базу данных и вставьте в нее 10 значений. Попросите базу вернуть вам количество и вы получите 10. Вставьте в нее 10 миллиардов значений и начнете получать разные цифры. Это оптимизация базы, так обрабатываются запросы, иначе приходится вовлекать систему в перебор всех ячеек, а это слишком ресурсозатратно для того, чтобы показать вам количество бэков.

Я работаю как минимум с 2 высоко нагруженными, не миллиарды, но несколько десятков миллионов. Спорить не буду, все таки до программистов не дорос и дуб дубом в этом. Но подтверждение вашим словам не видел.

Как должна работать программа по подсчету обратных ссылок:

1. Робот обходит сайты и заносит урлы всех (уникальных) страниц, на которых найдена обратная ссылка, в базу.

2. Когда мы обошли все сайты в интернете и занесли в базу все имеющиеся страницы и сайты, программа подсчитывает количество записей (то есть уникальных страниц) и записывает эту цифру в другую базу.

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

Конечно это все утрировано, но примерно так это должно работать. Понятное дело, что один сервер с этой нагрузкой не справится, поэтому задача разбивается на множество серверов и пауки поочередно обходят сайты, занося данные именно в свою базу. Но потом все должно синхронизироваться (складываться, сравниваться или пересекаться с другим множеством), но общий смысл такой. Но вот по какой-то причине там идет неверный подсчет. Либо глючат сервера, либо программа, либо алгоритмы - кроме сотрудников яндекса вряд ли эту информацию кто-то знает. Именно поэтому недавно все пользователи жаловались на некий "ссылочный взрыв и отскок", когда количество ссылок внезапно увеличивалось в разы, а потом обратно уменьшалось (или наоборот). Да и то, как правильно заметил Присущ - изменение этих цифр при обновлении страницы имеет свою закономерность. То есть 2-3 значения на разных серверах, которые не синхронизировались и показывают эти данные.

Беру небольшую базу в 100 тысяч записей - бэклинки, формат INNODB, тип SQL

В общем списке таблиц вижу запись: ~108,718. Открываю первую страницу (вывод по 30):

"Отображает строки 0 - 29 ( ~109,257 всего , запрос занял 0.0002 сек.)"

открываю 2-ю страницу

"Отображает строки 30 - 59 ( 115,192 всего, запрос занял 0.0002 сек.)"

открываю 3-ю страницу

"Отображает строки 60 - 89 ( 103,593 всего, запрос занял 0.0002 сек.)"

открываю 4-ю страницу

"Отображает строки 90 - 119 ( 107,234 всего, запрос занял 0.0002 сек.)"

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

---------- Добавлено 22.08.2015 в 01:09 ----------

Это ваши домыслы, алгоритм работы базы данных я описал выше. Не думайте, что Яндекс ставит перед собой задачу отчитаться перед вами о количестве ссылок на ваш сайт. Это не так. Поэтому отдельной базы количества бэклинков никто не ведет. Она есть у всевозможных сервисов по сбору бэклинков типа ahrefs - там цифра скакать не будет, потому что забита в отдельную таблицу.

Вы извините, но у меня калькулятор быстрее работает, чем Ваш "сервер".

Отображает строки 9778650 - 9778679 ( 9,778,954 всего, запрос занял 0.0001 сек.)

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