Отговори на тема  [ 101 мнения ]  Отиди на страница Предишна  1, 2, 3, 4, 5, 6, 7  Следваща
Питане за облачни архитектури 
Автор Съобщение
Ранг: Форумен бог
Ранг: Форумен бог
Аватар

Регистриран на: Нед Ное 21, 2004 10:31 pm
Мнения: 8686
Мнение Re: Питане за облачни архитектури
мдааа... всеки JS програмист сънува, че е собственик на следващия NEST.

опитват се да ме вкарат в тоя филм поне от 3 години. много ентусиазъм, блясък в очите, и гръмки фрази "това се прави за един ден". вече трета година...


Пет Яну 20, 2017 9:05 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Нед Фев 26, 2006 5:52 pm
Мнения: 7712
Местоположение: Добрич
Мнение Re: Питане за облачни архитектури
gicho написа:
Каква ти е логиката на "украсата"? Без него не работи системата - там ми е бекенда.

От предишните ти постове не ставаше ясно. Хем казваш че е важен, хем смяташ да го шунтираш, То не може китки и фитки. Но след примера ти с ТКЗС-то нещата се изясниха. В твоя случай сървърът ти е нужен за украса. Може да правиш каквото си искаш определено.
Системите с които обикновено се занимавам аз са свързани с финанси, плащания и т.н. Клиентите обикновено искат 24/7/365 ъп тайм и обикновено не са шегаджии. Примерно една от последните системи я правихме за едно момченце с малко килограми няма начин да не се сещаш #кой. Въпреки че там нямаше толкова сериозни изисквания, все пак не е място за експерименти.
Та ако някога ти трябва надеждност ще разбереш че няма вариант да шунтираш SQL-а повярвай ми. Не става дума изобщо дали и какво съхраняваш, скорости и т.н, говоря ти за транзакции, атомичност и т.н. без които няма как да направиш сериозна система. Отгоре разбира се може да ползваш каквото си искаш включая MQTT, но не може да разчиташ на тях за надеждност, транзакции и т.н. Добре е да седнеш да приказваш с ИТ-та дето са правили по-големи корпоративни неща, те ще ти обяснят и какво джелязо има, как се прави редунданси, какъв избор имаш нагоре по софтуера и т.н. Познавам такива хора мога да те свържа ако ти се наложи. От опит мога ти кажа, че един такъв разговор с професионалист е много полезен.


Пет Яну 20, 2017 10:01 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Пон Мар 13, 2006 12:59 pm
Мнения: 2788
Местоположение: Габрово
Мнение Re: Питане за облачни архитектури
Не твърдя че смятам да търся универсално решение - убеден съм че има доста причини да се сложи SQL, били те технически или просто "наследство" или комфорт за участниците.
А за транзакции и подобни - много съм се борил и много нерви съм похабил в обратната посока. Преди години (десетилетия) някой се е опитал да сложи централизирана база в устройствата ни. По онова време дребни ембедед устройства, с 16-битово микроконтролерче и малко и2ц епром за storage.
От тогава това си стои вътре и влачи проблеми, специфични и не знам доколко има смисъл да описвам, но ще опитам.
Представяме си обектен модел на някакво устройство - в него има няколко (десет, 20) "модула", правещи нещо си. Всеки един модул има входни и изходни точки, конфигурация, разни данни, генерира събития, реагира на събития. Всеки от тези модули има собствени данни - на инстанцията по-точно, че има някой с повече от една инстанция. Да си представим нещата в ТКЗС примера - машината е да кажем с три оси и един шпиндел. Всяка ос се върти от серво, да сложим и шпиндела като серво и да викаме 4 оси. Да кажем че тия модули не са "хардуерни", а с софтуерни вървящи на един процесор.
Всяка от "осите" има актуални данни - скорост, позиция, момент например. Всяка от тях може да реагира на команди - зададена скорост, позиция, момент.
Вътре в инстанциите на модула "серво" има променливи - актуална скорост, момент, позиция и задания - зададени скорост, момент, позиция, както и още много други. На команда "позиционирай" съответстват статусни събития "стигнах", "забих", "няма пък".
Това мисля е коректно да се нарича модел на обекта "сервото" (в смисъла на "модела" в MVC)
Сега, единия подход е тези данни в определени моменти да се качват в централната база (по подобие на SQL) и оттам който иска да ги взема. Т.е. в централната база да има "копия" с които другите да работят (по аналогия фронтенд-а би прочел тях, а не вътрешните актуални).
Това води до проблема за управление на актуалността на данните. Или циклично копиране, или при събитие за промяна автоматичен презапис (от вътрешните към базата - т.е. данните се пращат при промяна). По-малкото зло е на събитие - превъртаме напред (или назад) - публикуване (publish).
Има и другата посока - а тя е "фронтенда" да поиска да прати някоя от осите на нова позиция. За да стане това в крайна сметка тази нова позиция трябва да стигне до променливата "зададена позиция" на дадената ос (ако си стои в централната база няма полза). Ако фронтенда записва в централната се стига до същия проблем ама в обратната посока - кога да копираме данните то централната база към оста? Естествено, циклично е грубо (но често срещано :oops: ), другото е на събитие - при самия запис. Пак FF - абониране (subscribe).
Ако се замислиш какво се получава излиза че тая централна база го играе не база, ами "гара разпределителна" - като дойде нещо то не се задържа, ами се прехвърля на това което ще нарека "реалния собственик на тия данни/услуги". А копието дето го има в базата става излишно - по-точно става по-некачествено спрямо реалните данни (в смисъл че опресняването е дискретно и е възможно в определени моменти да не е актуално).
Това по разните fieldbus-и му викат object dictionary. Структурата изглежда отвън като монолитна база с много елементчета, но реално е изградена от множество под-обекти.
Много често по нашите области се предпочита да знаем реалното, а не да получим бързо не-толкова реално. Защо може да има разлики? Много клиенти например, един иска едно, друг друго. При централна база трябва да се следи достъпа (Lock-unlock). Това май се явява транзакцията в SQL (и не само).
Смятам че има и други начини за гарантиране на "atomic" действия - пак ще спомена active objects теорията и lockless синхронизирането.
Мисля си и друго - ако имаме база (SQL) трябва да имаме заключване и отключване (за да поддържаме много клиенти, единия от които може да е реалния собственик на данните, т.е. този които постоянно ги рефрешва че другите да ги видят). В този случай достъп от клиент Х може да се забави докато чака отключване от изпреварилия го клиент Y? Това си е класическо инвертиране на приоритетите в най-цветущата му форма. Всъщност в SQL има ли такива неща като приоритет на клиента?
Скромното ми мнение на страничен наблюдател е че проблемите с тия транзакции стават точно защото архитектурата не е изградена да пита винаги една единствена точка, която има ролята да определя какво става.
Не съм запознат с банкови транзакции например и звучи като интересна тема. Съвсем ламерски мога да си представя няколко обекта дето участват - сметка на изпращача, сметка на получателя .... И още едно дето някой го забравят - един междинен обект дето е "плащането", "куфарчето", "преносителят", "транзакцията". Първите две са ясни. Плащането е сумата която излиза от едната сметка И ПО-КЪСНО влиза в другата сметка - или се връща обратно. Тя възниква като отделен обект при нужда.
Атомичността се получава като се използва "буферен" елемент (обект) - както е входното FIFO на активния обект, както е съобщението което търчи от фронтенда към бекенда.

