Google демпингует на рынке поисковых движков

Я готов согласиться, что, наверное, это предложение Google - тот же самый custom search, только вылизанный ...

И в этом состоит главный недостаток, который сводит почти к 0 все преимущества. Крупнейшие проблемы такого поиска:

1. Медленная индексация - при поиске по базе данных сайта новая информация доступна через секунду после добавления. Гугль же может не проиндексировать ее и за месяц.

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

В общем, будущее за узкоспециализированным поиском. Т.е. если мне нужно найти квартиру в Москве, то я иду на поисковик "Аренда недорогих квартир в Москве" и просто выбираю вариант. А Яша и Гугол отдыхают.

Так что нужно просто сделать единый сайт со всеми вариантами, чтобы владельцы квартир сами их туда добавляли, вот и все. Какой смысл делать 1000 разных сайтов и индексировать их, если юзерам нужен лишь 1, но рабочий сайт, в котором реально можно что-то найти?

.
сайты от 250р
.

как-то вы совсем не в тему выступаете:

"1. Медленная индексация ..." - посмотрите ниже, это уже обсудили.

"2. Неудобство ..." - G предлагает решение для тех, кому не удобен ИМЕЮЩИЙСЯ у них поиск по сайту. Если кому-то он более удобен, чем то, что предлагает G, то ... и слава богу!

"Так что нужно просто сделать единый сайт ..." - это вообще ни к селу, ни к городу ...

1) Про доступность через секунду — в общем случае неправда. Если речь идёт о мелком сайтике с сотней посетителей в день — да, это так. Если у вас количество текстов в базе исчисляется десятками мегабайт, то тупые запросы SELECT * WHERE text LIKE '%sample%' не проходят, мало-мальски приличная аудитория просто положит базу данных. Так что приходится заниматься индексированием, что автоматически означает конечную свежесть выдачи.

И я сомневаюсь, что если на сайте есть sitemap - он будет индексироваться месяц. Попробуйте сами и убедитесь.

2) Никто не говорил, что поиск Гугла будет ненастраиваемым. В том же CSE есть приличное количество инструментов для структуризации контента, они наверняка будут работать и в "заказном" поиске, а вероятнее всего будут расширены.

Да и сайт это - в общем случае - не база данных, а "набор" файлов. Представить себе, что весь контент сайта находится в одной (или нескольких) таблице, к которой можно делать запросы SELECT ... можно, наверное, но - как-то странно.

Если Серж говорит, что он хранит на Film.ru тексты в базе - значит, так оно и есть.

Вот на Lenta.ru до сих пор всё в plain text файлах. И ищется там практически grep'ом.

И ничего. Не жалуется народ.

Разные школы. Серж - виндузист. Мошков - юниксист.

Правильно сработанная структура flat file text database по скоростям не хуже, чем RDBMS :)

http://gong.livejournal.com/110784.html?thread=137920#t137920

4 секунды на запрос - grep'ом.
5 -"- - sqlite
45 -"- - mysql

.html...

Gabe wrote: "I didn't bother with databases because I didn't need the added complexity... I maintain the full text and metadata for thousands of articles and blog posts in core. Tech.memeorandum occupies about 600M of core. Not huge."

И ещё:

Mark wrote: "The 1.4 billion blog posts we've archived since we went on-line are stored in a data storage system that we wrote ourselves. This system is based on flat files that are replicated across multiple machines, somewhat like the system outlined in the Google File System paper."

Никакой я не виндузист. Хоть на Фортране пиши, главное чтобы нагрузку держало и масштабировалось. Вот к Ленте как раз по этой части претензии: оно регулярно ложится, чуть было нагрузка вырастет. Допустим, к 9/11 не подготовился никто, но когда Ельцин умер — трафик на новостных изданиях вырос дай бог вдвое-втрое против обычного, и всё, привет, Лента помахала нам ручкой. И я не уверен, существует ли способ эффективно эту историю отзеркалить на кластер.

Насчёт большой задержки — давно уже не так. Если сайт достаточно авторитетен (имеет высокий PR, давно сидит на одном IP) и на сайте есть грамотный sitemap/или он экспортирует RSS, то новые документы добавляются в Google молниеносно. На примере Фильм.Ру: новости и статьи регулярно встречаются в гугловой выдаче менее чем через час после опубликования.

Час - это, конечно, круто. Но для новых проектов, особенно с большим начальным кол-вом документов, это вряд ли сработает. Скажем для моего сайта с PR3 добавление нескольких десятков документов заняло в июле две недели.
Т.е. CSE хорошее решение, но некоторые неоднозначные вещи типа PR, "один ip" и т.п. снижают его привлекательность.
И если бы они сделали за это $100-500 свою песочницу для каждого CSE с каким-то документированным сроком обновления, то это было бы гораздо веселее. Хотя тут могут быть уже другие проблемы, типа использования песочницы не по назначению.

PR - это отдельная тема. А то, что они сканировать эти сайты, стоящие на обслуживании, будут с той частотой, которая будет ОГОВОРЕНА в условиях КОММЕРЧЕСКОГО договора, так в этом как бы даже сомневаться странно ...

Обсуждается платная услуга, а вы ее сравниваете с проблемами и обстоятельствами бесплатного (и вообще - произвольного) сплошного сканирования!

