Comments 54
Спасибо за такой сравнительный обзор и ваши выводы — ждем продолжения!
>Если поисковик по каким-то причинам недоступен, пользователи не сидят и не ждут, когда он, наконец, заработает — они просто идут в другие системы (например, мы отчётливо видели это по счётчикам LiveInternet год назад, во время сбоев у одного из наших конкурентов)
Мне кажется ситуация была ровно обратная, основная часть никуда не перешла.
Хотя конечно те, что всё же перешли, создали ощутимый эффект на поисковик с небольшой долей.
Мне кажется ситуация была ровно обратная, основная часть никуда не перешла.
Хотя конечно те, что всё же перешли, создали ощутимый эффект на поисковик с небольшой долей.
Вы правы в количественном отношении.
Я это показывал в выступлении на РИФе, тут есть слайд под номером 5 с иллюстрацией: go.mail.ru/blog/2012/04/27/pochemu-lyudi-menyayut-poiskovik/
Было 70 тысяч переходов, вместо этого 20-25 тысяч ушли к конкурентам.
Но в качественном отношении — это же очень много! Когда почта лежит, такого не случается.
Кроме того, после восстановления работоспособности сервиса, кто-то всё-равно остаётся на новом поисковике.
Понятно, задачи есть разные, что-то нужно искать прямо сейчас, а что-то и потерпит. Но поведение людей отличается.
Я это показывал в выступлении на РИФе, тут есть слайд под номером 5 с иллюстрацией: go.mail.ru/blog/2012/04/27/pochemu-lyudi-menyayut-poiskovik/
Было 70 тысяч переходов, вместо этого 20-25 тысяч ушли к конкурентам.
Но в качественном отношении — это же очень много! Когда почта лежит, такого не случается.
Кроме того, после восстановления работоспособности сервиса, кто-то всё-равно остаётся на новом поисковике.
Понятно, задачи есть разные, что-то нужно искать прямо сейчас, а что-то и потерпит. Но поведение людей отличается.
На самом деле, в самом Lucene реализовано не так много интересных решений, которые могла бы позаимствовать большая поисковая система по вебу, рассчитанная на миллиарды документов.
А чего не хватает если по существу? Или просто «Java/gc тормозит»?
С другой стороны, это довольно смелое решение, потому что сайты обкачивать тяжело — не каждый сайт отвечает за гарантированное время, и вычислительные ресурсы кластера тратятся на то, чтобы он просто ждал ответа от чужого веб-сервера.
…
Мы некоторое время анализировали такое решение, и в результате отказались от него. Пожалуй, для нас архитектура этого спайдера была интересна как, своего рода, «отрицательный пример».
Я так и не понял, вы отказались от этого решения потому что «вычислительные ресурсы клатера тратятся на то, чтобы он ждал ответа от чужого веб-сервера»? Как вы решили эту проблему — отказались от индексирования медленных сайтов вообще или решили тратить вычислительные ресурсы «другого» кластера?
А чего не хватает если по существу? Или просто «Java/gc тормозит»?
С другой стороны, это довольно смелое решение, потому что сайты обкачивать тяжело — не каждый сайт отвечает за гарантированное время, и вычислительные ресурсы кластера тратятся на то, чтобы он просто ждал ответа от чужого веб-сервера.
…
Мы некоторое время анализировали такое решение, и в результате отказались от него. Пожалуй, для нас архитектура этого спайдера была интересна как, своего рода, «отрицательный пример».
Я так и не понял, вы отказались от этого решения потому что «вычислительные ресурсы клатера тратятся на то, чтобы он ждал ответа от чужого веб-сервера»? Как вы решили эту проблему — отказались от индексирования медленных сайтов вообще или решили тратить вычислительные ресурсы «другого» кластера?
А чего не хватает если по существу? Или просто «Java/gc тормозит»?
Я лично не считаю Java безусловным недостатком, но на поисковом кластере по-моему логичнее использовать C/C++. Потому что там оптимизация оправдывается, а её выполнять проще на этих языках.
По существу же ответ тут будет пространный, это же ведь и не недостаток, в общем-то, это просто разные задачи. Lucene — это универсальный движок, а веб-поиск заточен под конкретное применение и в нём, во-первых, много конкретных оптимизаций, сделанных под имеющиеся данные и важные для производительности (реализация эшелонирования как самый простой пример) и, во-вторых, сам движок невелик по отношению ко всякой обвязке, вокруг него накрученной. Тут и организация апдейтов, и failover и т.п. Про это редко рассказывают и, на мой взгляд, это самое интересное.
В качестве иллюстрации вещей, специфичных для индекса, приведу первое, что приходит в голову — стоп-слова. Как решена проблема стоп-слов в Lucene? Они выкидываются. Но если их выкидывать, то становится сложнее искать цитатные запросы, т.е. выкидывать нельзя (а то [что где когда] не найдётся). А что делать, если не выкидывать? Относиться к ним как к обычным словам нельзя, они же большие, просто так ходить по их координатным блокам — мучение. Вот это уже интересный вопрос, решение которого требует некоторой смекалки и изворотливости.
(Я, конечно, может и ошибаюсь, я Lucene сильно не изучал, может там всё иначе. )
Сильная сторона Lucene — API, настройка на разные языки. Возможность внедрить к себе и не задумываться о том, что внутри поиска происходит. Часто именно это и нужно, но в веб-поиске движок дотачивается под поиск.
И, повторю, из Lucene, наоборот, очень много чего интересного отпочковалось — Hadoop, HBase.
Я так и не понял, вы отказались от этого решения потому что «вычислительные ресурсы клатера тратятся на то, чтобы он ждал ответа от чужого веб-сервера»?Ну, в реализации Nutch'а это получается так. Если один редьюсер хватает урлы одного сайта, то он будет качать их с паузами (он же «вежливый»?) и слот будет всё это время простаивать.
Как вы решили эту проблему — отказались от индексирования медленных сайтов вообще или решили тратить вычислительные ресурсы «другого» кластера?
В некотором смысле, «решили тратить ресурсы другого кластера» :)
Дело в том, что выкачка это довольно простой процесс и, главное, постоянный. Соответственно процессы, обкачиваю
Я лично не считаю Java безусловным недостатком, но на поисковом кластере по-моему логичнее использовать C/C++. Потому что там оптимизация оправдывается, а её выполнять проще на этих языках.
По существу же ответ тут будет пространный, это же ведь и не недостаток, в общем-то, это просто разные задачи. Lucene — это универсальный движок, а веб-поиск заточен под конкретное применение и в нём, во-первых, много конкретных оптимизаций, сделанных под имеющиеся данные и важные для производительности (реализация эшелонирования как самый простой пример) и, во-вторых, сам движок невелик по отношению ко всякой обвязке, вокруг него накрученной. Тут и организация апдейтов, и failover и т.п. Про это редко рассказывают и, на мой взгляд, это самое интересное.
В качестве иллюстрации вещей, специфичных для индекса, приведу первое, что приходит в голову — стоп-слова. Как решена проблема стоп-слов в Lucene? Они выкидываются. Но если их выкидывать, то становится сложнее искать цитатные запросы, т.е. выкидывать нельзя (а то [что где когда] не найдётся). А что делать, если не выкидывать? Относиться к ним как к обычным словам нельзя, они же большие, просто так ходить по их координатным блокам — мучение. Вот это уже интересный вопрос, решение которого требует некоторой смекалки и изворотливости.
(Я, конечно, может и ошибаюсь, я Lucene сильно не изучал, может там всё иначе. )
Сильная сторона Lucene — API, настройка на разные языки. Возможность внедрить к себе и не задумываться о том, что внутри поиска происходит. Часто именно это и нужно, но в веб-поиске движок дотачивается под поиск.
И, повторю, из Lucene, наоборот, очень много чего интересного отпочковалось — Hadoop, HBase.
Я так и не понял, вы отказались от этого решения потому что «вычислительные ресурсы клатера тратятся на то, чтобы он ждал ответа от чужого веб-сервера»?Ну, в реализации Nutch'а это получается так. Если один редьюсер хватает урлы одного сайта, то он будет качать их с паузами (он же «вежливый»?) и слот будет всё это время простаивать.
Как вы решили эту проблему — отказались от индексирования медленных сайтов вообще или решили тратить вычислительные ресурсы «другого» кластера?
В некотором смысле, «решили тратить ресурсы другого кластера» :)
Дело в том, что выкачка это довольно простой процесс и, главное, постоянный. Соответственно процессы, обкачиваю
Не дописал до конца, продолжаю.
Я так и не понял, вы отказались от этого решения потому что «вычислительные ресурсы клатера тратятся на то, чтобы он ждал ответа от чужого веб-сервера»?
Ну, в реализации Nutch'а это получается так. Если один редьюсер хватает урлы одного сайта, то он будет качать их с паузами (он же «вежливый»?) и слот будет всё это время простаивать.
Как вы решили эту проблему — отказались от индексирования медленных сайтов вообще или решили тратить вычислительные ресурсы «другого» кластера?
Медленные сайты нельзя не качать, теряется полнота поиска.
Поэтому, «решили тратить ресурсы другого кластера» :) Но он специфический, не такой, какой требуется для вычислительных задач.
Дело в том, что выкачка это довольно простой процесс и, главное, постоянный. Он требует сетевых ресурсов, диска и, по сути, больше ничего. Hadoop для этого не нужен. Можно очень просто сделать процесс, который качает список урлов в 10000 потоков и сохраняет на локальный диск, сервера под это нужны не очень мощные. Hadoop нужен, чтобы готовить списки документов на выкачку (приоритезация, подавление дублей и т.п.), для сохранения результатов и их последующей обработки.
В принципе, можно такой же процесс, асинхронно и во много потоков качающий сайты, реализовать и в виде редьюсера. Но, с другой стороны, мне очень не нравится идея запускать «вдруг» процесс, который может съесть значительное количество открытых файловых дескрипторов на сервере. Причём, на случайно выбранном сервере из кластера. А там и так могут быть проблемы с этими дескрипторами, потому что их довольно много требуется для работы регионсерверов HBase.
То есть, если пойти на принцип, «делаем всё в Hadoop'е», то можно реализовать. Но проще вынести.
Я так и не понял, вы отказались от этого решения потому что «вычислительные ресурсы клатера тратятся на то, чтобы он ждал ответа от чужого веб-сервера»?
Ну, в реализации Nutch'а это получается так. Если один редьюсер хватает урлы одного сайта, то он будет качать их с паузами (он же «вежливый»?) и слот будет всё это время простаивать.
Как вы решили эту проблему — отказались от индексирования медленных сайтов вообще или решили тратить вычислительные ресурсы «другого» кластера?
Медленные сайты нельзя не качать, теряется полнота поиска.
Поэтому, «решили тратить ресурсы другого кластера» :) Но он специфический, не такой, какой требуется для вычислительных задач.
Дело в том, что выкачка это довольно простой процесс и, главное, постоянный. Он требует сетевых ресурсов, диска и, по сути, больше ничего. Hadoop для этого не нужен. Можно очень просто сделать процесс, который качает список урлов в 10000 потоков и сохраняет на локальный диск, сервера под это нужны не очень мощные. Hadoop нужен, чтобы готовить списки документов на выкачку (приоритезация, подавление дублей и т.п.), для сохранения результатов и их последующей обработки.
В принципе, можно такой же процесс, асинхронно и во много потоков качающий сайты, реализовать и в виде редьюсера. Но, с другой стороны, мне очень не нравится идея запускать «вдруг» процесс, который может съесть значительное количество открытых файловых дескрипторов на сервере. Причём, на случайно выбранном сервере из кластера. А там и так могут быть проблемы с этими дескрипторами, потому что их довольно много требуется для работы регионсерверов HBase.
То есть, если пойти на принцип, «делаем всё в Hadoop'е», то можно реализовать. Но проще вынести.
Тут и организация апдейтов, и failover и т.п.
Ничего стандартного в этом отношение пока нет, но скорее всего потому что условия у каждого разные. Solr Сloud использует ZooKeeper для хранения конфигурации кластера (шарды, лидеры, реплики) и leader election, ElasticSearch zero discovery с броадкастом и тд.
Как решена проблема стоп-слов в Lucene?
Можно выкидывать, можно сохранять, можно делать и то и то в разные поля и просто бустить результаты с точным совпадением включая стоп слова. Проблема цитатных запросов со стоп словами решается индексированием N-gram-ов (и соот-ей обработкой запроса в момент поиска). Рассказали бы про ваше хитрое решение — очень интересно.
но на поисковом кластере по-моему логичнее использовать C/C++. Потому что там оптимизация оправдывается, а её выполнять проще на этих языках.
Я слышал мнение, что задачу обьединения результатов поиска от разных shards и отдачу пользователю некоторые реализуют на C/C++ потому что паузы GC здесь очень критичны, паузы на самих же поисковых нодах можно просто игнорировать по таймауту и возвращать неполные результаты поиска.
Если один редьюсер хватает урлы одного сайта, то он будет качать их с паузами (он же «вежливый»?) и слот будет всё это время простаивать.
Насколько я понимаю один редьюсер держит различные очереди для каждого топ левел домена (или айпи) и обрабатывает их паралельно. Если же осталась одна очередь с медленным сайтом, то наверняка можно решить проблему таймаутами или какой-нибудь эвристикой (дропать или вообще выбирать урлы с учетом скорости сайта?) или уменьшением кол-ва страниц скачиваемых одним редьюсером / увеличением кол-ва редьюсеров. Вообщем, является ли это глобальной проблемой при использовании nutch, которая никак не решилась в вашем случае?
Ничего стандартного в этом отношение пока нет, но скорее всего потому что условия у каждого разные. Solr Сloud использует ZooKeeper для хранения конфигурации кластера (шарды, лидеры, реплики) и leader election, ElasticSearch zero discovery с броадкастом и тд.
Как решена проблема стоп-слов в Lucene?
Можно выкидывать, можно сохранять, можно делать и то и то в разные поля и просто бустить результаты с точным совпадением включая стоп слова. Проблема цитатных запросов со стоп словами решается индексированием N-gram-ов (и соот-ей обработкой запроса в момент поиска). Рассказали бы про ваше хитрое решение — очень интересно.
но на поисковом кластере по-моему логичнее использовать C/C++. Потому что там оптимизация оправдывается, а её выполнять проще на этих языках.
Я слышал мнение, что задачу обьединения результатов поиска от разных shards и отдачу пользователю некоторые реализуют на C/C++ потому что паузы GC здесь очень критичны, паузы на самих же поисковых нодах можно просто игнорировать по таймауту и возвращать неполные результаты поиска.
Если один редьюсер хватает урлы одного сайта, то он будет качать их с паузами (он же «вежливый»?) и слот будет всё это время простаивать.
Насколько я понимаю один редьюсер держит различные очереди для каждого топ левел домена (или айпи) и обрабатывает их паралельно. Если же осталась одна очередь с медленным сайтом, то наверняка можно решить проблему таймаутами или какой-нибудь эвристикой (дропать или вообще выбирать урлы с учетом скорости сайта?) или уменьшением кол-ва страниц скачиваемых одним редьюсером / увеличением кол-ва редьюсеров. Вообщем, является ли это глобальной проблемой при использовании nutch, которая никак не решилась в вашем случае?
Ничего стандартного в этом отношение пока нет, но скорее всего потому что условия у каждого разные.
Да, я примерно это и имел в виду. При этом Вы справедливо напоминаете про Solr Cloud — про него я забыл, там действительно есть интересные фишки.
Рассказали бы про ваше хитрое решение — очень интересно.
Рассказывать конкретно слишком уж много получится, в общих чертах.
Вы правильно рассуждаете, про N-граммы. Но ведь просто взять и построить N-граммы для всего потока — это увеличить объём индекса как минимум вдвое (это если индекс не сжатый и если хранить слова и биграммы), а скорее и втрое-вчетверо (но реальное увеличение нужно проверять, индекс биграмм по-моему должен хуже сжиматься, чем индекс слов), а словарь — так на порядок. Поэтому индексировать все N-граммы только для того, чтобы при необходимости представить запрос в виде N-грамм довольно дорого (индекс же кладётся в память; если на диск — то без разницы, но поиск медленный получается).
Поэтому все N-граммы строить нельзя, надо отбирать нужные. Нужны, очевидно, N-граммы со стоп-словами. Допустим, всё-таки, речь идёт о биграммах, тогда на каждое стоп-слово есть две биграммы (для последовательностей слов A S B, где S — стоп-слово, получается две биграммы, AS и SB). Проблема в том, что если сохранять в индексе обе, то они тоже будут занимать значительное место, 30-50% от объёма индекса. Поэтому нужно отбирать по одной биграмме. Как отбирать — просто так не понять, в каких-то случаях нужны одни биграммы, в других — иные (а неправильно выделенные биграммы начинают мешаться). Например, для запроса [что было бы если футурама], где «что было бы если» это название серии, а «футурама» — название сериала, биграмма «если-футурама» будет вредна и не нужна, т.к. цитатность здесь важна только в первой части запроса, а футурама может болтаться в документе где угодно.
Поэтому отбор биграмм становится тесно связан с сегментацией запроса на части, выделением объектов из запросов и текстов и т.п.
Я слышал мнение, что задачу обьединения результатов поиска от разных shards и отдачу пользователю некоторые реализуют на C/C++ потому что паузы GC здесь очень критичны, паузы на самих же поисковых нодах можно просто игнорировать по таймауту и возвращать неполные результаты поиска.
Нет-нет, это мнение, на мой взгляд, совершенно неправильное и вредное.
Неполные результаты поиска это очевидное зло, нельзя на него полагаться как на штатную ситуацию. Могу, кстати, сказать, что мы, с 2010-го года, сократили количество неполных результатов в потоке порядка на три, каждый раз считая что вот теперь-то у нас наконец-то стабильный поиск. А когда привыкаешь к низким числам в этой статистике, оглядываешься на старые показатели и думаешь, «вот ужас-то был».
При этом GC на бэкендах будет возникать в разное время, тем самым неполные результаты будут возвращаться не с частотой запуска GC на одном бэкенде, а помноженное на общее количество бэкендов, Когда их число начинает быть кратным сотням это становится существенным.
Поэтому служебные действия на бэкендах правильно выполнять синхронно, минимизируя общее время, когда кластер отвечает неполно. В это время можно жить на кеше, можно использовать второй кластер (если он есть) для подстраховки.
Но насколько я знаю, если такие вещи пишут на Java, то вообще пытаются не полагаться на собственный аллокатор, чтобы не бороться с GC. Выделяют памяти от пуза и уже работают с ней самостоятельно. Но я тут как раз перестаю понимать, зачем пользоваться Java, когда C/C++ есть :)
Вообщем, является ли это глобальной проблемой при использовании nutch, которая никак не решилась в вашем случае?
Да мы Nutch не использовали, мы своё писали. И у нас была такая мысль, сделать выкачку на том же кластере, что и всё остальное, «раз платформа есть». Но я просто считаю, что если задача хорошо и просто отделяется, отличается от остальных задач, то её нужно отделять. Выкачка, как я написал выше, очень специфична, ей требуются другие ресурсы. И, в общем, ни разу об этом решении не пожалели.
А то ведь и сёрчеры тоже можно как-нибудь на Hadoop'е запустить, в принципе.
Да, я примерно это и имел в виду. При этом Вы справедливо напоминаете про Solr Cloud — про него я забыл, там действительно есть интересные фишки.
Рассказали бы про ваше хитрое решение — очень интересно.
Рассказывать конкретно слишком уж много получится, в общих чертах.
Вы правильно рассуждаете, про N-граммы. Но ведь просто взять и построить N-граммы для всего потока — это увеличить объём индекса как минимум вдвое (это если индекс не сжатый и если хранить слова и биграммы), а скорее и втрое-вчетверо (но реальное увеличение нужно проверять, индекс биграмм по-моему должен хуже сжиматься, чем индекс слов), а словарь — так на порядок. Поэтому индексировать все N-граммы только для того, чтобы при необходимости представить запрос в виде N-грамм довольно дорого (индекс же кладётся в память; если на диск — то без разницы, но поиск медленный получается).
Поэтому все N-граммы строить нельзя, надо отбирать нужные. Нужны, очевидно, N-граммы со стоп-словами. Допустим, всё-таки, речь идёт о биграммах, тогда на каждое стоп-слово есть две биграммы (для последовательностей слов A S B, где S — стоп-слово, получается две биграммы, AS и SB). Проблема в том, что если сохранять в индексе обе, то они тоже будут занимать значительное место, 30-50% от объёма индекса. Поэтому нужно отбирать по одной биграмме. Как отбирать — просто так не понять, в каких-то случаях нужны одни биграммы, в других — иные (а неправильно выделенные биграммы начинают мешаться). Например, для запроса [что было бы если футурама], где «что было бы если» это название серии, а «футурама» — название сериала, биграмма «если-футурама» будет вредна и не нужна, т.к. цитатность здесь важна только в первой части запроса, а футурама может болтаться в документе где угодно.
Поэтому отбор биграмм становится тесно связан с сегментацией запроса на части, выделением объектов из запросов и текстов и т.п.
Я слышал мнение, что задачу обьединения результатов поиска от разных shards и отдачу пользователю некоторые реализуют на C/C++ потому что паузы GC здесь очень критичны, паузы на самих же поисковых нодах можно просто игнорировать по таймауту и возвращать неполные результаты поиска.
Нет-нет, это мнение, на мой взгляд, совершенно неправильное и вредное.
Неполные результаты поиска это очевидное зло, нельзя на него полагаться как на штатную ситуацию. Могу, кстати, сказать, что мы, с 2010-го года, сократили количество неполных результатов в потоке порядка на три, каждый раз считая что вот теперь-то у нас наконец-то стабильный поиск. А когда привыкаешь к низким числам в этой статистике, оглядываешься на старые показатели и думаешь, «вот ужас-то был».
При этом GC на бэкендах будет возникать в разное время, тем самым неполные результаты будут возвращаться не с частотой запуска GC на одном бэкенде, а помноженное на общее количество бэкендов, Когда их число начинает быть кратным сотням это становится существенным.
Поэтому служебные действия на бэкендах правильно выполнять синхронно, минимизируя общее время, когда кластер отвечает неполно. В это время можно жить на кеше, можно использовать второй кластер (если он есть) для подстраховки.
Но насколько я знаю, если такие вещи пишут на Java, то вообще пытаются не полагаться на собственный аллокатор, чтобы не бороться с GC. Выделяют памяти от пуза и уже работают с ней самостоятельно. Но я тут как раз перестаю понимать, зачем пользоваться Java, когда C/C++ есть :)
Вообщем, является ли это глобальной проблемой при использовании nutch, которая никак не решилась в вашем случае?
Да мы Nutch не использовали, мы своё писали. И у нас была такая мысль, сделать выкачку на том же кластере, что и всё остальное, «раз платформа есть». Но я просто считаю, что если задача хорошо и просто отделяется, отличается от остальных задач, то её нужно отделять. Выкачка, как я написал выше, очень специфична, ей требуются другие ресурсы. И, в общем, ни разу об этом решении не пожалели.
А то ведь и сёрчеры тоже можно как-нибудь на Hadoop'е запустить, в принципе.
Про то, что энграммы (или биграммы в простейшем случае) нужно строить хитро если обьемы большие это понятно. Не понятно почему вы сделали вывод, что этого нельзя сделать в Lucene. Вообще, возможности кастомизации анализа текста в Lucene очень гибкие (как компоновкой существующих tokenizer/tokenfilter так и написанием своих компонент).
Про интерактивные приложения и GC — я не говорю про то, что нужно отказаться от мониторинга/оптимизации GC совсем, только что это не так критично как думают «java is slow» адепты.
На fetcher кластере все равно нужно
а) сохранять скачанное (в hdfs/hbase?)
b) как-то помечать что скачано/что нет (в hbase?)
Вообщем, мне не понравилось резкость вывода «отрицательный пример» без подробного и вдумчивого анализа. А вообще, правильный способ был бы начать обсуждение в Nutch мэйлинг листе со всеми вашими опасениями и в идеале засабмитить патч (open source way так сказать).
Про интерактивные приложения и GC — я не говорю про то, что нужно отказаться от мониторинга/оптимизации GC совсем, только что это не так критично как думают «java is slow» адепты.
На fetcher кластере все равно нужно
а) сохранять скачанное (в hdfs/hbase?)
b) как-то помечать что скачано/что нет (в hbase?)
Вообщем, мне не понравилось резкость вывода «отрицательный пример» без подробного и вдумчивого анализа. А вообще, правильный способ был бы начать обсуждение в Nutch мэйлинг листе со всеми вашими опасениями и в идеале засабмитить патч (open source way так сказать).
Не понятно почему вы сделали вывод, что этого нельзя сделать в Lucene. Вообще, возможности кастомизации анализа текста в Lucene очень гибкие (как компоновкой существующих tokenizer/tokenfilter так и написанием своих компонент).
Я же написал — сильная сторона Lucene это API. Сделать через него можно многое, но меня же интересовала конечная архитектура, а не конструктор. Вот реализации того, что я сказал, там же нет? То есть, если я знаю как, я могу это сделать в Lucene. Но знакомятся с чужими проектами для того, чтобы найти новые идеи, посмотреть, как это делается.
Про интерактивные приложения и GC — я не говорю про то, что нужно отказаться от мониторинга/оптимизации GC совсем, только что это не так критично как думают «java is slow» адепты.
Алексей, заметьте, это вы написали про GC впервые, а не я. Я же как раз и сказал, что это не так критично, но C/C++ мне кажется в этом месте логичнее.
На fetcher кластере все равно нужно
а) сохранять скачанное (в hdfs/hbase?)
b) как-то помечать что скачано/что нет (в hbase?)
Нет, это как раз уже вычислительные задачи в моём понимании, т.е. это не «фетчер-кластер», а обычный HBase.
Вообщем, мне не понравилось резкость вывода «отрицательный пример» без подробного и вдумчивого анализа.
Это, конечно, отрицательный пример и Вы меня не переубедили. Выше в обсуждении я написал, почему я так думаю — про расход ресурсов, про иные потребности задач.
А вообще, правильный способ был бы начать обсуждение в Nutch мэйлинг листе со всеми вашими опасениями и в идеале засабмитить патч (open source way так сказать).
Я же говорю, Nutch мы не используем и он нам не подходит, поэтому обсуждать и, тем более, патчить было бы для нас лишней потерей времени.
Мы используем HBase и там, да, мы и обсуждаем, и патчим. Вот пример самого эпического патча, повышающего скорость сканов с фильтрами и «перекошенными» по составу колонками в 10-20 раз: issues.apache.org/jira/browse/HBASE-5416. Это полгода тестирования, между прочим, хождения по самым разным граблям. Но это действительно полезный патч, на мой взгляд.
Я же написал — сильная сторона Lucene это API. Сделать через него можно многое, но меня же интересовала конечная архитектура, а не конструктор. Вот реализации того, что я сказал, там же нет? То есть, если я знаю как, я могу это сделать в Lucene. Но знакомятся с чужими проектами для того, чтобы найти новые идеи, посмотреть, как это делается.
Про интерактивные приложения и GC — я не говорю про то, что нужно отказаться от мониторинга/оптимизации GC совсем, только что это не так критично как думают «java is slow» адепты.
Алексей, заметьте, это вы написали про GC впервые, а не я. Я же как раз и сказал, что это не так критично, но C/C++ мне кажется в этом месте логичнее.
На fetcher кластере все равно нужно
а) сохранять скачанное (в hdfs/hbase?)
b) как-то помечать что скачано/что нет (в hbase?)
Нет, это как раз уже вычислительные задачи в моём понимании, т.е. это не «фетчер-кластер», а обычный HBase.
Вообщем, мне не понравилось резкость вывода «отрицательный пример» без подробного и вдумчивого анализа.
Это, конечно, отрицательный пример и Вы меня не переубедили. Выше в обсуждении я написал, почему я так думаю — про расход ресурсов, про иные потребности задач.
А вообще, правильный способ был бы начать обсуждение в Nutch мэйлинг листе со всеми вашими опасениями и в идеале засабмитить патч (open source way так сказать).
Я же говорю, Nutch мы не используем и он нам не подходит, поэтому обсуждать и, тем более, патчить было бы для нас лишней потерей времени.
Мы используем HBase и там, да, мы и обсуждаем, и патчим. Вот пример самого эпического патча, повышающего скорость сканов с фильтрами и «перекошенными» по составу колонками в 10-20 раз: issues.apache.org/jira/browse/HBASE-5416. Это полгода тестирования, между прочим, хождения по самым разным граблям. Но это действительно полезный патч, на мой взгляд.
Извините за оффтоп, но давно хотел спросить у представителей Поискаmail.ru, как вы относитесь к тому что ваш Браузер и Спутник распространяется с помощью вирусов, подписанных вашей цифровой подписью, это Ваша политика дистрибуции?
Конечно, нет.
Пришлите мне, пожалуйста, на kalinin@corp.mail.ru, откуда Вы скачали наши продукты с вирусами.
Пришлите мне, пожалуйста, на kalinin@corp.mail.ru, откуда Вы скачали наши продукты с вирусами.
Куча платных архивов (да-да, те которые раскрываются за смс) ставят тулбар, многие даже без галочек.
Добрый день! Вот пример сайта откуда можно скачать екзе, подписанный подписью майл ру, который ставит браузер и тулбар. Ранее еще ставил игровой центр.
skan.ru/software/n10590_flv_converter.html кликаете на кнопочку «Скачать FLV Converter» далее через сайт Loadmoney.ru вас перекидывает на сервера майл ру откуда качается файл, подписанный подписью майл ру, при этом определяющийся многими АВ компаниями — как вирус. Пример скана с вирустотала:
www.virustotal.com/file/eafad56e117823e9961551c2ff05742051e39d9c86d995685fff5264537faec0/analysis/
Да, обратите внимание, как завуалированы галочки на этом «загрузчике от майл ру». Кроме того — ставится одновременно и тулбар и ваш «браузер», который обвешивает ярлыками пол рабочего стола — с различными «полезными сервисами от майл ру». Забавно…
P.S. А потом появляются статьи на роеме вида roem.ru/2012/08/14/mailfalsealarm52810/
skan.ru/software/n10590_flv_converter.html кликаете на кнопочку «Скачать FLV Converter» далее через сайт Loadmoney.ru вас перекидывает на сервера майл ру откуда качается файл, подписанный подписью майл ру, при этом определяющийся многими АВ компаниями — как вирус. Пример скана с вирустотала:
www.virustotal.com/file/eafad56e117823e9961551c2ff05742051e39d9c86d995685fff5264537faec0/analysis/
Да, обратите внимание, как завуалированы галочки на этом «загрузчике от майл ру». Кроме того — ставится одновременно и тулбар и ваш «браузер», который обвешивает ярлыками пол рабочего стола — с различными «полезными сервисами от майл ру». Забавно…
P.S. А потом появляются статьи на роеме вида roem.ru/2012/08/14/mailfalsealarm52810/
PPS: Продублировал сообщение вам на почту.
Конечно же это не они. Обязательно с этим разберутся. Не переживайте.
Это наша большая головная боль.
Дело в том, что этот файл, на котором срабатывают некоторые антивирусы — это наш загрузчик, он и подписан нашей цифровой подписью. И вирусов там нет.
Вы посмотрите, что они там детектят, это всё эвристики проактивной защиты. Например, McAfee определяет его как Artemis с какой-то контрольной суммой, т.е. это срабатывание эвристики + контрольная сумма файла, на котором она сработала, вот тут у них больше полутысячи жалоб на неё: community.mcafee.com/community/security/malware_discussion/artemis?view=discussions
Некоторые пишут что это Downloader — это, в общем, справедливо; он действительно дальше скачивает тот файл, который нужно загрузить. Но это не вирус, не троянский конь.
С антивирусными компаниями мы общаемся, с некоторыми всё удачно проходит, а некоторые демонстрируют тут какую-то отмороженность, заявляя просто что они нас не любят и поэтому будут срабатывать и дальше. В некотором смысле, это всё те же элементы браузерных войн.
Дело в том, что этот файл, на котором срабатывают некоторые антивирусы — это наш загрузчик, он и подписан нашей цифровой подписью. И вирусов там нет.
Вы посмотрите, что они там детектят, это всё эвристики проактивной защиты. Например, McAfee определяет его как Artemis с какой-то контрольной суммой, т.е. это срабатывание эвристики + контрольная сумма файла, на котором она сработала, вот тут у них больше полутысячи жалоб на неё: community.mcafee.com/community/security/malware_discussion/artemis?view=discussions
Некоторые пишут что это Downloader — это, в общем, справедливо; он действительно дальше скачивает тот файл, который нужно загрузить. Но это не вирус, не троянский конь.
С антивирусными компаниями мы общаемся, с некоторыми всё удачно проходит, а некоторые демонстрируют тут какую-то отмороженность, заявляя просто что они нас не любят и поэтому будут срабатывать и дальше. В некотором смысле, это всё те же элементы браузерных войн.
Андрей, получается так, что вы, как бы, ни при делах, это все партнеры гадят, но ведь неправда, что вы никак не способствуете распространению этого треша.
Создается партнерская программа, которая оказывается порою выгоднее, чем распространение всяких вирусов:
forum.searchengines.ru/showthread.php?t=709778
forum.searchengines.ru/showthread.php?t=709778&page=28
forum.searchengines.ru/showthread.php?t=709778&page=61
И какие-то люди обсуждают, почему антивирусы на ваш софт ругаются. Да правильно ругаются — там куча PUA, нарушаются все правила и лицензии. Еще отчетливо видно, что эти люди — спамеры, манимейкеры… «Палево, конверт, траф»… это все очень дурно пахнет. И Вы-то понимаете, что это такое.
Кроме того, есть куча «софт-порталов», где ссылки на скачивание файла ведут не на сам дистрибутив непосредственно, а на некий «download manager». Сперва пользователю устанавливается download manager, по сути дублирующий функционал закачки браузера, который затем скачивает запрошенный файл (а файл не всегда именно то, что вы хотели).
Как только вы скачиваете и запускаете download manager, в вашем ПК появятся Спутник и Защитник от мейл.ру, при этом никаких галочек — соглашений про установку дополнительного софта, у пользователя не спрашивают.
Т.о. download manager от Mail.ru не предоставляет пользователю никакого дополнительного полезного функционала, единственная цель его существования — поставить Спутник и Защитник от мейл.ру. На софт, который распространяется с помощью этого де-факто никаких ограничений не накладывается, т.е. это могут быть крякнутые официальные программы, ключи для анлока Win7 и т.п.
Очевидно, что вы потворствуете созданию огромного количества псевдосайтов, которые предлагают что-то такое скачать. Они низкого качества, с ними рядом ходит всякое мошенничество типа платных смс-архивов и т.п. И если вам кажется, что вы делаете что-то хорошее (типа, школота не вирусы распространяет, а безобидный mail.ru), то вы ошибаетесь. Те же люди, которые участвуют в ваших партнерках, набравшись опыта и заработав денег, через некоторое время все засрут. Экология нарушается, мошенничества становится все больше. Вам это надо? Или плевать на все, лишь бы сейчас бабок срубить, а что после нас хоть потоп? Зачем же так гадить, Андрей?
Создается партнерская программа, которая оказывается порою выгоднее, чем распространение всяких вирусов:
forum.searchengines.ru/showthread.php?t=709778
forum.searchengines.ru/showthread.php?t=709778&page=28
forum.searchengines.ru/showthread.php?t=709778&page=61
И какие-то люди обсуждают, почему антивирусы на ваш софт ругаются. Да правильно ругаются — там куча PUA, нарушаются все правила и лицензии. Еще отчетливо видно, что эти люди — спамеры, манимейкеры… «Палево, конверт, траф»… это все очень дурно пахнет. И Вы-то понимаете, что это такое.
Кроме того, есть куча «софт-порталов», где ссылки на скачивание файла ведут не на сам дистрибутив непосредственно, а на некий «download manager». Сперва пользователю устанавливается download manager, по сути дублирующий функционал закачки браузера, который затем скачивает запрошенный файл (а файл не всегда именно то, что вы хотели).
Как только вы скачиваете и запускаете download manager, в вашем ПК появятся Спутник и Защитник от мейл.ру, при этом никаких галочек — соглашений про установку дополнительного софта, у пользователя не спрашивают.
Т.о. download manager от Mail.ru не предоставляет пользователю никакого дополнительного полезного функционала, единственная цель его существования — поставить Спутник и Защитник от мейл.ру. На софт, который распространяется с помощью этого де-факто никаких ограничений не накладывается, т.е. это могут быть крякнутые официальные программы, ключи для анлока Win7 и т.п.
Очевидно, что вы потворствуете созданию огромного количества псевдосайтов, которые предлагают что-то такое скачать. Они низкого качества, с ними рядом ходит всякое мошенничество типа платных смс-архивов и т.п. И если вам кажется, что вы делаете что-то хорошее (типа, школота не вирусы распространяет, а безобидный mail.ru), то вы ошибаетесь. Те же люди, которые участвуют в ваших партнерках, набравшись опыта и заработав денег, через некоторое время все засрут. Экология нарушается, мошенничества становится все больше. Вам это надо? Или плевать на все, лишь бы сейчас бабок срубить, а что после нас хоть потоп? Зачем же так гадить, Андрей?
О, Яндекс.
Понимаю.
Сергей, привет!
Как только вы скачиваете и запускаете download manager, в вашем ПК появятся Спутник и Защитник от мейл.ру, при этом никаких галочек — соглашений про установку дополнительного софта, у пользователя не спрашивают.
Неправда.
Остальной плач Ярославны я комментировать не хочу, этическая истерика она такая, бороться с ней себе дороже. Ну что мне сказать тебе, что за партнёрами следят, их отстреливают, и что нам тоже это не надо, боремся с этим?
Или что каналы дистрибуции не резиновые, и если что-то занял Яндекс или Гугл, то никому туда больше не попасть?
Но ты же ведь уже вывод сделал:
Вам это надо? Или плевать на все, лишь бы сейчас бабок срубить, а что после нас хоть потоп? Зачем же так гадить, Андрей?
И вот только Яндекс, весь в белом…
Сергей, в общем, не хочу я устраивать тут срач между двумя компаниями. Вам всё мешает: Гугл мешает (см. интервью, которое я процитировал выше), Mail.Ru мешает, вы этими двумя компаниями недовольны. Ну и хорошо, лично я бы очень сильно бы напрягся, если бы ты нас похвалил.
Понимаю.
Сергей, привет!
Как только вы скачиваете и запускаете download manager, в вашем ПК появятся Спутник и Защитник от мейл.ру, при этом никаких галочек — соглашений про установку дополнительного софта, у пользователя не спрашивают.
Неправда.
Остальной плач Ярославны я комментировать не хочу, этическая истерика она такая, бороться с ней себе дороже. Ну что мне сказать тебе, что за партнёрами следят, их отстреливают, и что нам тоже это не надо, боремся с этим?
Или что каналы дистрибуции не резиновые, и если что-то занял Яндекс или Гугл, то никому туда больше не попасть?
Но ты же ведь уже вывод сделал:
Вам это надо? Или плевать на все, лишь бы сейчас бабок срубить, а что после нас хоть потоп? Зачем же так гадить, Андрей?
И вот только Яндекс, весь в белом…
Сергей, в общем, не хочу я устраивать тут срач между двумя компаниями. Вам всё мешает: Гугл мешает (см. интервью, которое я процитировал выше), Mail.Ru мешает, вы этими двумя компаниями недовольны. Ну и хорошо, лично я бы очень сильно бы напрягся, если бы ты нас похвалил.
В этом смысле вас хвалить не за что.
Вот пример неправды, кстати: nero-free.ru/ — инсталл за смс, даже в случае отмены установки без предупреждения устанавливает полный набор от мейл.ру. Очевидно, вам невыгодно отстреливать таких замечательных партнеров :) Или вот: icqskype.com/8-skajp-skachat.html И таких — тьма. Если мы вам пришлем списочек таких сайтов — откажетесь от их услуг?
Кстати, я вообще из антиспама, я дистрибуцией не занимаюсь. Просто вижу, что плодится большое количество говносайтов специально под ваши партнерки. И если вам от этого польза, то — это временно.
Что касается каналов дистрибуции… Это как идти расклеивать объявления на столбах, остановках, в метро, электричках и в других неподходящих местах, засирая все вокруг, оправдываясь тем, что на более приличную работу ты не устроился.
Вот пример неправды, кстати: nero-free.ru/ — инсталл за смс, даже в случае отмены установки без предупреждения устанавливает полный набор от мейл.ру. Очевидно, вам невыгодно отстреливать таких замечательных партнеров :) Или вот: icqskype.com/8-skajp-skachat.html И таких — тьма. Если мы вам пришлем списочек таких сайтов — откажетесь от их услуг?
Кстати, я вообще из антиспама, я дистрибуцией не занимаюсь. Просто вижу, что плодится большое количество говносайтов специально под ваши партнерки. И если вам от этого польза, то — это временно.
Что касается каналов дистрибуции… Это как идти расклеивать объявления на столбах, остановках, в метро, электричках и в других неподходящих местах, засирая все вокруг, оправдываясь тем, что на более приличную работу ты не устроился.
Вот пример неправды, кстати: nero-free.ru/ — инсталл за смс, даже в случае отмены установки без предупреждения устанавливает полный набор от мейл.ру. Очевидно, вам невыгодно отстреливать таких замечательных партнеров :) Или вот: icqskype.com/8-skajp-skachat.html И таких — тьма. Если мы вам пришлем списочек таких сайтов — откажетесь от их услуг?
Присылай, конкретика меня интересует. Проверим, а там либо предупредим, либо откажемся. Моя почта у тебя есть, но всё равно: kalinin@corp.mail.ru
Что касается каналов дистрибуции… Это как идти расклеивать объявления на столбах, остановках, в метро, электричках и в других неподходящих местах, засирая все вокруг, оправдываясь тем, что на более приличную работу ты не устроился.
Смотри, устроить этическую истерику можно по любому поводу. Например.
Вот вы ставите тулбар с uTorrent'ом. Для чего используется uTorrent? Что через него качают? Вы, значит, поддерживаете пиратов, крекеров и далее по списку того, что там лежит?
И какой дополнительный функционал несёт с собой тулбар, который ставится пользователю?
Ну это я так, без надрыва — просто наметил, прошёлся по твоему списку.
Но факт остаётся фактом, лидер занимает самые лучшие места, потому что пришёл первым. В России лучшие места заняты Яндексом, а в мире, между прочим, Гуглом. И Волож, к примеру, утверждает, что это недобросовестная конкуренция со стороны Гугла, не пускать туда никого, кроме себя.
А работа мне моя нравится, тут интересно.
Присылай, конкретика меня интересует. Проверим, а там либо предупредим, либо откажемся. Моя почта у тебя есть, но всё равно: kalinin@corp.mail.ru
Что касается каналов дистрибуции… Это как идти расклеивать объявления на столбах, остановках, в метро, электричках и в других неподходящих местах, засирая все вокруг, оправдываясь тем, что на более приличную работу ты не устроился.
Смотри, устроить этическую истерику можно по любому поводу. Например.
Вот вы ставите тулбар с uTorrent'ом. Для чего используется uTorrent? Что через него качают? Вы, значит, поддерживаете пиратов, крекеров и далее по списку того, что там лежит?
И какой дополнительный функционал несёт с собой тулбар, который ставится пользователю?
Ну это я так, без надрыва — просто наметил, прошёлся по твоему списку.
Но факт остаётся фактом, лидер занимает самые лучшие места, потому что пришёл первым. В России лучшие места заняты Яндексом, а в мире, между прочим, Гуглом. И Волож, к примеру, утверждает, что это недобросовестная конкуренция со стороны Гугла, не пускать туда никого, кроме себя.
А работа мне моя нравится, тут интересно.
И какой дополнительный функционал несёт с собой тулбар, который ставится пользователю?
Ага, и что там с пополнением поискового индекса (урлов) шпионской программой тулбар? Или метрикой? Чем там закончилась эпопея?
Ага, и что там с пополнением поискового индекса (урлов) шпионской программой тулбар? Или метрикой? Чем там закончилась эпопея?
Интересно, как майл ру всегда в подобного рода вопросах переводит стрелки на конкурентов :)
Даже если не брать во внимание то, что яндекс ставит ТОЛЬКО свой тулбар, а Майл ру навязывает 1. тулбар 2. браузер и да, при старте системы ПОСТОЯННО открывает IE со своей стартовой — что очень сильно тормозит загрузку в целом. А при открытии других браузеров вместо одной стартовой открывается ТРИ! И все — майл ру или же одноклассники. Дак вот даже если не брать это во внимание — просто сравните как ставятся «сервисы» от майл ру и от яндекса:
Яндекс
s2.ipicture.ru/uploads/20120828/ro7Kc641.jpg
Маил
s2.ipicture.ru/uploads/20120828/VkDVNPMX.jpg
Разница видна невооруженным глазом. И да — все дело — именно в СТЕПЕНИ навязываемости, которая у майл ру просто зашкаливает.
Даже если не брать во внимание то, что яндекс ставит ТОЛЬКО свой тулбар, а Майл ру навязывает 1. тулбар 2. браузер и да, при старте системы ПОСТОЯННО открывает IE со своей стартовой — что очень сильно тормозит загрузку в целом. А при открытии других браузеров вместо одной стартовой открывается ТРИ! И все — майл ру или же одноклассники. Дак вот даже если не брать это во внимание — просто сравните как ставятся «сервисы» от майл ру и от яндекса:
Яндекс
s2.ipicture.ru/uploads/20120828/ro7Kc641.jpg
Маил
s2.ipicture.ru/uploads/20120828/VkDVNPMX.jpg
Разница видна невооруженным глазом. И да — все дело — именно в СТЕПЕНИ навязываемости, которая у майл ру просто зашкаливает.
Интересно, как майл ру всегда в подобного рода вопросах переводит стрелки на конкурентов :)
Конкуренты сами пришли. :)
Разница видна невооруженным глазом.
Ну, обычно оно всё-таки иначе выглядит, как-то так: s2.ipicture.ru/uploads/20120828/9ND7mR32.png
По кликам идентично, два клика у нас, два клика у Яндекса.
По составу, наш вариант на этом скриншоте, более сильный, да. Мы конечно будем дальше экспериментировать, чтобы он устанавливался более целенаправленно.
PS. Про автоматическое открытие браузера — это не мы, это у Вас кто-то другой его открывает.
Конкуренты сами пришли. :)
Разница видна невооруженным глазом.
Ну, обычно оно всё-таки иначе выглядит, как-то так: s2.ipicture.ru/uploads/20120828/9ND7mR32.png
По кликам идентично, два клика у нас, два клика у Яндекса.
По составу, наш вариант на этом скриншоте, более сильный, да. Мы конечно будем дальше экспериментировать, чтобы он устанавливался более целенаправленно.
PS. Про автоматическое открытие браузера — это не мы, это у Вас кто-то другой его открывает.
Мне вот интересно — я читаю вашу статью — и вижу там одну манеру общения. Читаю ваши посты — и вижу тут совсем другое :) Это так за вас через ваши уста кто то передает «политику» компании?
И да — по поводу скрина — да есть и такой вариант установки яндекс бара. Но согласитесь, он куда более честный, чем какая то малозаметная стрелочка у вас.
P.S. И да — хватит уже выгораживать компанию, где вы работаете. Вы ниже сами сказали — что не видите другого способа достучаться до вашего пользователя. А не видите потому — что вы думаете ТОЛЬКО о деньгах, и вам нужно отжать все очень быстро, и с минимальными вложениями. Вот и устроили такой балаган с дистрибьюцией. Вместо того чтобы развивать сервисы, и ЖДАТЬ пока люди сами к вам придут ПОСТЕПЕННО, вы решили действовать агрессивно, не думая о последствиях. Но они будут. Обязательно =)
А насчет интернет експлорера — я думаю было бы странно, если бы его кто то открывал кроме вас, на вашей стартовой. Кому это нужно? И это не только на моей машине. Хватит врать.
И да — по поводу скрина — да есть и такой вариант установки яндекс бара. Но согласитесь, он куда более честный, чем какая то малозаметная стрелочка у вас.
P.S. И да — хватит уже выгораживать компанию, где вы работаете. Вы ниже сами сказали — что не видите другого способа достучаться до вашего пользователя. А не видите потому — что вы думаете ТОЛЬКО о деньгах, и вам нужно отжать все очень быстро, и с минимальными вложениями. Вот и устроили такой балаган с дистрибьюцией. Вместо того чтобы развивать сервисы, и ЖДАТЬ пока люди сами к вам придут ПОСТЕПЕННО, вы решили действовать агрессивно, не думая о последствиях. Но они будут. Обязательно =)
А насчет интернет експлорера — я думаю было бы странно, если бы его кто то открывал кроме вас, на вашей стартовой. Кому это нужно? И это не только на моей машине. Хватит врать.
Ооо да, особенно вот тут, ага
Особенно вот тут, ага
А вы тоже в Mail.ru работаете, если не секрет?
Пока нет, но все надеюсь. А вы?
Вообще, мне тоже временами казалось, что активные участники этого треда имеют какое-то отношение к Яндексу.
Но это не так. Вот NFM, к примеру, судя по всему был организатором своих партнёрских программ: forum.searchengines.ru/showthread.php?p=5490475#post5490475
forum.searchengines.ru/showthread.php?p=6149319#post6149319
Ну, т.е., скорее всего, конкурент той партнёрки, на сайты которой он жаловался.
А сейчас занимается, сложно в это поверить, распространением своего тулбара: forum.searchengines.ru/showthread.php?t=658686
(nicetest — название старой партнёрки)
Тот ещё серпентарий, в общем.
Но это не так. Вот NFM, к примеру, судя по всему был организатором своих партнёрских программ: forum.searchengines.ru/showthread.php?p=5490475#post5490475
forum.searchengines.ru/showthread.php?p=6149319#post6149319
Ну, т.е., скорее всего, конкурент той партнёрки, на сайты которой он жаловался.
А сейчас занимается, сложно в это поверить, распространением своего тулбара: forum.searchengines.ru/showthread.php?t=658686
(nicetest — название старой партнёрки)
Тот ещё серпентарий, в общем.
Так расклейщикам объявлений, может, тоже интересно. А вот жителям города уже не очень… Ну что ж, твой выбор :)
Вот несколько примеров:
win-planet.com/office/17-skachat-microsoft-office-2010-na-russkom-yazyke-besplatno.html
sozdanie-prezentacii.ru/
photoshop-adobe.com/
antivirus-ok.com/index.php/antivirus-kaspersky
nero-10.ru/
download-powerpoint.programma-free.ru/
hdfile.ru/810-microsoft-office-full.html
down-office.ru/
office.programmatut.ru/
download-powerpoint.com/
+ распространение установщика mail.ru под видом другого ПО — openprog.ru/opera
Интересно, что с ними станет недели через две :)
Вот несколько примеров:
win-planet.com/office/17-skachat-microsoft-office-2010-na-russkom-yazyke-besplatno.html
sozdanie-prezentacii.ru/
photoshop-adobe.com/
antivirus-ok.com/index.php/antivirus-kaspersky
nero-10.ru/
download-powerpoint.programma-free.ru/
hdfile.ru/810-microsoft-office-full.html
down-office.ru/
office.programmatut.ru/
download-powerpoint.com/
+ распространение установщика mail.ru под видом другого ПО — openprog.ru/opera
Интересно, что с ними станет недели через две :)
Openprog.ru как мы видим по ссылке ниже, принадлежит админам партнерской программы которая реселит mail.ru всем желающим вебмастерам.
forum.searchengines.ru/showpost.php?p=10779540&postcount=601
forum.searchengines.ru/showpost.php?p=10779540&postcount=601
Я ссылки передал, спасибо.
Вы сами вебмастерам и платным архивам дали реселить Спутник и Браузер, а теперь передаете ссылки на проверку? Вам не кажется, что это смешно?))
У нас есть требования к партнёрам, если они их не выполняют — мы с ними прекращаем работать. Партнёрскую сеть мы проверяем, а так же разбираемся по жалобам.
И да, про вас же уже давно статьи на дрвебе пишут, и про этот openprog и loadmoney. Почитайте: www.ferra.ru/ru/soft/news/2012/08/22/drweb-ZIPPRO/
www.ferra.ru/ru/soft/news/2012/08/15/drweb-Trojan-Mayachok-1/
Как вообще майл мог докатиться до того, чтобы распространяться ВООБЩЕ без галочек да еще и с БАНКОВСКИМИ ТРОЯНАМИ. Какие черту жалобы? Статьи вон пачками в интернете валяются. Кругом репосты. Погуглите.
www.ferra.ru/ru/soft/news/2012/08/15/drweb-Trojan-Mayachok-1/
Как вообще майл мог докатиться до того, чтобы распространяться ВООБЩЕ без галочек да еще и с БАНКОВСКИМИ ТРОЯНАМИ. Какие черту жалобы? Статьи вон пачками в интернете валяются. Кругом репосты. Погуглите.
Очень интересно. Ждем продолжения.
да у вас поиск от яндекса, о чём вы вообще?
Ваш ник говорит сам за себя. Давай,… ну вы поняли.
Там в начале ссылка на предыдущий пост, где написано про то, как и когда у нас появился поиск.
Поиск от Яндекса был до 1-го января 2010-го года.
Потом был наш поиск.
Потом комбинация нашего поиска и поиска от Google.
В общем, мы всех запутали, но поиск у нас есть, о нём и рассказываю.
Поиск от Яндекса был до 1-го января 2010-го года.
Потом был наш поиск.
Потом комбинация нашего поиска и поиска от Google.
В общем, мы всех запутали, но поиск у нас есть, о нём и рассказываю.
UFO just landed and posted this here
Я описал причины существования и распространения Спутника в начале статьи.
Он нужен как минимум в виде ответа на тулбары других компаний.
Он нужен как минимум в виде ответа на тулбары других компаний.
UFO just landed and posted this here
Я Вас понимаю.
Но дело в том, что качеством продукта новых пользователей привлечь нельзя. Качество — это то, что оставляет пользователей у сервиса. То есть, сервис хороший, пользователю понравился, он остался на нём. Сервис не понравился, не привычен — пользователь сбежал.
Но для того, чтобы этот процесс запустить, пользователь должен увидеть сервис. И вот эта задача для поисковиков и порталов решается, к сожалению, тулбарами и браузерами. Почему так получилось, я написал в статье.
Для Mail.Ru же здесь довольно интересно — нас не воспринимают (не воспринимали?) как поиск. Средний пользователь РуНета пользуется почтой Mail.Ru и поиском Яндекса. Но люди банально не видят у нас поисковой строчки, не замечают её. Хотя по суммарной аудитории Mail.Ru и Яндекс примерно одинаковы. Как дать людям возможность понять, что у нас есть поиск тогда?
Но дело в том, что качеством продукта новых пользователей привлечь нельзя. Качество — это то, что оставляет пользователей у сервиса. То есть, сервис хороший, пользователю понравился, он остался на нём. Сервис не понравился, не привычен — пользователь сбежал.
Но для того, чтобы этот процесс запустить, пользователь должен увидеть сервис. И вот эта задача для поисковиков и порталов решается, к сожалению, тулбарами и браузерами. Почему так получилось, я написал в статье.
Для Mail.Ru же здесь довольно интересно — нас не воспринимают (не воспринимали?) как поиск. Средний пользователь РуНета пользуется почтой Mail.Ru и поиском Яндекса. Но люди банально не видят у нас поисковой строчки, не замечают её. Хотя по суммарной аудитории Mail.Ru и Яндекс примерно одинаковы. Как дать людям возможность понять, что у нас есть поиск тогда?
Для Mail.Ru же здесь довольно интересно — нас не воспринимают (не воспринимали?) как поиск. Средний пользователь РуНета пользуется почтой Mail.Ru и поиском Яндекса. Но люди банально не видят у нас поисковой строчки, не замечают её. Хотя по суммарной аудитории Mail.Ru и Яндекс примерно одинаковы. Как дать людям возможность понять, что у нас есть поиск тогда?
Взгляните на ya.ru — там только поиск, может и вам стоит что-то похожее придумать )
А у нас есть: go.mail.ru/
История с дистрибуцией действительно печальная. Выход-то есть? Или «смотрите что ставите, дорогие юзеры», а поисковики так и будут использовать все способы заполучить малограмотную аудиторию?
Выход, судя по всему, не за горами.
Во-первых, меняются платформы. PC с Windows в его текущем виде это, всё же, профессиональный инструмент. Пользователю, которому нужно ограниченное количество программ он в таком виде не требуется, смартфоны и планшеты с централизированным способом установки стороннего ПО уже удовлетворяют нужды обычных пользователей.
А в этих платформах всё значительно жёстче, там уже не производитель браузера, а производитель платформы контроллирует поставщика поиска. В iOS в Safari поиск может быть любым, если это Google, Yahoo или Bing. То есть, новая версия Windows, новый способ установки ПО — и всё, все сидят на Bing'е (но это я утрирую, как раз Microsoft'у могут такого и не позволить сделать, монополист, «империя зла» и т.п.).
Во-вторых, меняется интерфейс поиска. Если посмотреть на тот же Siri, то можно заметить, что это, хоть и пока что не очень функциональный, но прототип «поиска будущего». Ты ему вопрос, а он тебе — ответ. И тогда уже само мобильное устройство превращается в поисковую систему, а что там внутри, в какой реальный поиск оно транслирует запрос, может быть и не очень важно, поисковик (в современном виде) превращаются в какую-то малопонятную деталь под капотом смартфона, куда никто не добирается.
И тогда «браузерные войны» превратятся уже в «войны платформ».
Во-первых, меняются платформы. PC с Windows в его текущем виде это, всё же, профессиональный инструмент. Пользователю, которому нужно ограниченное количество программ он в таком виде не требуется, смартфоны и планшеты с централизированным способом установки стороннего ПО уже удовлетворяют нужды обычных пользователей.
А в этих платформах всё значительно жёстче, там уже не производитель браузера, а производитель платформы контроллирует поставщика поиска. В iOS в Safari поиск может быть любым, если это Google, Yahoo или Bing. То есть, новая версия Windows, новый способ установки ПО — и всё, все сидят на Bing'е (но это я утрирую, как раз Microsoft'у могут такого и не позволить сделать, монополист, «империя зла» и т.п.).
Во-вторых, меняется интерфейс поиска. Если посмотреть на тот же Siri, то можно заметить, что это, хоть и пока что не очень функциональный, но прототип «поиска будущего». Ты ему вопрос, а он тебе — ответ. И тогда уже само мобильное устройство превращается в поисковую систему, а что там внутри, в какой реальный поиск оно транслирует запрос, может быть и не очень важно, поисковик (в современном виде) превращаются в какую-то малопонятную деталь под капотом смартфона, куда никто не добирается.
И тогда «браузерные войны» превратятся уже в «войны платформ».
>Подробнее о структуре нашего поисковика, о том, как мы строили поисковую систему, я расскажу в следующем посте.
если он уже вышел, сделайте пожалуйста ссылку в конце статьи
если он уже вышел, сделайте пожалуйста ссылку в конце статьи
В статье есть некоторая неточность.
Cassandra создана не по подобию BigTable, а по white-paper от Amazon о Dynamo DB.
Cassanda— Наверное все таки имелась ввиду Cassandra.
Cassandra создана не по подобию BigTable, а по white-paper от Amazon о Dynamo DB.
Спасибо, исправил.
Да, совершенно верно, но по-моему Dynamo можно считать родственником BigTable — а уж оттуда и родственность Кассандры. Там много отличий, но в целом для наших нужд теоретически подходили все такие решения, поэтому я их и упомянул вместе.
Cassandra создана не по подобию BigTable, а по white-paper от Amazon о Dynamo DB.
Да, совершенно верно, но по-моему Dynamo можно считать родственником BigTable — а уж оттуда и родственность Кассандры. Там много отличий, но в целом для наших нужд теоретически подходили все такие решения, поэтому я их и упомянул вместе.
Sign up to leave a comment.
Поиск@Mail.Ru, часть вторая: обзор архитектур подготовки данных больших поисковых систем