Едит: отплеснах се и не отговорих на въпроса ти - ти си цитирал важните неща "atomic", надеждност, uptime. Да ги причисляваш само на SQL е несериозно - там може да се реализирани, но това че някой е измислил парния двигател не значи че друг няма да измисли вътрешното горене.
Надеждността се постига с мерки - трябва ти ток 24/7/365, интернет и т.н. Дали има бъгове в MQTT протокола или неговите имплементации? Може, затова има няколко големи имена, едното е "голямо синьо" :) , другите са пак големи ама по-безцветни. Ако търсим надеждност няма да я получим нито с мой MQTT брокер (ако тръгна да пиша), нито с SQL база написана от някой именит професор от габровското ТУ.
Аз твърдя че "би трябвало" да има и друг път. Не, не го твърдя, чета че по-умни хора от мен го правят.

Понеже точно тези проблеми - availability, скалируемост, надеждност на данните ме вълнуват търся дискусията и конкретните проблеми, които има за решаване - трябва ми проблем който да "пусна" през архитектурата и да видя какво ще излезе. Ако няма решение значи е лошо, ако има решение ама е сложно - пак лошо.
Тъй де, дай някоя специфична ситуация покрай банковите и финансовите да ме ориентира?


Съб Яну 21, 2017 12:01 am
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Пон Мар 13, 2006 12:59 pm
Мнения: 2788
Местоположение: Габрово
Мнение Re: Питане за облачни архитектури
ДедоБоре написа:
мдааа... всеки JS програмист сънува, че е собственик на следващия NEST.

опитват се да ме вкарат в тоя филм поне от 3 години. много ентусиазъм, блясък в очите, и гръмки фрази "това се прави за един ден". вече трета година...

А, Дедо, ще те съборят ли 200 долара за нест?
Не, сериозно, имам чувството че смятате че го играя някакъв "първопроходец"? Нее, много съм назад зад всички ама поне се опитвам да се взирам надалеко и ако зрението ми е още добро ще им видя пушека някъде далееко покрай хоризонта.
Казах го и преди - нямам самочувствието че правя нещо "стартъпско" (само "тъпско" може би). Има хора дето са го мислили, аз гледам да скрадна някоя идея че тия три години дето ги цитираш да минават по-интересно.


Съб Яну 21, 2017 12:21 am
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Вто Окт 11, 2011 10:53 pm
Мнения: 2775
Местоположение: Brussels / Пловдив
Мнение Re: Питане за облачни архитектури
miro_atc написа:
palavrov написа:
gicho написа:
По друг начин казано, искаме да изградим архитектура (базирана на нещо разбира се, не от нулата) която да ни отвори тези възможности - да имаме набор от услуги които:
- да могат да вървят на различните 'tier'-и - в облака, на мобилното устройство, на наш сървър, на виртуалка на чужд сървър и т.н. - идеята е да ние да го пишем веднъж а то да върви навсякъде (от изброените)
- да можем да дадем достъп (с контрол) към всяко едно от нивата - за 3rd party разработчици
- да имаме 'continuos integration' на услугите - да можем да работим по нови feature-и и лесно (без проблеми за клиентите) да ги пускаме когато са тествани

