Clojure, ленивость и отложенные отчеты

[metaclass]

Очередной раз стукнулся об ленивость.

Делаю фоновый расчет отчетов - клиент просит у сервиса "посчитай мне отчет", тот ему возвращает идентификатор-ссылку на future со считалкой отчета и далее клиент опрашивает сервис на предмет "а не готов ли наш отчет" и тот ему отвечает либо "не готов" либо "готов, вот тебе данные".
Ну, склепал очередь отчетов - атом, в нем мап, в мапе идентификаторы запрошенных отчетов и future к ним. Запускаю - а оно мгновенно говорит, "да, вот отчет готов, забирай" и давай его считать и отдавать. В потоке запроса, не в рабочем потоке future.
Ленивость. Оно возвращает башку последовательности данных отчета сразу, "на тэбэ, дорогой, форси меня". И запрос готовых данных (в том числе, даже просто попытка в целях отладки посмотреть на мап с future) - вызывает форсинг последовательности.

PS: И еще обнаружил очередную фичу кложури - thread-local bindings протаскиваются во все вызовы, которые перекладывают работу в другие потоки. Т.е. конкретно тут - я в запросе часть общих параметров (типа имени пользователя) складываю в thread-local binding чтобы не протаскивать их руками через 100500 функций, думал, что при вычислении внутри future придется их доставать и перекладывать во второй поток - а оно уже сделано.
Авторы кложури не перестают удивлять своей крайней адекватностью и практичностью языка.

Comments

[plumqqz.livejournal.com]

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

[metaclass.livejournal.com]

Хм, с тем, чтобы курсор не фетчился, я сталкивался только при ошибках. А как он может не фетчится в обычных условиях работы?

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

[plumqqz.livejournal.com]

Хм, с тем, чтобы курсор не фетчился, я сталкивался только при ошибках. А как он может не фетчится в обычных условиях работы?
Ну почему не фетчится. Фетчится, только медленно.

[levgem.livejournal.com]

может оно и к лучшему. Отдаст ленивый ответ, посчитает первую страницу, а дальше всё равно никому не интересно.

[berezovsky.livejournal.com]

Ага, листаешь жежешечку, а там эта хуетень по центру крутится. Пока ждёшь, десять раз читать передумаешь.

[metaclass.livejournal.com]

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

[berezovsky.livejournal.com]

Кстати да. Как нормальный пейджинг делают?
Два селект топа каждый раз, или тянут всё на клиент и перекладывают на грид, или что-то промежуточное, вроде "посчитали конечную табличку, оставили на сервере, по мере листания на клиенте получаем из неё куски"?

[metaclass.livejournal.com]

Не знаю. Наверно выполняют запрос с select first/top/limit
Меня огорчает мысль о том, что этот запрос выполняется повторно на каждую страницу, поэтому теоретически, надо бы выполнить его один раз и закэшировать.

[swizard.livejournal.com]

> Меня огорчает мысль о том, что этот запрос выполняется повторно на каждую страницу, поэтому теоретически, надо бы выполнить его один раз и закэшировать.

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

[jakobz.livejournal.com]

Делают select top каждый раз. Прикол в том, что никто списки дальше чем страницы на 3 не листает. Т.е. пейджинг - он только в теории нужен, а на практике надо нормальный UI со списками заголовков, фильтрацией, и т.п.

[swizard.livejournal.com]

Вот, кстати, совершенно согласен про ненужность пейджинга. Имхо он реально необходим только для двух вещей:

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

[sergiej.livejournal.com]

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

[metaclass.livejournal.com]

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

[sergiej.livejournal.com]

Не надо кешировать. Первым запросом берутся только айдишки да побольше, скажем страниц на 10, если больше говорим "заузь критерии, всё не влазит". Потом очередной набор айдишек кверится для каждой страницы с деталями, вот и всё. Обеспечено что пациент пролистав увидит все записи. Можно не листать а дописывать внизу вновь прочитанные - так намного удобнее, но не во всех гридах это возможно без извращений.
Пейджинг собственно только для того и нужен, чтобы особо недоверчивые были уверены что они "проверили всё глазками".

[jakobz.livejournal.com]

Вот на это кладут вообще всегда и все.

[vit-r.livejournal.com]

Думаю, всё-таки зависит от сценариев использования. Если пользователь открывает страницу и пять минут её разглядывает, а открывает следующую, то повторный запрос можно пережить. Если он открывает и сразу печатает весь документ, тут уже нужен другой подход.

[theiced.livejournal.com]

ну - всё как надо.

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

[jakobz.livejournal.com]

А это не то ли IO вперемешку с ленью, с которым борятся монадой в хаскеле? Или у тебя тупо чистые вычисления там, и просто не зафорсилось где надо?

[metaclass.livejournal.com]

Оно самое, побочные эффекты+лень.

[jakobz.livejournal.com]

У меня похожая прикольная тема была. OpenGL-окошко на хацкеле, стейт в MVar, обновляется в idle на нужное количество тиков по таймеру. Сворачиваешь окошко, разворачиваешь - stack overflow.

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

Как такое чинить в общем виде в хаскеле - не ясно. Мне хватило зафорсить один санк, это почему-то вылечило stack overflow, но стейт до текущего времени при разворачивании окна оно все равно догоняет, для меня это уже не критично было.

[jakobz.livejournal.com]

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

[gds.livejournal.com]

> Если у нас нет лени - мы просто жарим CPU, и если он успевает - все ок. А с ленью всплывают интересные философские вопросы.

да какие там вопросы -- сплошные ответы. С ленью в этом случае сначала жарим память, откладывая личинки вычислений, а только потом жарим совместно память, цпу и бедного мусорщика. Причём цпу обычно жарим на большее количество тактов -- надо же эту лентяйку обслуживать как-то: смотреть, посчитали личинку или ещё нет, например.
Выгода тут есть только тогда, когда многие вычисления не нужны. Но при гуе навряд ли так выйдет.

[tonsky.livejournal.com]

Насколько я помню по реализации, только если запускаешь вычисления через Future или Agent. Мы как-то стартовали треды сами и выковыривали соответствующий код из clojure.core чтобы оно так же работало. Появилось, кстати, недавно, в 1.3 или 1.4

[metaclass.livejournal.com]

Да, в 1.3 и при запуске стандартными средствами.
А разве 1.3 это недавно? Я вроде 1.4 год назад начал использовать, 1.5 недавно вышла.

[prepor.livejournal.com]

эм, простите, вы разве не про это?

(def ^:dynamic *foo*)
(binding [*foo* "bar"]
	       (-> (Thread. (bound-fn [] (prn *foo*)))
		   (.start)))

=> "bar"