Pull to refresh
18
0
Алексей Серба @Aleksey

User

Send message
Интересно вы используете Zookeeper. В Сurator есть repices для всяких очередей, но большими буквами написано, что это нужно делать осторожно (не для большого количества сообщений и почему). См ZooKeeper makes a very bad Queue source. Вообще для задач схожих с вашей много раз слышал о Kafka.
Про то, что энграммы (или биграммы в простейшем случае) нужно строить хитро если обьемы большие это понятно. Не понятно почему вы сделали вывод, что этого нельзя сделать в Lucene. Вообще, возможности кастомизации анализа текста в Lucene очень гибкие (как компоновкой существующих tokenizer/tokenfilter так и написанием своих компонент).

Про интерактивные приложения и GC — я не говорю про то, что нужно отказаться от мониторинга/оптимизации GC совсем, только что это не так критично как думают «java is slow» адепты.

На fetcher кластере все равно нужно
а) сохранять скачанное (в hdfs/hbase?)
b) как-то помечать что скачано/что нет (в hbase?)

Вообщем, мне не понравилось резкость вывода «отрицательный пример» без подробного и вдумчивого анализа. А вообще, правильный способ был бы начать обсуждение в Nutch мэйлинг листе со всеми вашими опасениями и в идеале засабмитить патч (open source way так сказать).
И какой дополнительный функционал несёт с собой тулбар, который ставится пользователю?

Ага, и что там с пополнением поискового индекса (урлов) шпионской программой тулбар? Или метрикой? Чем там закончилась эпопея?
Тут и организация апдейтов, и failover и т.п.
Ничего стандартного в этом отношение пока нет, но скорее всего потому что условия у каждого разные. Solr Сloud использует ZooKeeper для хранения конфигурации кластера (шарды, лидеры, реплики) и leader election, ElasticSearch zero discovery с броадкастом и тд.

Как решена проблема стоп-слов в Lucene?
Можно выкидывать, можно сохранять, можно делать и то и то в разные поля и просто бустить результаты с точным совпадением включая стоп слова. Проблема цитатных запросов со стоп словами решается индексированием N-gram-ов (и соот-ей обработкой запроса в момент поиска). Рассказали бы про ваше хитрое решение — очень интересно.

но на поисковом кластере по-моему логичнее использовать C/C++. Потому что там оптимизация оправдывается, а её выполнять проще на этих языках.
Я слышал мнение, что задачу обьединения результатов поиска от разных shards и отдачу пользователю некоторые реализуют на C/C++ потому что паузы GC здесь очень критичны, паузы на самих же поисковых нодах можно просто игнорировать по таймауту и возвращать неполные результаты поиска.

Если один редьюсер хватает урлы одного сайта, то он будет качать их с паузами (он же «вежливый»?) и слот будет всё это время простаивать.
Насколько я понимаю один редьюсер держит различные очереди для каждого топ левел домена (или айпи) и обрабатывает их паралельно. Если же осталась одна очередь с медленным сайтом, то наверняка можно решить проблему таймаутами или какой-нибудь эвристикой (дропать или вообще выбирать урлы с учетом скорости сайта?) или уменьшением кол-ва страниц скачиваемых одним редьюсером / увеличением кол-ва редьюсеров. Вообщем, является ли это глобальной проблемой при использовании nutch, которая никак не решилась в вашем случае?
На самом деле, в самом Lucene реализовано не так много интересных решений, которые могла бы позаимствовать большая поисковая система по вебу, рассчитанная на миллиарды документов.
А чего не хватает если по существу? Или просто «Java/gc тормозит»?

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

Мы некоторое время анализировали такое решение, и в результате отказались от него. Пожалуй, для нас архитектура этого спайдера была интересна как, своего рода, «отрицательный пример».