Те това се прави лесно с node и доста по трудоемко с други езици и фрамеворки.


Абе не знам... не ща да спорим. Той по принцип Гичо като си науми нещо не се отказва, така че освен да му пожелаем по-малко мотики по пътя друго няма ;-)

А иначе за протокола, това не са конкретни изисквания, щото всяка една система почва с подобни пожелания - да е отворена, да се развива лесно, бля, бля....
Да кажеш че това се прави най-лесно с node... позволи ми да не се съглася с теб и да си стиснем ръцете, нали всеки имаше право на грешно мнение ;-)

Е, то няма за какво да се спори - в смисъл, че всеки пречупва нещата през неговата си гледна точка и опит. От моят опит ноде решава най-лесно всички тези не конкретни изисквания в сравнение с другите технологии, платформи и фрамеворки които съм ползвал или разучавал. Всичко си е субективно.

_________________
Мразя да мразя ...


Съб Яну 21, 2017 1:03 am
Профил
Ранг: Форумен бог
Ранг: Форумен бог
Аватар

Регистриран на: Сря Апр 27, 2005 11:48 am
Мнения: 1677
Мнение Re: Питане за облачни архитектури
Пример: София - Система за паркинг места
100000 шофьора с телефони - не плащат дирекно услугата, може би с гледане на реклами
100 паркинга с до 50 места - 100 концентратора с минутен трафик, няколко байта данни
1 PC с база данни и визуализация
Комплексно решение та дори и в национален мащаб... бързо, точно и ясно

ТКЗС, NEST - частни данни, малко устройства, малко потребители - "висока" цена
Друго би било селскостопанска ферма с 1000 датчика и 100 изпълнителни устройства, 100 концентратора и един PC за сървър
Тук комуникацията частна и е в рамките на 20-30 километра и няма никъв смисъл трафика да мине през на майна си райна за да стигне до ТКЗС-то
Има логика за управление, следователно трябва индустриален "ОБЛАК" което си е частно конкретно решение

Централизирани облаци се правят за
- огромно количество комуникационни устройства и потребители
- еднотипни данни

Паркинг система "става", Става защото устройствата са прости логери а данните са публични и трябва да стигнат до потребителите
Елетромери, водомери, улични лампи е все такива - данните са частни и клиента ще ти търси високо качество и много ниска цена за услугата

Количеството комуникационни устройства ще намамят цената на трафика и цената на обслужването
Най-вероятно ще искаш данните да са JSON, да ама не всички устройства имат възможноста да обработват JSON, ако могат значи имат възможности, което предполага, че са и по-скъпи устройства
Ако добавиш HTTP, XML, web sockets, long-polling...и всевъзможни такива за да покриеш голям диапазон от потребители увеличваш сложността на "облака", следователно цената, сигурноста на данните и качеството на услугата
Големите клиенти не искат да плащат цената за сим картите, а ти добавяш цена и за облак

Ако събереш екип от 5 програмиста да се занимават с проекта, други 5 ще ти вземат клиентите с малки комплексни и конкретни решения
Или се целиш в световен мащаб...

_________________
main[-1u]={1};
http://www.wizio.eu/


Съб Яну 21, 2017 11:27 am
Профил ICQ
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Пон Мар 13, 2006 12:59 pm
Мнения: 2788
Местоположение: Габрово
Мнение Re: Питане за облачни архитектури
Интересен пример.
Как се прави следното разширение - няколко фирми, например 2 таксиметрови, 3 за коли под наем, един Uber примерно, някоя туристическа агенция, някоя транспортна фирма за цвят ти пращат запитване:
- Ще може ли в нашите системи да интегрираме вашите услуги?
Това различните фирми го виждат по различен начин:
- едни очакват в техните приложения да могат да ползват данни за наличните свободни места и да навигират техните устройства (коли, камиони) - въвеждат крайна дестинация и тяхната навигация им подсказва за ваш паркинг с налични свободни места
- може да поискат да резервират място - кофти е за бизнеса ако тръгнат от на майната си и като дойдат мястото да е заето; отделно твоя шеф няма да има нищо против да щипне малка такса за "резервиране на място"
- други виждат екстрата за резервация и им щраква - ей, дайте да вземем да сметнем дали оня дето е тръгва сега от Бургас и го чакаме след 2-3 часа няма да можем да го вмъкнем някъде - в смисъл в момента знаем че на удобния за него паркинг място йок, но имаме клиент който е платил за още 1 час и негово място може да му го дадем; ако не го "предвидим" ще трябва да откажем на клиента ("в момента място няма") или да го пратим на другия край на града

Идеята е че като се наложи такова нещо системата почва да има нужда от онези atomic неща за които говори Миро - резервация на паркомясто, което значи на чичката на бариерата (или на брояча на входа на паркинга, или червено-зелен буркан над мястото) да знае кога е резервирано от Бургаския клиент. Ама да не стане че два големи джипа дошли с резервирано един и също място и ги дават по новините понеже го ударили на престрелка в центъра...
Тия неща примерно в стила на SQL ще станат централно в базата - резервирано, заето, в ремонт, пълно със сняг, празно ама затворен пътя щото ВиК правят ремонт отпред. Работи - в стила на lock-unlock.
Едно ПЦ някъде предполага ниска надеждност - или поне не гарантирана. Това може и да не е проблем, ама ако батката дето ти е поръчал може да не се зарадва че заради ония от ВиК-то дето копаят ударили мрежата или тока, или пожарникарите заляли сървъра с пяна понеже комшията не си очистил комина и той се запалил. Не се радва понеже го удря по джоба - аверчето от транспортната фирма му пили защото камионджиите не могат да си резервират място.

