зимовку в тайланде

Писать код - дело не хитрое. Вот что писать- это вопрос)

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

В параметры сообщение передать

Если его крэшится - супервизор перезапускает с теми же параметрами

Но от падения ноды не спасает

Ты можешь вообще написать проксю на эликсире, туда по udp кидать данные а потом писать в эластик

Да, дело ясное

Просто не персистентное

Допустим количество товара может просраться если двое одновременно купят

Вот тут то тебе и нужны очереди)

Используй RabbitMQ и не парься

А эластик сам вообще персистентный?

Может мне просто на pgsql забить

И работать прямо с nosql

Я лично знаю чуваков чудаков с одной нодой монги в проде

Причём fintech решения у них для Nasdaq

Опасные чуваки) Пожалели железа.

Если ты поднимешь кластер из Эластиков, персистентный

А если одно, где может проебаться?

эластик раз в секунду пишет данные по умолчанию

Если я буду через брокер пилить

Т.е. Если упадёт - просто разверну запрос

опять же кроме поиска ты как ещё с данными работать-то будешь?

тебе надо просто документное хранилище с поиском?

Ну менять теоретически можно

Считай что твиттер

С редактированием

Допустим количество товара может просраться если двое одновременно купят

тут тогда тебя спасет CQRS/ES :)

вот кстати буквально вчера чтиво появилось https://10consulting.com/2017/01/04/building-a-cqrs-web-application-in-elixir-using-phoenix/

Кто сталкивался, подскажите насколько стабилен адаптер mongodb для Ecto https://github.com/michalmuskala/mongodb_ecto

https://qafoo.com/blog/086_how_to_synchronize_a_database_with_elastic_search.html

Вот такое чудо нарыл

Как вам решение?

Ещё статью нарыл, советуют after_update пихать в очередь и не тупить

Ну как мы и обсуждали вроде

Кто сталкивался, подскажите насколько стабилен адаптер mongodb для Ecto https://github.com/michalmuskala/mongodb_ecto

увы.. не фанат монги

https://www.amazon.com/gp/offer-listing/1449362125/ref=dp_olp_all_mbc?ie=UTF8&condition=all&coliid=ISJ9WL9YQJCKJ&colid=3147L6WR31PSQ

тудумс

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

хм, что то информация разнится.. где-то пишут что еще не издана, хотя издана была еще в 2014 если не путаю на прагпроге появится вообще в марте примерно https://pragprog.com/book/eserlang/the-erlang-runtime-system

http://stenmans.org/happi_blog/

чувак просто затянул)

http://stenmans.org/happi_blog/ - его блог

интересно, на какой главе он остановился? ;)

на той где нужно выкатить в продакшен ?

?

это книга на базе http://erlang.org/doc/apps/erts/erts.pdf ?

это книга на базе http://erlang.org/doc/apps/erts/erts.pdf ?

без понятия

это книга на базе http://erlang.org/doc/apps/erts/erts.pdf ?

нене. Дима про книгу Стенмана кидал, а твоя от эриксона

прошу прощения за криво составленный вопрос я имел ввиду - содержание там плюс-минус одно и то же (ожидается), речь идет о том же, по сути?

Всем привет. Как я понимаю, скоро будет русский перевод книги: Designing for Scalability with Erlang/OTP

https://twitter.com/FrancescoC/status/816938582032187393

покупать заново?

redbeard Ну может кому-то приятнее читать на русском :)

невероятно эффективный и безглючный брокер очередей

Ох не безглючный. Гораздо лучше Apache kafka

Ох не безглючный. Гораздо лучше Apache kafka

А в чем заключаются проблемьі?

https://twitter.com/FrancescoC/status/816938582032187393

Я помню его доклад , даже побазарил с ним немного

Такой уже довольно взрослый мужичек

Но они там тролят друг друга

А в чем заключаются проблемьі?

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

ERROR: S client not available

Кто то тут про эластик спрашивал. Недавно писал проект на прости господи нодежс. Дак там для Mongoose поставили плагин который на каждый save модели кидал данные в эластик

Конечно это решение в лоб. Тк если эластик недоступен то все пропало

Всетки неплохое решение это иметь таблицу с постоянно увеличивающимся изменениями в рдб

И соответственно в эластике в каждый документ вешать это поле

Ну надежность rdbms никто не переплюнет пока

Потом после поднятия эластика из небытия находим док с самым последним числом изменения

И вытягиваем из рдб все что за это время набежало

Кстати в постгре же вроде есть фул текст индекс. Не пробовал?

Кстати в постгре же вроде есть фул текст индекс. Не пробовал?

Он не интеллектуальный и без лексического анализа и ранжирования

Ну это да

Может есть расширения какие к постгре не искал не знаю

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

А с инкрементным индексом если документ и потерялся, то он вместе с индексом и теряется

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

как-то так, не?

Вчера в дороге слушал подкаст как живет авито на постгре. Это к тому что рдб не так уж и плохи на больших проектах

это я уже почти из первых рук и полгода назад слышал :)

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

Тут кстати возможна жава имеет решение. В спринге есть решение для распределенных транзакций. Возможно эластик там можно прикрутить

Я ж говорю в чем проблема очередей - ты можешь записать а оно не сохраниться

значит, надо будет думать про персистенси на диск

Кафка вроде всегда на диск пишет

Могу ошибаться

Кафка еще не только на диск писал, а еще и книжки норм. :)

:)

Не в очереди не сохраниться, а в эластике

А да

а возможно ли удостовериться, что в эластике сохранилось?

Вчера в дороге слушал подкаст как живет авито на постгре. Это к тому что рдб не так уж и плохи на больших проектах

А поиск у них тоже на постгре?

Потому что он у них ужасен

Если бы в эластике все сохранялось - я бы вообще рдб выкинул