Okay

Да ладно. Простой паук который просто убирает HTML, примитивно токенизирует и обновляет индекс.

Проблема решить что качать, а не качать

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

Проблема решить что качать, а не качать

Ее нельзя решить наивно в пару строчек? У нас же нет требований о том, на сколько эффективно должен работать этот паук?

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

Как показывает практика, хотя бы на неделю в перед надо понимать что будет, иначе как-то совсем тоскливо

Как показывает практика, хотя бы на неделю в перед надо понимать что будет, иначе как-то совсем тоскливо

Неделя, месяц, два - это все условное «завтра».

Как показывает практика, хотя бы на неделю в перед надо понимать что будет, иначе как-то совсем тоскливо

неделя? для успешного бизнеса нужно понимать что будет через год и примерно представлять что начнется через 5. Иначе толка будет не очень много

Воу воу, палехче

Вы еще скажите что я не прав :)

Там где ставят такие задачи "Запили мне аналог гугла)" обычно не эджайл, для эджайла на первом этапе эта постановка вполне

Вы еще скажите что я не прав :)

зависит от проекта и страны базирования

неделя? для успешного бизнеса нужно понимать что будет через год и примерно представлять что начнется через 5. Иначе толка будет не очень много

Ну вот «прогрессивный» бизнес с тобой не согласен. Герман Оскарович на пример говорит, что сейчас среднее время жизни бизнеса сократилось до 4 лет. То есть за 4 года надо родиться, проферить модель, заработать денег и умереть.

Ну вот «прогрессивный» бизнес с тобой не согласен. Герман Оскарович на пример говорит, что сейчас среднее время жизни бизнеса сократилось до 4 лет. То есть за 4 года надо родиться, проферить модель, заработать денег и умереть.

Герман Оскарович знатный говорун :)

Но он прав

Ага) Зато тот же гугл наглядно показывает что можно говорить а что - делать :)

ну гугл свои проекты закрывает

примерно в такое время 3-4 года

может чуть больше

Это может и так, но сам гугл живет и закрываться не спешит)

Гугл плохой пример в плане проектов, очень плохой

эпл?)

Эпл, насильно застреливает старые проекты раз в 3-4 года

Хотя тут, смотря куда смотреть в железную сторону или софтовую

Запили мне аналог гугла)

Недавно видел ссылку на заказ , висевший на какой-то фриланс-бирже(какой не помню, но точно какая-то снгшная) - написать аналог prism под андроид, бюджет - 10к руб вроде

Смотреть в сторону бизнеса) Тот же интел - тоже уже который год существует)

Смотреть в сторону бизнеса) Тот же интел - тоже уже который год существует)

У вас не верный посыл, вы смотрите на компании которые являются единицами из миллиардов

Эплл или Гугл или Интел могут прямо сейчас остановиться и спокойно плыть еще десяток лет

Первая имеет одних резервов кеша больше бюджета этой страны

в сатанинском чате видел запрос сделать за 30к аналог призмы за 3-5 дней, пусть не очень хорошо, но лишь бы работало и было быстро и держало нагрузку

Не увидел) мб об одном и том же речь, но бюджет точно помню не превышал 10к

Не, я конечно понимаю что в каждом правиле есть исключения, но учитьс у тех кто является одними из многих - не самая удачная мысль как по мне. Стремиться нужно выйти за рамки. А это уже как раз тот самый гугл, эпл, интел и прочие)

касательно подкаста — как часто думаете делать?

Пока план раз в две недели.

Кто-нибудь использует akka-persistence-jdbc в продакшн?

мы думаем его использовать в качестве первого шага миграции на кассандру, так что вопрос тоже интересен

А почему сразу не взять касандру? она ведь идеально подходит под хранение подобных данных?

потому что будет слишком много изменений за один раз, и если что-то перестанет работать то поиск баги будет труден

Ээээ, ну вообще не важно поверх какого именно хранилища делать интеграцию akka-persistence, я конечно JDBC не проверял, но поверх cassandra у меня есть живой проект. За время работы были проблемы только непосредственно с кодом akka-persistence а не стем куда именно оно сладывает эвэнты

а какого рода проблемы были?