Принципно 100000 клиента с добра цифра, но обикновено се дефинират не броя на регистрираните, а броя на едновременно закачените които могат да бъдат обслужени.

Иначе JSON е нещо добро, но не уникално. Няма вече хардуер (освен в китайските лампички за елха) дето да не го може - в последните 20 години не съм слизал под pic10 и 8051 и те го могат, но не отричам че има китайски плюнки дето може да им се опъне.
Това не значи че трябва да се ползва - MQTT често се ползва през JSON, но никъде в стандартите не се говори за такова нещо - payload-а може да байт, текст, каквото и да е до 256Мб.

Може би не съм описал добре цялата архитектура, мисля че се подразбира, но ще пробвам - в заветното цнц или друга машина има много процесори - например в енкодера в мотора. Това не значи че се очаква той да праща данните като "json" или да клати node.js или каквото и да е. Сигурно може, ама най-малкото няма кой да ни даде достъп да ми сменяме фирмуера.
Та идеята е че си има разделение на нива - ние за тия цели имам по-ембедед устройства да го кажем, които може да са свързани през друг интерфейс - modbus е подходящ пример, макар че при нас да не се ползва, но CAN и по-точно fieldbus-и с такъв физически слой. Над тях се намират по-интелигенти устройства, както споменах - линукс на арм или x86. В тях се очаква да се вкарат "агенти" които да са мост или гейтуей към горното ниво. Те превеждат информацията която я има долу и я вкарват горе (в MQTT примерно).
Имаме и софтуерни продукти и за виндоус, които могат да правят горе-долу същото като се връзват например през usb-към-can интерфейсно адаптерче и дават достъп (не real time) до устройствата които са на този бъс. Тия продукти са за настройка и диагностика, както и за програмиране на PLC-тата в нашите устройства.

Съвсем логично е че и в твоите устройства са на нива - най-простите които примерно светят лампите или детектират наличие на кола отгоре едва ли са малинки с линукс, и не е задължително да са по етернет. Може би RS485 или CAN или нещо друго което е лесно за окабеляване.
Всичките тези влизат в мастър, който предполагам иска интернет. Тук може и без ОС, може и със - предвид че може би ще се очаква гъвкавост откъм интернет свързаност аз бих турил нещо с openwrt поне - за да имам опции за жичен, безжичен, 3G, 4G,.... Може и с нещо по-просто, зависи от изискванията. Ако например батката иска паркинга поне локално да работи (т.е. чичката да не чупи пръсти да обяснява че няма нет и бариерата няма да се вдигне да си тръгнат хората) може да се наложи по-сложна архитектура, нещо разпределено. Може би има четци за NFC или карти или нещо друго, знам ли - тук вече ще се стигне до по-сложни дивотии с реплициране на данните и локално за да може поне навън да излизат колите при проблем.

Къде MQTT се вписва - брокерите могат да са повече от един и да се закачат през bridge-ове - единия в будката на чичката, другия примерно в някой дейта център за да не се чудим за пожарникарите. Както и за да имаме автоматичен failover и истински 99.99% достъпност.


Съб Яну 21, 2017 12:32 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Вто Окт 11, 2011 10:53 pm
Мнения: 2775
Местоположение: Brussels / Пловдив
Мнение Re: Питане за облачни архитектури
TheWizard написа:
...
Най-вероятно ще искаш данните да са JSON, да ама не всички устройства имат възможноста да обработват JSON, ако могат значи имат възможности, което предполага, че са и по-скъпи устройства
Ако добавиш HTTP, XML, web sockets, long-polling...и всевъзможни такива за да покриеш голям диапазон от потребители увеличваш сложността на "облака", следователно цената, сигурноста на данните и качеството на услугата
Големите клиенти не искат да плащат цената за сим картите, а ти добавяш цена и за облак

Ако събереш екип от 5 програмиста да се занимават с проекта, други 5 ще ти вземат клиентите с малки комплексни и конкретни решения
Или се целиш в световен мащаб...

Хубаво е да не забравяме и за закона на Мур - кой ти е предполагал преди 15-20 години, че ще търкаляш юникс в засовника си както е днес - дори в момента желязо което може да търкаля пълноценен node.js струва под $5. Затова, човек трябва да гледа нещата и малко в перспектива което си е чиста руска рулетка, но който познае верния кон след някоя друга година ще се смее последен :)

_________________
Мразя да мразя ...


Съб Яну 21, 2017 12:51 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Нед Фев 26, 2006 5:52 pm
Мнения: 7712
Местоположение: Добрич
Мнение Re: Питане за облачни архитектури
gicho написа:
Едит: отплеснах се и не отговорих на въпроса ти - ти си цитирал важните неща "atomic", надеждност, uptime. Да ги причисляваш само на SQL е несериозно - там може да се реализирани, но това че някой е измислил парния двигател не значи че друг няма да измисли вътрешното горене.
Надеждността се постига с мерки - трябва ти ток 24/7/365, интернет и т.н. Дали има бъгове в MQTT протокола или неговите имплементации? Може, затова има няколко големи имена, едното е "голямо синьо" :) , другите са пак големи ама по-безцветни. Ако търсим надеждност няма да я получим нито с мой MQTT брокер (ако тръгна да пиша), нито с SQL база написана от някой именит професор от габровското ТУ.


