Aktywne Wpisy
Skallagrimsson +50
MaxWalonkoo +88
Wakacje z dziewczyna i teściowa to jest jakiś dramat, nie polecam XD
Jesteśmy w górach i oni nigdzie nie chcą iść, żarcie wybierają pod brata dziewczyny. Idziemy tam gdzie brat dziewczyny chce. Śpię do 11? Dramat, to nic że codziennie wstaje o 6:50 i chciałbym chociaż raz się wyspać. Bolał mnie brzuch? No to źle bo nie miałem humoru. Chce posiedzieć sam w sypialni? Źle bo nie siedzę z nimi, a jak
Jesteśmy w górach i oni nigdzie nie chcą iść, żarcie wybierają pod brata dziewczyny. Idziemy tam gdzie brat dziewczyny chce. Śpię do 11? Dramat, to nic że codziennie wstaje o 6:50 i chciałbym chociaż raz się wyspać. Bolał mnie brzuch? No to źle bo nie miałem humoru. Chce posiedzieć sam w sypialni? Źle bo nie siedzę z nimi, a jak
Aktywne Znaleziska
1. Docelowo to ma być komputer mający na pokładzie 256 MB RAM. Czy używanie Redisa to dobry pomysł? Chciałem go wybrać żeby aplikacja była wydajniejsza na słabym sprzęcie, jednak zastanawiam się czy on nie będzie zajmował za dużo RAM-u.
1.a. Jak zrozumiałem technologie typu Kafka czy RabbitMQ nie przechowują danych w RAMie, więc one go nie będą tak zjadały, ale za to będą wolniejsze, zgadza się? Czy są jakieś argumenty za tym żeby je wybrać a nie Redisa?
2. Jak to jest z komunikacją Pub/Sub i jego niezawodnością? Jak czytałem Streamy gwarantują przesłanie zainteresowanym komunikatu, a Pub/Sub nie bo to działa na zasadzie wystrzel i zapomnij. Czy to jest coś czym powinienem się przejmować jeśli mówimy o przesyłaniu komunikatów pomiędzy mikroserwisami na tej samej maszynie fizycznej, gdzie nie ma jakiegoś ryzyka przerwania komunikacji i zgubienia przez to wiadomości? Mówimy planowo o maksymalnej liczbie do 2500 komunikatów na sekundę.
ja sobie sensory/aktuatory pcham przez MQTT ale tego jest raptem w porywach kilka/s i to dobrze działa ale zoptymalizowałem tak, żeby szło paczkami no i pomiędzy różnymi urządzeniami
@kwanty: W sumie bardziej IIoT. Dane odczytywane za pomocą driverów Modbusa, S7 i inne przemysłowe protokoły - odczyt 2500 danych pomiarowych/sekundę to nie jest jakoś dużo dla tych protokołów, jak idzie paczkami( ͡° ͜ʖ ͡°) A z nich pchane do Redisa czy innego brokera komunikatów żeby
@Wegrzynski: Z IoT to tak średnio ma to cokolwiek wspólnego. Do tego jeszcze Redis i mikroserwisy. Pozwolę sobie zacytować klasyka - schlubnie, chociaż nasrane. Co to za cudo ma w ogóle robić?
@Wegrzynski: ok, rozumiem :-) pytanie czy dobrze to rozkminiasz, jeżeli to jest strumień danych to może nie trzeba traktować każdy z punktów pomiarowych osobno (jako niezależny message) tylko właśnie jako strumień.
A tak w ogóle to jak masz serię danych to rzuć okiem na bazy typu VictoriaMetric - one są zoptymalizowane właśnie pod serie danych i optymalnie to reprezentują (np. pozwalają upraszczać sekwencje takich samych
Jak potrzebujesz tylko event bus to polecam https://nats.io/. Możesz sobie strumienie skonfigurować czy mają trzymać dane w ram czy na dysku.
Sam broker też ma dobre skalowanie. Może działać zarówno na jednej Malince jak i na rozproszonym środowisku
@groman43: Poprawiłem się wyżej - bardziej IIoT, 2000 komunikatów to można zbierać z jednej maszyny przemysłowej ( ͡° ͜ʖ ͡°) Eksperymentalny Historian i koncentrator danych z maszyn.
@Wegrzynski: O tak! bo jak to zrobisz nieefektywnie to będziesz miał gigantyczny overhead na samym "przesyłaniu/segregowaniu/wyłuskiwaniu". Z tego powodu Google w pewnym momencie zrezygnowało wewnętrznie z REST i przeszli na protobuf