Молодой человек, вы видимо не прочитали ту главу и не засели за калькулятор. Да , ваш пример скорее всего правильный. Потому что на больших таблицах ( с длинными полями) размер указателя хранящегося в индексе будет не существенным относительно всей длинны индекса, но для поискового сервера вам понадобаться микротаблицы типа KeywID , PageID , pos1, pos2 . И на них размеры индекса превысят размер таблицы. Да и в вашем примере превышает , но не существенно.
Простой пример , таблица из одного поля INT ( 4 байта) , индекс построенный по этому значению будет занимать ( 4 + 4(размер указателя) ) * 3/2 (заполняемость) или на 1 значение - 12 байт, что ~ в 3 раза превысит оригинальный размер таблицы. И это не вина разработчика , а особенность хранения данных .
По mysql прочтите раздел "Estimating Query Performance".
Однозначно это сложнее , только есть техническая задача и ее решение , иначе в песочницу .
Тема вроде давно отзвучала , но все же.
Я конечно не знаком с разработчиком "совы" , я сам разработчик другого украинского сервера , "сова" меня опережает по посетителям, но не намного. Суть не в этом . Пользователи так же недовольны.
После определенных измышлений я пришел к выводу что SQL базы не годятся для поисковых машин и вот из каких соображений. Дело в том что индексы SQL баз состоят из листов , в которых есть значение и ссылка на запись в таблице. При ничтожных записях , таких как например KEYW(INT) DOC(INT) POINTS (int) , размер индекса превышает размер таблицы, для оптимизации SQL запроса таких индексов может быть три , в итоге индексы могут превысить саму запись в несколько раз. Вы индексируете 1 мб , а получаете 4 мб . Для публики дожно быть понятно что я здесь описал процесс очень грубо, если хотите узнать как помучайтесь сами ;-). Отсюда следует расход памяти и скорость. Кроме того , SQL базы оставляют "дыры" в индексах, они нужны чтоб быть готовыми вставить запись. Что для поискового сервера не совсем требуется.
Во вторых я пришел к выводу , что процесс должен состоять из двух частей , первая - это сбор и коллекционирование информации (тут может применяться SQL) , не путать с простой работой паука, и компилирование собранной информации в структуру пригодную для поиска. В процессе компиляции часть информации может быть отброшена , например если слово "окно" посторяется 100000 раз , то поверьте оно врядли вам пригодиться в таком количестве. При выдаче обычно отдается первых 200 результатов , и даже если предположить что возможен mix с другими словами , все равно его столько не нужно. А сколько нужно - будет зависеть от вашей политики.
Далее я заметил что яндекс меняет выдачи версиями баз. Т.е. коллекционирует и в определенные дни происходит замена одной базы на другую. Целиком.
Более я убежден что яндекс например сначала выбирает "кандидатов" , затем делает пересортировку в памяти и выдает в выдачу. Но кандидаты при этом "верные". Далее результаты этого кеша еще некоторое время хранятся - вторая и следующие страницы выдаются с кеша.
Что касается mysql и применения в непоисковых системах, то тут у меня имеется опыт до 4 Гб , все работает очень быстро.
Не ну че прислушался , удалил линкаторы . И написал там по другому . Каталог полезных ссылок. В принципе они мне не нужны . И так все со всем нормально.
Кстати , а как происходит склейка, последствия . Как это выглядит . Я поставил ссылки на другом сайте на том же IP , с точным соответвием тайтла, и текста ссылок на основном сайте.
Мы говорим не о том что он на самом деле представляет. А то что я не вижу ничего противозаконного. Если яндекс каталог меряет качество по нему, почему я не могу померять.
А чем вам не понравилось N1 ? Собственно тИЦ является параметром качества ресурса. Теоретически. Чем больше цитируют ресурс тем он лучше. И вполне законно желание представить только качественные ресурсы.
История продолжаеся , с этой суботы опять ничего нет в яндексе и робот за это время не посещал ...
Что называется "ну нифига себе" , ей богу за пару часов еще раз смотрел . Данцинг ????
Или письмо в саппорт , я писал ?
Или барабашки ?
Помогало ? Примеры ? Или чисто теоретически ?