Тук имаме много сериозни разминавания... Аз затова ти казах, че ти трябва разговор с професионалисти в тая област. В случая на теб ти трябва както теоретични познания, така и практични. В теорията си има закони. Примерно не можеш да направиш надеждна синхронизация по ненадежден комуникационен канал, ако щеш гъза си да скъсаш. От там насетне ти си преценяваш дали в конкретното приложение ти е нужна синхронизация и колко надеждна. Или ще работиш по централизиран модел. Изборът си е изцяло твой, теорията обаче ти гарантира възможните и невъзможни резултати. Това че някой ти е централизирал системата съвсем не означава че просто така го е кефело повече. Може да е имал съвсем сериозни причини и дано не се налага да ги разбереш пост фактум.
А в практиката... там нещата са утъпкани и също така много специфични. Разбира се може да си правиш експерименти с клиенти на домашен компютър, но ти говореше за корпоративни клиенти и повярвай ми те няма да ти разрешат да се бъзикаш. Ако така, както обясняваш тук им обясниш архитектурата си, опасявам се че ще ти покажат вратата наистина. Ако трябва да правиш нещо в тая област, при всички случаи ще ти се наложиш да ползваш готови решения. Искаш или не искаш, то просто няма избор. Навремето и аз имах едни първоначални виждания, но седнах поговорих с няколко човека, начукаха ми канчето, а сега съм им благодарен;-)

Накратко защо SQL... първо от SQL до SQL сървър има огромна разлика. Когато гониш надеждност в една архитектура ти трябва "носеща конструкция". Тая носеща конструкция почва от съответните основи/фундаменти, после яко колони и така до покрива. Здравината се определя от най-ниското ниво (фундамента), ако ти е кекав фундамента естествено няма как да направиш по-здрава сградата с модерна козирка. И така почваш отдолу и градиш нагоре, като на всяко ниво здравината обикновено намаля щото както казах е безсмислено покрива да е по-здрав от основите.
В нашия случай е същата работа. Почваш от хардуера в рака. Естествено ако избереш чуплив хардуер, нагоре не може през софтуера да направиш по-нечуплива системата. После тръгваш от RILO-то (remote lights out) и почваш да наливаш софтуера. Инсталираш едно-друго, част от софта готов, част ти го пишеш. Две неща са важни - едното е, че колкото по-нагоре отиваш, става по-нестабилно. И другото е, че гледаш колкото по-нагоре стигаш толкова по-малко подробности да те интересуват. Примерно бояджията не го интересува дали стената е носеща или интериорна. И не би трябвало да го интересува нали...
Простичко казано, архитектурата нагоре трябва да ти дава свобода и възможност да си развихриш фантазията, а отдолу да ти осигурява нужната здравина, за да не срутят всичките ти красотички. Къде в тая картинка са SQL и MQTT?
Ролята на един SQL е да ти подсигури фундамента. Ти си решаваш колко здрав ти е нужен. Както казах има всякакви SQL-и. Може да го инсталираш като юзер приложение на пиклив домашен компютър, а може да е система от няколко сървърни машини, всяка с RAID-ве, с репликациите му, с редунданситата и т.н. Хубавото е, че погледнато отгоре все си е SQL, т.е. не те интересуват подробности като счупване на файлове, счупване на една от машините или че един или няколко диска са сдали багажа. Цялата здравина на целия фундамент отдолу стига до ниво SQL. Даже ако си направиш транзакциите като хората отиваш и по-нависоко, т.е. дори нещо по комуникациите да се счупи ънролваш и данните ти остават коректни, а не мазани-недомазани. Всичко това може да го вземеш като готово решение и да стъпиш върху него, или тепърва да откриваш топлата вода. Изборът е твой, но не съвсем, както казах сериозните клиенти ги проверяват тия неща и надали ще ти позволят да си правиш експерименти.
Относно MQTT... хубаво, бил удобен, мощен и т.н. ОК, така да е. Но какво ми помага това ако се скапе диск, ако се скапе машина или кабела дропне? Можем да говорим за сравнение между MQTT и PHP, но те и двете нямат нищо с SQL. Първите са инструменти за функционалност, докато другото е част от фундамента. Действително, ако правиш барака може да шунтираш основите. Но за по-сериозна постройка, просто се шегуваш. Тия приказки как еди кое си оставало "излишно" в SQL, ми извинявай... не е сериозно просто. Или не разбираш защо се ползва SQL или ковеш барака.

