просто когда DUB не было казалось что проще всё в фобос напихать

но на самом деле бюрократия там получается (и это разумно), так что развитие тормозится

Только вот как же Net живет? Я не видел чтобы люди стонали что его api старое

Только вот как же Net живет? Я не видел чтобы люди стонали что его api старое

на вдувании бабла от мс

Я кстати тут с Ольшанским поговорил. Тот говорит что из фобос нужно выкинуть все кроме алгоритмом. Типа все либы тормозят прогресс. В чем то он прав.

Вообще удобно, что в стандартной библиотеке всё есть. А каким образом тормозит?

А внести изменения сложно

всё что сложнее багфикса требует обсуждения потому что ломает многое

Ну куча либ откровенно старые с корявым api

https://docs-beta-transactions.mongodb.com/transactions/

?

Транзакции

То, чего не хватало)

То, чего не хватало)

транзакции это не сложно, но они ведь обещали ещё и избыточность хранения

Как я понимаю транзакции катят только очень простые. Без сложной обработки

реплики автоматические

реплики автоматические

Не понял

Как я понимаю транзакции катят только очень простые. Без сложной обработки

Не думаю, скорее всего любые

Нужно будет завтра днём попробовать

Если есть РЦ сборки

ну принт или его аналог

Ну так оно наверняка для строк онли

Не понял

Нужны не просто транзакции а распределённые. Иначе они просто переизобретут rdbms

Хех прикол, а ведь и правда Бартунов рисовал картинку как монга эволюционирует до постгреса постепенно)

Хех прикол, а ведь и правда Бартунов рисовал картинку как монга эволюционирует до постгреса постепенно)

Когда это было?

И где?

https://youtu.be/SNzOZKvFZ68?t=1807

Да он эту картинку еще в 2014 показывал на конференции )

Типа монга такая древняя обезъяна и по шагам превращается в человека, а справа на нее смотрит слон как она к нему идет :D

lol

ну да, короч, о чём и речь, чудес не бывает, CAP-теорема никуда не девается

обходить её надо как гугл - с помощью точного квантования времени

У нас на работе будут реквестить https://www.emotiv.com/epoc/

Будем пробовать что-то с этого сотворить

дык это баян 15-летний?

У нас на работе будут реквестить https://www.emotiv.com/epoc/

крутая штука, расскажешь потом что вышло?

дык это баян 15-летний?

я так понимаю ты 15 лет назад с этим говном работал уже?)

видео видел

крутая штука, расскажешь потом что вышло?

Если к тому времени ещё буду там работать

:)

Там и хололен будут брать, 2й версии

https://youtu.be/SNzOZKvFZ68?t=1807

Досмотрел - крутой доклад

Обычно дипломатию соблюдают докладчики, а тут просто: "монга - говно!" с пруфами

Кто знает, в MQTT есть возможность послать сообщение так чтобы его получил лишь один любой подписчик?

Кто знает, в MQTT есть возможность послать сообщение так чтобы его получил лишь один любой подписчик?

вроде нет

Придумал хак: shared subscribtion + отписываться сразу по получении сообщения.

Тогда много воркеров смогут подписаться и брать из такой "очереди" задачи

Кто знает, в MQTT есть возможность послать сообщение так чтобы его получил лишь один любой подписчик?

Ответ: да - shared subscribtions

Просто клиентов очередей у нас нет в code.dlang.org, как я понял

Ответ: да - shared subscribtions

чёт впервые слышу, как делается?

чёт впервые слышу, как делается?

А это новое в протоколе: https://paolopatierno.wordpress.com/2017/08/21/mqtt-v5-what-is-on-the-way/

https://stackoverflow.com/questions/35014975/using-mqtt-with-multiple-subscribers

Но это 16ый год

я делал на mosquitto себе либу

hive платный, настолько я помню

так что, возможно, в mosquitto и нет этой фичи

https://github.com/eclipse/mosquitto/issues/313

