Дык, оффтопик же совершенно очевидный. :-)
Извините, я не написал. В принципе, там если внимательно читать контекст, то можно понять. Вкратце я сравнивал показатели моего знакомого с тем, что другой пользователь форума написал. 20 тысяч - это о посетителях. 40 - уе об общих доходах через AdSense.
МолНет, вроде же я написал, что по отзывам людей. В частности по отзывам моего бывшего начальника. Зачем ему мне врать?
Ну ладно, насчет разницы в сто раз. Придется немного сдать знания, полученные во время работы в Яндексе. Специально для представителей Яндекса, которые думаю, что это нереально. Например, примерно такая разница наблюдается между многосёрчем в режиме single payload и одной Яндекс-нодой который стоит в Яндексе.
Максим, ну пусть 25% в среднем. Все равно там 2 * 1.25 = 2.5 раза. Так что цифры у этих ребят не сходятся в нескольких местах. И это только одно несоответствие. Второе заключается в том, что я не верю, что BDB как object store работает хотя бы примерно с той же скоростью, что и плоский файл. Если авторы верят в это, то это надо доказывать в цифрах. У меня этих цифр нет, но я помню, что когда в моем n-граммном индексе я начал хранить инвертированные списки просто на диске, а не в Беркли, у меня все заметно ускорилось.
А Илья, как раз спорит, не верит, что разница в сто раз возможна. И приводит заборные аргументы. А на заборе как раз всякая фигня может быть написана. Даже если забор такими уважаемыми людьми изготовлен.
PS: Несмотря на то, что в статье много всяких несоответствий там есть и очень правильные мысли на тему блочного кодирования. Что с ним действительно получаются неплохие результаты. У меня вот тоже есть очень положительный опыт использования блочного кодирования, только вот все равно до статического файла это малость не дотягивает, а структуры получаются навороченные.
Да и не нужно для интернет-поисковика нестатический файл, это просто я бы сказал глупо. Интернет поисковик может достаточно быстро "засосать" миллиона два докментов, сделать для них за пару часов индекс. Абсолютно копеечный оверхед по сравнению со временем обхода эти двух млн. документов. А несколько статических файлов можно опросить последовательно. Если их 2-3 на машине, то это всего на несколько процентов медленнее, чем один большой статический индекс в 5 млн. урлов.
И кстати, по поводу разницы в 100 раз: если упакованный инвертированный индекс весь влезает в кеш, а неупакованный список этих самых single payload в несколько раз больше размера оперативной памяти, то как раз эти самые 100 раз и получишь, уж никак не меньше.
Илья, я могу очень много рассказать про скорость индексации и прочая, но пока просто ограничусь указанием на несколько забавных мест в статье, ссылку на которую ты опубликовал. Вкратце хочу сказать, что авторы просто безбожно курят, когда дело касается конкретных цифр и дат. Итак обрати внимание на Figure 7 и таблицу 3. Но еще лучше сначала почитать раздел 4.2:
Внизу идет сноска, что 321 миллион это без учета повторяющихся постингов терминов внутри документа. Еще в таблице 3 для этих 2 млн документов указан средний размер input (HTML) в 16 гигов. Ага все замечательно. Исходя из среднего размера слова в 5.5 символов (для англ. языка) получаем, что чистый текст этой коллекции был никак не меньше (5.5 + 1) * 321 mln byte 1.8 гигов. Реально, наверное, было 2-4 гига текста. Возможно, что и больше, все зависит от повторяемости слов в документы 321 mln это все-таки без повторений.
Теперь посмотрим, сколько места может занимать single payload файл. В нем хранится слово ключевое 5.5 байт и еще два поля (номер документа, номер слова) по два байта минимум, а реальн, наверное, 2 + 3. еще сколько-нибудь занимает служебная информация (миниумум байт, а то и целый указатель) итого получаем примерно 10-12 байт на запись, что уже в два раза больше чистого текста. Теперь вспомни, что Беркли собственно строит динамические индексы и процентов пятьдесят места на страницах резервирует под будущие обновления, итого получаем трехкратный размер текста.
Потом снова смотрим в фигу 7 и натурально видим фигу, потому как размер всех списков анонсирован 3.5 гига вместо 6 гигов по самым скромным подсчетам. Уже разница в два раза!!! Может авторы выкинули стоп-слова? Но они про это нигде не пишут.
Далее в таблице 7 пунктиром указан размер индекса для так называемых full list. Он равен 1.5 гига. Несложно понять, что в не зависимости от того какой там PctUsed и PctFree в беркли, сжатый таким образом файл с точностью до резервируемого пространства < 50% текста, а single payload > 200% текста. Итого разница должна быть как минимум в 4 раза, а она чуть больше двух.
А вот еще очень важный логический момент: Авторы сравнивают скорость выборки mixed-list и full-list, но full-list лежит в индексе. А это значит, что скорее всего он побит на страницы, которые распиханы физически в разные уголки винчестера. То есть скорость поиска последовательно записанного на диск пост-листа может быть заметно выше. Авторы не приводят соответсвующих сравнений, но зато пишут:
Откуда, блин, такая уверенность в efficiency. Фантазеры, блин, а не ресерчеры. У меня вот лично есть абсолютно обратный экспириенс. Хотя я точных цифр не помню, но в свое время пришлось уйти от схемы full list и насколько я помню случился приличный выигрыш в производительности.
В любом случае, пока нет этих самых цифр про эффишенси по BDB vs plain binary file, это все несерьезно.
Короче, Илья, статья твоя халтура и полная лажа
20 тыс в месяц, меньше тысячи в день, соответственно порядка 200 уникальных посетителей в день. А если их порядка 1000 в день получается где-то 40, что соответствует реальным отзывам людей. На англоязычном контенте, ИМХО, можно заработать в несколько раз больше.
У знакомого интернет-магазин, 1 к в сутки, 20 баксов в месяц. Он, правда, не особенно много объявлений публиковал. Можно предположить, что при 3к в сутки заработок начинается где-нибудь с полтинника.
есть подозрение, что такой хитрый запрос написать не удастся. скорее всего придется просто считывать все и пересекать в памяти.