И нещо друго, което не е свързано с горното.... Как ще си изграждаш организацията над фундамента е нещо което сам си решаваш и имаш избор. Няма еднозначно решение. Но от моя опит, колкото повече разделяш клиентите от устройството, толкова по-добре. Идеята да прескачаш сървъра като излишен посредник не ми харесва. Ние също имаме почти реал тайм комуникация. Не че е фатално, но примерно като застанеш пред един терминал да си платиш една сметка не ти се чака много докато информацията първо се извлече от доставчика, докато се разбереш с платежния оператор. Обикновено искаш да цъкнеш и да ти изкара веднага бележка. Така че и при нас връзката през някакъв междинен сървър дето нито може да каже сметката нито да направи плащане изглежда излишна. Ама не е. В общия случай устройствата са различни, другите сървъри и клиенти пък е по-добре да не се намесват, тъй че един посредник през който да минават нещата решава много проблеми. Ти както говориш за устройство с 14000 параметъра (числото изобщо не е голямо), а сега си представи че устройствата станат 10-15-20. И едното е с 12, другото 14, трето 20 хиляди и т.н. На твое място не бих искал крайния клиент да трябва да знае с какво устройство си има работа, то с колко параметъра е и те каква стойност имат поименно. Един централен як сървър може да работи с много устройства и много параметри, но клиент и то през телефон... не много объркано ще стане. При нас устройството обикновено си говори с един или няколко сървъра. За по-сложните неща на самия съвър има "преводачи", които обират повечето специфики на отделните устройства и до базата стигат що-годе разбираеми данни. Освен това сървъра (както всеки сървър) предлага навигации, демек клиент като се върже не почват да му се изсипват хиляди параметри, ами първо през сървърните страници си избира какво иска да гледа, как да е систематизирано и как да го гледа. Така че "преводачи" има както от страната към устройствата, така и от клиентите. И всеки си говори само неговия език. Отделените модули е добре да са относително независими, т.е. не само че говорят независими езици, ами функционалност и т.н. Целта е да може да добавяш или променяш отделни части на системата, без да се налагат революции.


Съб Яну 21, 2017 1:18 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог
Аватар

Регистриран на: Сря Апр 27, 2005 11:48 am
Мнения: 1677
Мнение Re: Питане за облачни архитектури
....пълноценен node.js струва под $5...
като го вкараш в индустриалните стандарти, като го защитиш от гръмотевици, влага... етц почва да струва $500
От това което чета започвате от (copy/paste) Линукс нагоре, а някак си все още го анатемосвам за индустрия та дори и за HMI - някъде да си видял HMI на линукс
За "битови" джаджи става - сега следва трудната част да организирате над 1000 устройства да бълват данни към ОБЛАКА, за които да има логическо и икономическо потребление

_________________
main[-1u]={1};
http://www.wizio.eu/