Я так и не понял, вы отказались от этого решения потому что «вычислительные ресурсы клатера тратятся на то, чтобы он ждал ответа от чужого веб-сервера»? Как вы решили эту проблему — отказались от индексирования медленных сайтов вообще или решили тратить вычислительные ресурсы «другого» кластера?
Мы тоже используем ветку 1.9.x как раз из-за java gateway ootb.
Принято, особенно имеет смысл при использовании maven–а. Но тем не менее видел большое количество open source проектов в которых для удобства (и простоты настройки для новых разработчиков) файлы конфигурации _проекта_ находятся в репозитории. По моему это была бы показательная статистика популярности IDE.
Интересно было бы увидеть статистику по количеству open source-ых проектов (apache, github, google code, bitbucket, sourceforge) с включенными файлами проекта для Eclipse и Idea.
Не так давно услышал про mint, заинтересовался, есть ли что похожее в рунете, и нашел вашу статью. Молодцы! Печально конечно, что наши банки стандарт этот не хотят поддерживать. Представляю сколько времени и сил бы освободилось на анализ данных…
Хмм, сейчас столкнулся с проблемой синхронизации тайм зон в календаре. Если выставить вручную время, то календарь лажает со временем миитингов с буржуями. Неужто нет проще решения чем копаться внутрях?
Я периодически, когда надо лететь на дальние расстояния, сравниваю билеты на разных сервисах типа expedia, kayak, travelocity и по моим субьективным ощущениям expedia предлагает лучшие варианты (даже если ты букишь только перелет). Но у них к сожалению нет такой удобной возможности посмотреть когда билеты наиболее дешевые в пределах разумного интервала (у кого то есть такая возможность но только по штатам и не особо работает).

А что за начинания мэйла (речь идет о мэйлру?)?
Жалко пока не работает по всему миру, хотелось бы сравнить с Expedia и прочими.
Там вроде как эта бага может привести не только к крешу JVM, но так же может пострадать и данные, которые вы записываете (в данном случае битый индекс), что согласитесь не очень приятно. Теперь представьте, что вы распространяете java веб приложение в ввиде war архива и вам нужно настоятельно рекомендовать вашим пользователям отключать эти оптимизации циклов, иначе вы не несете гарантии за правильность работы вашего приложения. По моему серьезный геморрой для разработчиков, лучше бы задержали релиз и пофиксили.
> Такая практика как минимум неэтична.
Я бы даже сказал преступно.
Хорошая логика. Вот смотрите, вы пользуетесь gmail-ом и он вполне «открыто» хранит-анализирует вашу почту. Более того, даже контекстную рекламу вам показывает. А ну ка он выложит в публичный индекс — информации полезной ведь тоже полно там.

Я думаю никто бы не возражал, если бы они учитывали популярность страниц по статистики Бара только для тех документов которые были обнаружены обычными способами (читай паук, сайтмэп итд).
Попробуйте запостите на pastebin два вида поста — публичный и закрытые. Посмотрите отличаются ли чем-нибудь url-ы. Правильно — ничем кроме уникального хеша. Тем не менее публичные посты видны в листингах/каталогах и прекрасно индексируются поисковыми системами. Как вы предлагаете запрещать в robots.txt закрытые посты? Можно сказать конечно, что разработчики pastebin сами буратины, но я уверен что они даже подумать не могли что Гугл ТулБары или Яндекс Бары начнут шпионить и пополнять свой индекс таким образом. По моему это никому разумному в голову не может прийти. Поэтому мне все таки кажется, что Гугл таким не промыщляет, иначе давно скандал бы был.
Находить с помощью Яндекса Бара неизвестные пауку документы и индексировать их нельзя. Есть куча примеров с аутентификацией по хешу в урле начиная от pastebin (скрытые посты, которые не зная url никак не найти), picasa (временно расшаренные по хешу альбомы) и еще очень много всего.
Информировать это одно, а сливать в публичный доступ это другое.

Не секрет, что в интернете полно всячески динамически сгенеренных странниц с результатами поиска (читай дорвеи) и гугл мог вполне честно найти ссылки там. Тут правило действует, кто первый слил тот и бука. Я не знаю работает ли стабильно синтаксис поиска при котором можно получить все страницы, которые ссылаются на данную (link:http://leaked.page). Мои тесты показывают что такой синтаксис работает не всегда у гугла (может эскейпить надо как-то по хитрому), как у яндекса я не знаю. В любом случае Яндекс имеет эту информацию, но опровергать подозрения по поводу Бара-Метрики не хочет, видно есть что скрывать. Так что «Ату его!».
Было бы очень интересно почитать про практический опыт. Правильно ли я понимаю, что поста от вас так к сожалению и не было? Или это уже все разжевано где-то еще?

Information

Rating
Does not participate
Location
Санкт-Петербург и область, Россия
Date of birth
Registered
Activity