я делал на mosquitto себе либу

а он не умеет шаренный подписки

бррокеров щас развелось много, в некоторых есть

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

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

я пользоваться пробовал одним на vibe, который на D написан, может там тоже есть

а зачем ты написал свой клиент mqtt?

а зачем ты написал свой клиент mqtt?

vibe глючил

опаньки

а я его планировал

выяснил где глючил?

https://github.com/tchaloupka/vibe-mqtt/issues/29 да, даже вроде поправили, но я уже написал обёртку на тот момент

Аа ну ок

а вот Людвиг ничего не стал с багом делать

выяснил где глючил?

там эта фича что тебе нужна сделана?

там эта фича что тебе нужна сделана?

Она не от клиента зависит а от брокера

Это просто синтаксис подписки хитрый

а та либа только клиент?

а та либа только клиент?

Не брокер

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

РабитМку?

Не, это же amqp

Тоже нужен свой велосипед!)

Рассказываю эпик-фейл дня (до сих пор лежим). Я не предусмотрел, что кто-то из внутренней сети может додуматься отправить запрос на вборку из БД без явного указания лимитов. Ну вот не додумался я до такого кейса. В итоге утилита съела всю память и сервер упал. Все докеры и тд оказались бесполезны)) в итоге завис именно сервер в котором докер крутился. Не могли поднять почти 2 часа. Подняли. За это время скопилась толпа клиентов, которые в попытках провести транзакции устроили нам DDOS атаку своими запросами и база данных легла) Сейчас думаем как быть)

а чо за бд? постгрес?

да

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

Клиентам никогда нельзя доверять :)

> Не могли поднять почти 2 часа. А что делали? Вы же его ребутнули?

Рассказываю эпик-фейл дня (до сих пор лежим). Я не предусмотрел, что кто-то из внутренней сети может додуматься отправить запрос на вборку из БД без явного указания лимитов. Ну вот не додумался я до такого кейса. В итоге утилита съела всю память и сервер упал. Все докеры и тд оказались бесполезны)) в итоге завис именно сервер в котором докер крутился. Не могли поднять почти 2 часа. Подняли. За это время скопилась толпа клиентов, которые в попытках провести транзакции устроили нам DDOS атаку своими запросами и база данных легла) Сейчас думаем как быть)

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

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

Стандартная настройка

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

Рассказываю эпик-фейл дня (до сих пор лежим). Я не предусмотрел, что кто-то из внутренней сети может додуматься отправить запрос на вборку из БД без явного указания лимитов. Ну вот не додумался я до такого кейса. В итоге утилита съела всю память и сервер упал. Все докеры и тд оказались бесполезны)) в итоге завис именно сервер в котором докер крутился. Не могли поднять почти 2 часа. Подняли. За это время скопилась толпа клиентов, которые в попытках провести транзакции устроили нам DDOS атаку своими запросами и база данных легла) Сейчас думаем как быть)

Бывает

Мы системой очередей это разрулили

Где можно понизить количество воркеров

Мы системой очередей это разрулили

Какую выбрали?

Не понял как система очередей поможет именно эту проблему решить. Если конечный запрос все равно на бд выполняется

Какую выбрали?

Рабит

Не понял как система очередей поможет именно эту проблему решить. Если конечный запрос все равно на бд выполняется

Но их выполняется контролируемое количество

Ага, но это же решение более выского уровня абстракции. А если выполнится 1 запрос без указания лимитов, то все равно все умрет )

По времени лимитировать запрос тоже кмк не самая лучшая идея - много запросов могут потихоньку выполняться хоть пару минут. Надо найти какую-то комбинацию memory+cpu

Ага, но это же решение более выского уровня абстракции. А если выполнится 1 запрос без указания лимитов, то все равно все умрет )

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

Получать только те данные, которые нужны. Или минимизировать их количество

Если возможно - разбить на несколько итераций

По возможности, самое лучшее, работать с курсором

И раз уж так - дать больше памяти процессу