Съб Яну 21, 2017 2:36 pm
Профил ICQ
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Пон Мар 13, 2006 12:59 pm
Мнения: 2788
Местоположение: Габрово
Мнение Re: Питане за облачни архитектури
Хареса ми преди малко че се обърнахме към реални проблеми, ама сега пак го завръщате на общи приказки. Може би проблема е донякъде че отговарям едновременно на Миро и на Wizard, сигурно ще трябва да карам поотделно.
Първо, домашното ПЦ влезе в разговора от Визарда - имам предвид неговото описание за паркинга. Моята теза беше друга - дали ще е домашно пц, дали ще е рак, дали ще е нает сървър някъде, дали ще е платформа наета в облака от типа на амазон, не искам да има значение за "моята" постановка. Виж, ако написано от някого ДЛЛ-че за windows нещата стават сложни.
Клиенти на домашен компютър - мисля че си много реалистично като изискване - говорим за броузъра или фронтенд-а. Определено не смятам в кода да се проверява дали устройството е "домашно" и ако е служебен компютър или работна станция да му се отказва достъп :)
Дали modbus бриджа ще тича на същото ПЦ - може, няма проблем, ако конкретния клиент го иска ще стане - защо го иска си е негова работа - не иска да е зависим от интернет, не иска да рискува да го хакнат отнейде (през някоя непокрита виндоуска дупка), няма значение. За архитектурата това не е проблем.
По същия начин както има много SQL бази данни (и ще излязат сигурно и по-добри) има и различни MQTT брокери. Ако основателно те е страх да пуснеш node.js-ския mosca отиваш при IBM и вземаш техния. Има още няколко платени, реномирани, много ползвани брокери които можеш да ползваш - при теб или хостнати - както искаш. Въпрос на изисквания към даденото приложение и по никакъв начин не променящи архитектурата.
Имам предвид че качеството си е качество независимо за какво говорим - не можем да сравняваме концепции приемайки че едната ще слага само безплатни и непроверени компоненти, а другата да я мерим с платени неща вървящи на скъпи железа в още по-скъпи сгради.
За централизирането - не бих бил категоричен че някъде някой не е направил централизацията само по навик, но как беше - всеки има право на лош вкус.
Кога съм казал че няма да има централна точка? Дори виртуално да я има в определени частни случаи (понеже върви на същия хардуер където върви някое от другите - за да е по-бързо и изгодно) тя е там. Отделен софтуер който може да се "отдели" и сложи на различни места.
В момента в който говорим за отдалечена централна точка се сблъскваме с проблема за надеждност на комуникацията - това няма значение дали е SQL или MQTT. И двете са достатъчно напред за да предлагат мерки в това отношение - тук въпросът е ако решим да ги сравним за да видим кое къде е и да видим слабите точки на двете решения. Аз бих си представил че има трето което е в пъти по-добро - не знам вие как мислите. MQTT има идея за unreliable messaging и има разширение - MQTT-SN за още повече възможности и по-леки клиенти.
Разликата е в това какви функции поема тази задължителна централна точка и как ги композира. Няма универсално решение и затова опита всичко да мине през SQL-a е затормозяващ. Представи си система в която телефона и машината са в една подмрежа, примерно закачени към едно и също АП. Връзката към интернет е 100б/с когато я има (вечер между 10 и 11 часа само). Пак ли ще твърдим че трябва да ходим до централния рак да четем по SQL-а за да му покажем температурата? В такива крайни случаи може би дори ще се откажем от брокера - фронтенд-а ще достъпва сървъра в устройството. Само че тънката линия е че устройствата, на които можеш да пуснеш сериозен SQL са малко по-скъпи, тромави, бавно бутващи, капризни, и по-малко като брой хардуери отколкото такива на които можеш да подкараш http сървър например. И че при равни други условия гарантирано ще са по-малко надеждни. Някъде по средата е MQTT - работи прилично на 100МHz процесорче и може да мине без сторидж даже!
Отклонение - наскоро някакъв питаше дали може да се пусне mqtt брокер на esp8266 - реално може, някакъв румънец го е направил, но проблема е че TCP/IP стека на есп-то има ограничен брой връзки - май 16. Той е прекомпилирал стека (LWIP) и ги е качил до 25 май. И го е тествал с 20 и няколко клиента. На ЕСП за 2 долара франко пощенския клон до у нас! Защо са ограничени - ми горкото есп има малко (десетки Кбайти) RAM.
Вярно, http сървър и клиент върху есп работи отдавна и доста добре. Разликата обаче не е голяма - http сървъра пак е зависим от тия 16 или 25 връзки на стека.
Сега, да вземем да видим как ще пуснем SQL на есп ... или да не гледаме?
За да не се отклоним - няма да ползвам есп, говоря да се ограничим до сравнението на 100МХз процесорче в добро индустриално устройство, срещу GHz x86 сървър в индустриално изпълнение. Знам че в ITR има маркови машини за 50лв, нека не ги слагаме в уравнението. Ако някой натиска да си плати за да слага нашия софтуер на такова нещо - аз нямам нищо против парите му, с уговорката че гаранцията за хардуера да си я търси в Бургас.
SQL е сериозно нещо, но проблема е че както повечето продукти с неговия бизнес модел и от ерата от която идва, се опитва да изяде цялата баница, че ако може и айряна да задигне, и да те накара доживот да ядеш само баници. Налага концепция, ограничава свободата да се ползва друга. Вкарани са много отделни функционалности, които са вързани към определена файлова система, и към определен OS да кажем, и идеята е да си купиш цялото - да, получаваш цялостно решение. И да, губиш един тон гъвкавост. И да, ако се окаже неподходящ за друго приложение изборът е да го изхвърлиш целия (понеже не можех да промениш отделните части или концепцията).
Да, готин е че има книжки на български, голям процент от курсови и дипломни работи са Apache/PHP/SQL и има масовка да я вземеш да кърти.
За N-ти път се опитвам да кажа нещо - MQTT прави едно от нещата който прави SQL, и го прави добре и гъвкаво. Останалата част като persistence, анализ на данните е извън MQTT - не че не могат да го компилират вътре, но е грешен подход. Онзи брокер за node.js - mosca.io на сайта си е свързан с няколко различни бази (мисля че все no-sql). Но никой не ми налага да ползвам еди коя си база, или дори не ми налага да ползвам база ако нямам нужда от persistence. SQL-а го прави наобратно - дай да сложим всичко, да, бавничко ще е в някой случаи ама нищо - да си купят по-бърз сървър и/или сторидж. Ако не искат да си гледат работата - те са малка част от пазара, на нас са ни важни големите.

Архитектурата с MQTT е друга - ако има нужда от persistence се добавя като отделно нещо - модул, плъгин. Може да се реализира като отделен клиент на брокера който да слухти за конфигурираните му данни (не всички, безумно е - може да е конфигурирана за писане само една температура от 14444 параметъра) и да ги пъха в нещо - кеф ти SQL, кеф ти масив в паметта, кеф ти някъде из облака или друго.


Съб Яну 21, 2017 3:44 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Пон Мар 13, 2006 12:59 pm
Мнения: 2788
Местоположение: Габрово
Мнение Re: Питане за облачни архитектури
TheWizard написа:
някъде да си видял HMI на линукс

Не знам колко съвременни HMI, PLC-та, CNC-та и SCADА-и си разглеждал, но има доста. Да не говорим че останалите в масовия случай не ползват Windows ами скъпи RTOS-и. Има някой екзотики с Windows и са от най-добрите въпреки това, но там допълнението дето го прави тоя windows real-time на дребно чини хилядарка на ПЦ. Е, за много бройки сигурно е 10-20% от тази цена, не знам.
Неща като OpenGL и другите му наследници се ползват най-лесно през голяма операционна система - не става през FreeRTOS. Ускоренията на 2д и 3д като цяло, на видео, искат големи драйвери дето рядко са свободни. Да не говорим че голяма резолюция + 3д + мързеливи писачи не минават с по-малко от гига рам и се мръщят на едноцифрен брой ядра... Клиентите се радват като видят на екрана реалистично копие на вала им дето го стърже машината им в момента.
И аз имам някой задръжки като видя линукс за ембедед - основно по real-time концепциите им и по-точно по някой от вариантите им, по стартъпа. Но пущината някак си се нагнезди - една от причините може да е мързелът на хора като мен които затварят очите пред недостатъците и гледаш шаренията - точно както node.js, само засега не му знам недостатъците :lol:


