зато его долго заряжать ненадо

и днем глаза не режет , вид как у бумаги

Это да, юзал же)

ну просто нужен ли тот же горячий code reload в наше время? когда есть core os, которая поднимается меньше секунды (емнип) и есть те же контейнеры

Фишка в том что tcp соединения не отваливаются

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

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

https://www.youtube.com/watch?v=TS1lpKBMkgg Тут Пауль говоит что у скалы в целом большие проблемы

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

географически раскиданы. девайс - gps-gsm трекер (если оооочень грубо) примерно все так и происходит, как ты описал. просто хочется найти какое-то более простое решение для данной задачи и снизить затраты на облака

географически раскиданы. девайс - gps-gsm трекер (если оооочень грубо) примерно все так и происходит, как ты описал. просто хочется найти какое-то более простое решение для данной задачи и снизить затраты на облака

Эра ГЛОНАСС что ли?

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

как ты сразу критично :) мне скала пока хорошо заходит. то что там Пуль говорил - ну он вообще странный, а про совместимость - ну её ведь никто не обещал. да, переделали систему типов. да, стало лучше. akka - да, реализация акторов Erlang на JVM и если верить бенчмаркам, результаты там очень неплохие. но меня akka интересует больше со стороны akka streams

Ну там уже дело до уволнения доходило

https://www.youtube.com/watch?v=uiJycy6dFSQ

ну если Одерский уже сам давно ее не пилит

судя по гитхабу

Эра ГЛОНАСС что ли?

что то типа https://smartdriving.io/ ;)

вот этот чувак и пилил в основном

ну если Одерский уже сам давно ее не пилит

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

НУ у нас еще случай был. Есть один чувак у меня знакомый, он работал в свое время в германии в doo.com там тоже мялись что выбрать , скалу или clojure. в бщем там у них соревнование было , и clojure победил так как то что один делал 2 дня с половиной, пришел второй и тоже самое зделал на 4 часа

конечно это субъективно все было

но всеже у них потом про скалу даже шутки ходили

ну и на меня в свое время это подействовало.

как раз в тот момент все эти проблемы с увольнением и критикой от Пауля шли..

выступления эти

и бинарная совместимость

верее проблемы с ней при переходе на новую версию

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

може я что не так понял

какие там сети

и каналы

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

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

Стомегабитная сетка это уже музейный экспонат, по крайней мере в датацентрах

в датацентрах не спорю

но все девайсы вот в моей задаче раскиданы по области

вне крупных мегаполисов

и там связь порой идет через сотового оператора

что является узким местом

и потом человек говорит что 30 мегабайт в секунду это одни девайс а их у него 100 тысяч ожидается

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

вообще там что идет. подвижные точки будут на авто к примеру или стационарно распределенные с определенной плотностью на единицу площади

что за девайсы пока непонятно

30 мб/МЕСЯЦ

ну это уже другой расклад

простите, возможно возникло непонимание

Ну это то что я прочитал

а данные будут в течении суток равномерно идти или например в зависимости от часа пик?

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

и у нас в эти моменты больше данных идет

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

ну вот к вопросу о технологиях - когда мы были молоды и падки на bizpark от ms, запилили всё на .net/c# о чем лично я теперь очень жалею. я могу очень много говорить о плюсах и недостатках .net (чуть больше 10 лет опыта) могу чуть меньше рассказать про JVM (3-4 года) и на Scala я пока без месяца год писатель, примерно столько же на Erlang/Elixir с архитектурой плюс/минус понятно, если в упрощенном виде - всё так как ты написал. бенчмарки не совсем пустой звон для меня, ибо сейчас основная цель - снизить затраты на инфраструктуру, что бы в пересчете на 1 девайс получить минимальные затраты. понятно что в первую очередь это решали архитектурно, потом уже по битикам/байтикам бенчмарков. тут еще не маловажный фактор - стоимость разработки/поддержки

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

все как у вас. но всевозможными хитростями стараемся мазать эти моменты равномерно на сутки

сорри за долгие ответы :) не смог устоять перед ароматом куриных крылышек в духовке.

приятного апетита

приятного апетита

пасиб

По ерлангу.. процес вхождения несложный. У меня тут адепт-стажер после си быстро въехал уже через недели две дал боевой код писать

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

еще вопрос , вам сетевого стека TCP/IP на все хватит?

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

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

ниже TCP/IP не опускаемся

в кач-ве транспорта MQTT (он поверх TCP) в редких случаях данные по UDP

для UDP листенеры самопис, а для MQTT приспособили RabbitMQ с плагином слегка подпиленным

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

я уже выше говорил про тулинг - почему год назад обломался с erlang/elixir первая задача - данные от девайса размотать (heatShrink) и десереализовать (protobuf v3) - облом. готового нет :(

а писание протокола есть?

rfc там?

или чтото еще

а писание протокола есть?

MQTT?

это есть я уже понял. я непонял в чем сложность на erlang как вы гоыорите данные размотать и десериализовать?

самому написать если готового нет

ERROR: S client not available

Да, с бинарными данными отлично на эрланге работать.

прямо билиссимо!!!

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

дык на скале ничего сложного не остается уже :) только процессинг.. данные с rabbitMQ забрать, в akka по актору на девайс насоздавать, внутри актора отпроцессить данные, в базу сохранить, во внешние каналы запаблишить стримом скормить в кафку, что бы дальше ребята в дата-саентистов с big data поиграли :)

это есть я уже понял. я непонял в чем сложность на erlang как вы гоыорите данные размотать и десериализовать?

ну готового не было, а взять и написать - не было времени. всё банально ?

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

ну вот сразу вопрос. актор на девайс. а вы можете для каждого актора TCP порт поднять сразу и потом его грохнуть и пусть этих девайсов за раз 300 штук будет опрашиваться?

как в жабе с этим делом?

сокет имел ввиду

или там через rebbit както у вас сообщениями залетает?

на каждый актор?

я тут просто незнаю как представить правильно

или пулл какойто

держать

ну вот сразу вопрос. актор на девайс. а вы можете для каждого актора TCP порт поднять сразу и потом его грохнуть и пусть этих девайсов за раз 300 штук будет опрашиваться?

в случае TCP (таких 95%) девайсы всегда онлайн.. у них постоянный tcp коннект к rabbitMQ брокеру. они кидают данные. а я могу закинуть чего-нибудь на них (команду например) с брокера по AMQP я собираю данные (которые девайсы туда закидывают)

понятно. и теперь вам надо хранилище данных

для всего этого дела

с поиском по времени

угу.. :) для данных телеметрии сейчас azure tables apache cassandra в целом устраивает, но кассандра тяжела смотрю в сторону scylla, но пока страшно

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

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

какбы по месту тест сразу на боевой порции данных

небоольшой

а затраты это в соновном получается касандра дает? ресурсов много хавает?

со сциллой страх - что делать, если упадет в продакшне :) по кассандре какой-никакой опыт набили

у нас так вообще постгрес работает.

))))

но на 100 тыш девайсов думаю я бы его тоже десяь раз подумал

вотнуть или нет

а затраты это в соновном получается касандра дает? ресурсов много хавает?

где-то кассандра где-то виндовые тачки с .net и sql на всем можно сэкономить. кассандра пока нравится. а лично мне вот .net уже не очень :) ms sql в процессе замены на постгрю

ну а вот на ерланг-эликсир вы пробуете то что на net писано , портировать

я так понял

или на скалу