поэтому проще сразу выбрать что-то мощное, чтобы потом не переписывать

не факт

не факт

не факт что не факт ?

а выбирать что-то мощное - это "предварительная оптимизация"

то есть тебе миллионы сообщений в секунду не нужны (а нужны несколько тысяч, например), но выбрав тот же nats. Получаешь на голову усложнение администрирования и меньше функционала (то есть какие-то решения возможно придётся писать самому)

Преждевременная оптимизация))

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

ну и соответственно оценивать производительность обмена сообщениями в нём придётся своим решением каким-то

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

я как-то задался вопросов как одновременно обрабатывать 5 млн задач, потом 120 млн, потом завис над долгое время по обработке 4 млрд задач - надо будет попробовать на nats

поэтому согласен - все зависит от задач, но проще учить ту технологию к которой рано или поздно придешь все равно

????

поэтому согласен - все зависит от задач, но проще учить ту технологию к которой рано или поздно придешь все равно

ну надо на ассемблере тогда лабать, быстрее чем на нём ничего не сделаешь ?

вот она, технология максимальной производительности

ну надо на ассемблере тогда лабать, быстрее чем на нём ничего не сделаешь ?

я не так быстро на асемблере пишу)

вот она, технология максимальной производительности

кроме производительности лопаты еще есть производительность держателя лопаты))

кроме производительности лопаты еще есть производительность держателя лопаты))

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

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

кто ж знает нужно ли там допиливать)))

ну вот мне бы пришлось

если бы я вместо кролика стал nats использовать

я распределённые парсеры писал

мне очень хорошо заехала фишка ручного подтверждения задач

потому что каждый мой воркер не факт что мог справиться с задачей

зачем тебе трактор, если можно 500 таджиков пригнать в поле за три копейки - тоже верно)))

nats не трактор в том то и дело, у него меньше функционала чем у кролика

это болид формула один, а нужна газель ?

я его не изучал, не могу пока сказать)

надо будет потестить))

этим и хочу заняться в общемто

в болид много не нагрузишь, бензин быстро жрёт, обслуживать сложно и.т.п.

потому владельцы магазинов пользуются газелью =)

но гоняет болид быстрее - факт

потому владельцы магазинов пользуются газелью =)

тут не поспоришь))

видимо это чтото типа этого https://clickhouse.yandex/reference_ru.html#AggregatingMergeTree

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

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

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

в тот же Openstack в компьют движке встроен amqp или rabbitmq на выбор и можно гонять все данные, но по сути при матрешке где у 10 клиентов еще по 10 клиентов, получается адище адищ

раньше мы гнали данные со всех инстансов на 1 метрик сервер, было даже круто. Первые месяца 4

потом узнали о такой мелочи, как то что мы свою же сетку прогоном метрик перенагрузили )

в итоге вся телеметрия теперь собирается в своих мини-менеджмент серверах

и потом уже вышестоящий сервер берет что надо

операторы видят метрики инстансов клиентов с разрешением в 1 секунду. Биллинг видит все с разрешением в 1 минуту.

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

операторы видят метрики инстансов клиентов с разрешением в 1 секунду. Биллинг видит все с разрешением в 1 минуту.

ну вы же для этого свою обвязку делали? или готовое решение есть? какую TSDB используете и почему? (я только influxdb и ELK пользовался, потому интересно)

ну вы же для этого свою обвязку делали? или готовое решение есть? какую TSDB используете и почему? (я только influxdb и ELK пользовался, потому интересно)

прометей был основной, а мы всего лишь написали для него конфиги

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

?

странно что ты не в курсе, вообще понятие - федерация(как формирование), довольно популярно

тот же Консул вообще только из-за этого на руках носят

не работал с этим просто

https://www.consul.io/docs/guides/datacenters.html

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

он просто охуителен

почитал у прометея про иерархическую федерацию, крутотень

https://www.slideshare.net/OlegTokarev/how-we-cooked-elasticsearch-consul-haproxy-and-dnsrecursor

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

креативно сделано)

о, Олега в телеграме показывают

четко и понятно в общем-то написано))

самая четкая картинка там))

вообще для elasticsearch не нужен HA-Proxy, он и сам умеет кластеризоваться

consul штука интересная, я ещё с serf на него гляжу, но применять сейчас негде и незачем (((

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

вообще для elasticsearch не нужен HA-Proxy, он и сам умеет кластеризоваться

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

дык DNS round robin + кластеризация от эластика это не то же самое?

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

ERROR: S client not available

просто на nginx сделал балансировку на каждую и готово - все работает. И кластер живет

точнее узел эластика без данных и всё

обдумал, да, есть смысл в ha-proxy

точнее узел эластика без данных и всё

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

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

если бы трайб делали, то кровью умылись

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

вот смотрите появился golang и сколько продуктов крутых напилили: docker, consul, etcd, prometheus, grafana... в итоге складывается впечатление что другие языки / технологии были непригодны / сложны для разработки таких продуктов. а деревянный golang где особо нет возможности для фантазии программиста а только чтобы работу делать смог

да и MQ и баз данных стало сильно много на go

радует этот факт

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

Меня удивляет на питоне TensorFlow

Меня удивляет на питоне TensorFlow

под капотом же кресты

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

писать можно

Да, под капотом кресты, но почему "фронт" на питоне, если есть куда более шустрый go?

питон де-факто стандарт в датасайнс

Они ведь могли так хорошо пропиарить свое детище

потом идет Julia, R и прочее

и отхватить поддержку сообщества

Да, под капотом кресты, но почему "фронт" на питоне, если есть куда более шустрый go?

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

они так же могли бы забиндить тензорфлоу к дарту и пропиарить дарт еще разок )

А чего глобального на рубях?

при всем при этом на питоне есть Jupyter который уже де-факто стандарт для workbook датасайнтистов

Ну кроме редмайна

Да, под капотом кресты, но почему "фронт" на питоне, если есть куда более шустрый go?

для го тоже есть тензор флоу, вроде

Да, но без тренеровки модели

А чего глобального на рубях?

homebrew

А чего глобального на рубях?

гитхаб

Rails :)

Да все на рельсы завязано

Spree

github