А я сравниваю, потому что я специально искал у гугла упоминание про скорость индексации для cse за деньги, и не нашел. Хотя да, триал не пробовал и tos соотвественно именно для комм. версии не видел.
Тем более, скорость сканирования не связана напрямую с временем попадания в индекс. Гугл бот обычно приходит очень быстро.

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

Я, кстати, вообще считал, что задержка связана с тем, что индекс у гугла обновляется далеко не моментально. Но вот SergeAx пишет, что у него за час, что наводит на мысль, что или индекс таки у гугла очень часто меняется, или, скорее, он сегментирован, и есть более динамические части, в которые и добавляются обновления от "авторитетных" сайтов.

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

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

Так что если нужен действительно хороший поиск по базе, который дает конкретные ответы на конкретные вопросы, то Гугол отдыхает. Приведу пример, который уже не раз упоминал: если мне нужна 3-комнатная квартира в Отрадном, не ниже 3-го этажа, по цене до 1000 доларов, с мебелью, то что выдаст Гугол на такой запрос? Миллион мусорных страниц. А должен выдать ТОЛЬКО то, что реально есть и подходит по ВСЕМ параметрам. Не больше и не меньше, а ровно столько.

И если один из этих вариантов ушел МИНУТУ назад, то он не должен выдаваться ВООБЩЕ в качестве релевантного результата. Сразу после того, как автор записи (владелец квартиры или агентство) отметил вариант, как неактуальный, запись должна перестать показываться. В Гугле это пока фантастика - там часто висят сайты и страницы, которые год назад перестали существовать. И это сильно раздражает всех пользователей.

Так что метод поиска, предложенный Гуглом, не годится для большинства СЕРЬЕЗНЫХ бизнес-сайтов. А несерьезные сайты не будут платить столько денег, так как поиск чаще всего является необязательной функцией для таких сайтов - по такому сайту можно искать и бесплатно в том же Гугле или Яху.

Странно, в среде оптимизаторов редко встречаются такие наивные идеалисты. Такое впечатление, что вы ну никак не хотите, чтобы решение от Гугла оказалось адекватным и приемлемым. Скажите, вы в глубине души ненавидите Гугл?

Ну вот взять, скажем, Фильм.Ру. Онлайновое СМИ, в базе данных — под 20 000 фильмов, около 10 000 текстов (новостей, статей, интервью, рецензий, репортажей и т.д.), 100 000 персоналий, из которых про 10 000 известно больше, чем имя и фамилия. Ну и там 150 кинотеатров, расписания сеансов и т.д. Суммарный объём базы данных, включая индексы — 300 мегабайт. Это довольно много, но это не запредельно: я легко представляю себе, скажем, онлайновый архив газеты "Правда" с 1917 года, или, более реалистичный пример, собрание документов какого-нибудь органа власти, в который добавляется примерно по мегабайту в день. Скажу проще: любое серьёзное интернет-СМИ рано или поздно достигнет суммарного объема текста в сотню мегабайт.

В принципе проблема поиска по массивам информации объёмом в сотни мегабайт при помощи прямого перебора базы данных, разумеется, решается. Мой опыт подсказывает, что если ткнуть пальцем в потолок, то там будет написано две цифры: 5000 долларов и 100 000 запросов в день. Первая — это стоимость выделенной железки под такую задачу, вторая — его производительность. Стоимость разработки составит, ну, скажем, ещё минимум пятерку, при условии, что программирование не на аутсорсе, а внутри (мы же солидная контора, да?). Так вот я утверждаю, что потратить 10 тысяч долларов на решение задачи мгновенного поиска — это абсолютно неадекватное поведение для любого СМИ, при условии существования на рынке решений на порядок более дешевых, обеспечивающих лаг в 15 минут на добавление/изменение информации и, скажем, 12 часов — на удаление.

И не путайте текстовые поиски со специализированными. Вы ещё билеты на самолёт поищите Гуглом, или тур в отель "Всё включено" на завтра.

Необязательной функцией поиск является для ваших сайтов, которые вы делаете для роботов, а не для людей. На любом НОРМАЛЬНОМ сайте поиск ОБЯЗАН быть просто по умолчанию, особенно сейчас, в XXI веке. Ибо это инструмент увеличения глубины просмотра, вовлеченности и лояльности пользователей. Впрочем, вам эти термины ничего не говорят. И если даже самый примитивный блоггер зарабатывает на своём сайте контекстом, скажем, $100 в месяц, то добавив поиск, он элементарно поднимет свою прибыль минимум на 10%, то есть уже $40 в плюсе, и это при условии, что кликабельность контекста на поисковой выдаче такая же, как у обычной страницы, а это не так, она примерно вдвое выше.

обеспечивающих лаг в 15 минут на добавление/изменение информации и, скажем, 12 часов — на удаление.
Эти цифры вы откуда взяли?

Скажите, вы использовали sitemap?

Конечно. У меня даже lastmod в сайтмапе совпадают с реальными last-modified, так что новые документы теоретически видно сразу.

Квинтура - ИМХО мыльный пузырь для инвесторов, так как там нет ничего принципиально нового (кроме кривого интерфейса).

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

Вообще-то вы - не первый.

Но раз уж вы не первый: признак, позволяющий задавать вопрос о демпинге, - когда товар продается по ценам ниже себестоимости У КОНКУРЕНТОВ. Собственно, тогда они и начинаю вопить про демпинг.

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

Ну и конечно я признаю и подтверждаю,- для тех кто в танке - что слово "демпинг" употреблено здесь в метафорическом смысле. Готов принести искренние извинения уважаемому Google.