вызов persist внутри Future не работает :)

ну как и любой доступ к внутреннему стейту вне актора :)

да, это становится логично когда посмотришь в код под методом

но вот в доке они почему-то решили про это ничего не писать... хотя они в целом старательно обходят тему Future inside actors

насколько помню, в документации akka писали про то что из Future стейт не нужно менять, как и sender() из future использовать

Future в акторах без pipeTo очень короткий путь в бездну

Если сходить в гугл группу или их гиттер, то там раз в несколько дней вопросы про это возникают

Future в акторах без pipeTo очень короткий путь в бездну

скорее запутанный) искать такой баг неочевидно как-то

в бездну отладки ?

потому что будет слишком много изменений за один раз, и если что-то перестанет работать то поиск баги будет труден

стоит еще обратить внимание, на совместимость PersistentQuery, если будете их использовать. То что есть в jdbc может не быть в кассандре и наоборот

заявлено что akka-persistence-jdbc полностью реализует query API.

Да, не вопрос, но зная особенности касандры, я бы сказал что скорость работы тех или иных запросов может отличаться в разы

Да, не вопрос, но зная особенности касандры, я бы сказал что скорость работы тех или иных запросов может отличаться в разы

можно подробнее?

Интересно, насколько JDBC делает всё хуже в кассандре за счет того что потоки будут ждать ответа.

JDBC же всегда блокирует

можно подробнее?

Я не знаю что именно там за запросы, но из моего опыта жизни с касандрой - в ней нет вторичных индексов (я на практике не смотрел как работают новые SASI, но вроде есть надежда что работают достаточно хорошо) поэтому если запрос требует фильтраци данных не по основному ключу используемумо в column family касандры, скорость обработки этого запроса будет чудовищно медленной. Это касается в принципе ограничений которые накладывет касандра

В кассандре есть вторичные индексы

Вы реально с ними работали?

да

они более менее работают когда у вас в запросе всегда есть partition key

если нет, то они не работают

Ты говоришь про запросы, которые несколько нод затрагивают. Они будут медленными, потому что несколько нод + нагрузка на координатор.

Что значит не работают?

не рабоают в данном случае значит что время ответа измеряется в секундах :)

может у вас индексы были... не очень?

На координаторе еще и OOM можно получить

Слишком маленькое кол-во значений или слишком большое

ERROR: S client not available

В общем в кассандре есть вторичные индексы, они слегка капризные, и нужно за ними следить

Да, они есть и да за ними надо следить. но лучше их вообще не трогать

это оч странные заявления

А ну и самое главное нельзя пытаться хранить в касандре данные требующие транзакционного обновления

если есть какие-то конкретные и необъяснимые пробелемы, надо писать в рассылку их

а то сейчас это выглядит как "ну мы попробовали, было чот как-то не очень, НИКТО НЕ ПОЛЬЗУЙТЕСЬ ФУФУФУ"

@greenhost87 почему? Можно сделать транзакции поверх кассандры

не стоит такие данные делать горячими

ну или по крайней мере стоит очень продумывать это

в общем не нужно что-то объявлять неработающим в общем случае

это странно

@greenhost87 почему? Можно сделать транзакции поверх кассандры

Это тоже как минимум странно, да это можно делать но это отдельная точка отказа. Либо точка очень медленной работы в случае если использовать встроенный в касандру пафос

очень медленной по сравнению с чем?

со sqlite3? :)

Вы смеетесь?

если мы говорим про akka-persistence, то там все должно быть несложно. две почти одинаковые таблицы, две колонки по которым выборка идет

да

60 запросов в секунду это примерно максимум что выдате пафос

потому что это очень забавно, когда люди говорят "транзакции на распределенной БД очень медленные"

а какие они должны быть?

они ж распределенные

60рпс? вы серьезно?

у меня вот несколько тысяч

Да я не спорю, просто есть люди которые начинают проект с криками мы берем касандру и будем в ней всё хранить

ну и им придется очень много всего узнать нового

можно им об этом сказать

что им будет сложно

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

а не "в кассандре нет вторичных индексов"

это просто ложь

или "транзакции самописные будут медленные"

это пугает, но информации в себе не несет никакой вообще