Съб Яну 21, 2017 3:55 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог

Регистриран на: Нед Фев 26, 2006 5:52 pm
Мнения: 7712
Местоположение: Добрич
Мнение Re: Питане за облачни архитектури
gicho написа:
По същия начин както има много SQL бази данни (и ще излязат сигурно и по-добри) има и различни MQTT брокери. Ако основателно те е страх да пуснеш node.js-ския mosca отиваш при IBM и вземаш техния.

Пак ти казвам, от гледна точна на архитектурата на една система SQL има функция на фундамент. Докато PHP, МQTT са по-скоро интериорна украса. Разбира се ако вземеш готово решение от IBM или друг сериозен то под блажната боя отдолу ще има вероятно много стабилна основа. Но тук възниква въпросът чисто практически ти как ще направиш поддръжката на тая система. Дали ще плащаш на IBM да реагират в рамките на минути независимост коя част от денонощието и кой ден е в годината?
Аз ти казах, когато опре яйцето до задника избираш нещо, което може да намериш хора да ти го изградят и поддържат на разумни цени. И на които вярваш естествено. И тъй като ние сме малка държава, твоите и моите финанси не са безгранични, то потенциалните хора дето могат ти свършат работа се броят на пръсти. Дано намериш някой дето може да изгради система по твоите изисквания, но ме съмнява... Пак казвам, че в моя случай аз се съобразих с техните изисквания, а не обратното.


Цитат:
Няма универсално решение и затова опита всичко да мине през SQL-a е затормозяващ. Представи си система в която телефона и машината са в една подмрежа, примерно закачени към едно и също АП. Връзката към интернет е 100б/с когато я има (вечер между 10 и 11 часа само). Пак ли ще твърдим че трябва да ходим до централния рак да четем по SQL-а за да му покажем температурата?

Да, пак ще ходим. Представи си другата ситуация - имаш една машина в село долно-нагогорно и сървър на оптика нейде няма значение. Ако гледаш с телефон от същото село е едно, ако гледаш с телефон от Лондон - друго и ако гледаш през 1000 телефона едновременно тая машина е трето...
Ако ти мислиш че има много смисъл да се оптимизира варианта "селянина с телефона" ОК, но въпросът изобщо не е в това. И преминаването през централен сървър не е с цел оптимизация на трафика (само).
От гледна точка на архитектурата е важно дали ще имаш разделяне и независимости или няма да имаш. Когато минаваш през сървър, той освен всичко друго разделя и може да направи независими устройства и клиенти. Дори с най-съвременните средства е адски трудно да се поддържат всякакви клиенти. Знаеш, че като отвориш един сайт с един браузър работи, с друг не работи и колко е мазало всичко. Едва ли искаш да вържеш директно телефон с ембедед устройство и такава да ти е системата. Как си го представяш това от гледна точка на поддръжка? Брр... аз от такива неща бягам по-бързо отколкото дявол от тамян!
И как точно ще работи това с плъгини, а имаш ли плъгин за вей-хуй компакт 2 ?? :D


Съб Яну 21, 2017 4:57 pm
Профил
Ранг: Форумен бог
Ранг: Форумен бог
Аватар

Регистриран на: Нед Ное 21, 2004 10:31 pm
Мнения: 8686
Мнение Re: Питане за облачни архитектури
gicho написа:
За N-ти път се опитвам да кажа нещо - MQTT прави едно от нещата който прави SQL, и го прави добре и гъвкаво.

я по-подробно от тук нататък?

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

или съм изтървал някой фючър на MQTT :-|

---
никой не ти говори за SQL в ПИК.
гролям брой на конекциите в esp8266 също е нон-сенс. и въобще да се разчита на LWIP за серозно неща е под критика също.
не ти ли светка някоя червена лампичка, защо ЕСП струва $2 доставено до пощенската ти кутия?


Съб Яну 21, 2017 5:24 pm
Профил
Ранг: Почетен член
Ранг: Почетен член

Регистриран на: Пет Юни 03, 2005 8:39 pm
Мнения: 805
Мнение Re: Питане за облачни архитектури
gicho написа:
...Ако например батката иска паркинга поне локално да работи (т.е. чичката да не чупи пръсти да обяснява че няма нет и бариерата няма да се вдигне да си тръгнат хората)....

Летище София, септември - няма система (какво и да значи това), няма паркинг(на паркинга места колкото искаш) - докато търся къде да паркирам много пъти си представях как бавно извивам вратлето на малоумника измислил и внедрил "системата"...

_________________
Определянето стойността на дадена величина се нарича ИЗМЕРВАНЕ!


Съб Яну 21, 2017 6:33 pm
Профил
Покажи мненията от миналия:  Сортирай по  
Отговори на тема   [ 101 мнения ]  Отиди на страница Предишна  1, 2, 3, 4, 5, 6, 7  Следваща

Кой е на линия

Потребители разглеждащи този форум: 0 регистрирани и 1 госта


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

Търсене:
Иди на:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software for PTF.
Хостинг и Домейни