[uanog] Parallel processing - which one to use?

[Maksym Tulyuk]

Почти правильно: я нахожу проблему в том, чтобы устанавливать прокси на клиента. Мне больше нравится это делать на сервере, что бы потом делать по человечески: 1) upgrade 2) troubleshooting 3) monitoring

Но кешировать локально тоже хорошая идея

Максим
On 18 Jan 2021, 14:40 +0100, Volodymyr Litovka <doka at xlit.one>, wrote:
>
> On 16.01.2021 16:16, Maksym Tulyuk wrote:
> > > > Поэтому, в данной ситуации, я бы [ ... ] или написал свой “прокси" REST API и добавлял туда механизмы кеширования.
> > > так по сути "проксёй" и является in-memory db. Очень быстрой проксёй.
> > Согласен, это очень просто перенести/запустить серверную часть на клиенте, но как потом сделать: 1) upgrade 2) troubleshooting 3) monitoring 4) etc?
> Я правильно понял, что ты предлагаешь сделать прокси и тут же находишь в этом проблему? :-)
> Я объясню, почему прокси не подходит. Потому что нужно в real time на толстом потоке данных предпринимать действия. Данные - дискретные и не связанные друг с другом (вот таков он, источник информации), потому batching не канает. Потому можно, конечно, делать вот так -
> 1) ask local
> 2) ask api (long delay)
> 3) store data locally (delay)
>
> но пока кеш таким образом разогреется, принятие решений будет сильно тормозить. Потому - сначала загнать все данные в память (разогреть перед стартом), обновлять данные по мере поступления обновлений и спрашивать только в локальной in ram DB.
> А если приложение или inramdb накрылись - повторить процедуру инициализации. Это не страшно, потому что на время инициализации нагрузка распределится по другим приёмникам.
>
> --
> Volodymyr Litovka
>  "Vision without Execution is Hallucination." -- Thomas Edison
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uanog.kiev.ua/pipermail/uanog/attachments/20210118/532b45d6/attachment.html>