Jak skalować websockety?

Mój pomysł na pracę dyplomową na podyplomówce Big Data o streamowaniu danych zaczyna się komplikować.
Nie pomyślałem wcześniej o tym jak będę skalował tę aplikację, a o to przecież chodzi w tym całym Big Data.

W skrócie aplikacja będzie robić to:

O ile Apache Kafka czy Postgres umie działać na klastrach, więc się skaluje o tyle Springowe Websockety nie.
Potrzebuję jakiegoś brokera STOMP? ActiveMQ? RabitMQ z biblioteką do STOMP?
No, bo na front streamować z Kafki to chyba słabe rozwiązanie?

Jakiś broker wiadomości, może być RabbitMq albo Redis. Chociaż masz już tam Kafkę, to nie wiem po co dokładać.

A dlaczego websocket, a nie np. HTTP/2 push albo SSE? Jak będziesz skalowalnoć websockety na load balancerze?

I co robi tam ten biedny Postgres w świecie Big Data? :)

Ogólnie też bez konkretów nt. wolumenu danych, liczby użytkowników, wymagań odnośnie latency ciężko coś zaproponować sensownego. Może dałoby radę to opazdzierzyć na postgresie i zrobić zwykły polling. Wyjdź od czegoś prostego.

Charles_Ray napisał(a):

Jakiś broker wiadomości, może być RabbitMq albo Redis. Chociaż masz już tam Kafkę, to nie wiem po co dokładać.

Kafka nie obsługuje protokołu STOMP...

A dlaczego websocket, a nie np. HTTP/2 push albo SSE? Jak będziesz skalowalnoć websockety na load balancerze?

no właśnie nie wiem jak...

I co robi tam ten biedny Postgres w świecie Big Data? :)

A jaką inną bazę proponujesz?
Dane będą ustrukturyzowane. Postgres skaluje się elegancko i ma dedykowaną wersję do szeregów czasowych: timescaledb

Co tu jest chyba fundamentalnie nie tak, wyglada jakby było mega scouplowane. Na Kafce masz eventy, które konsumenci pushują do websocketa i dopiero tam mówimy o stompie.

Nie znam tej bazy i nie wiem co tam chcesz trzymać - może to być use case na Cassandrę, może na Influxa, ale nie znam wymagań :)

Ogólnie poczytaj o Lambda/Kappa Architecture, nie musisz wynajdywać koła od nowa.

Z ciekawostek to jest coś takiego jak CockroachDB i jest to rozproszona baza danych dość dobrze udająca Postgresa (na poziomie protokołu i SQL).
Udawanie postgresa na pewno działa dobrze. Co do skalowania to niestety poza "marketingiem" wiem niewiele więcej - mam za małe (na razie) aplikacje na tym.

Pisałeś tu https://4programmers.net/Forum/Off-Topic/350683-websocket_do_notowan_kryptowalut?p=1755998#id1755998 że będziesz dane z sieci zasysać. Rozumiem, że w jakiś sposób przetworzysz te dane i wyslesz na swój front. Sorry, jeżeli coś upraszczam, ale po co w ogóle Ci w takim razie jest Postgress, znaczy właściwie DB w ogólności? Co Ty w tej DB chcesz trzymać?

Charles_Ray napisał(a):

Nie znam tej bazy i nie wiem co tam chcesz trzymać - może to być use case na Cassandrę, może na Influxa, ale nie znam wymagań :)

PanamaJoe napisał(a):

Pisałeś tu https://4programmers.net/Forum/Off-Topic/350683-websocket_do_notowan_kryptowalut?p=1755998#id1755998 że będziesz dane z sieci zasysać. Rozumiem, że w jakiś sposób przetworzysz te dane i wyslesz na swój front. Sorry, jeżeli coś upraszczam, ale po co w ogóle Ci w takim razie jest Postgress, znaczy właściwie DB w ogólności? Co Ty w tej DB chcesz trzymać?

np. tak o:

To DB to w sumie kij z nim, może go nie być, ale kafka ma connectory, więc to mam za darmo.** Problem jest w tym, że z Apache Kafka Streams nie wiem jak wysłać na front.**

Problem jest w tym, że z Apache Kafka Streams nie wiem jak wysłać na front.

Pierwszy wynik w Google https://www.confluent.io/blog/webify-event-streams-using-kafka-connect-http-sink/

Jak pisałem wcześniej, nie tylko websockety są na świecie, tym bardziej, że nie potrzebujesz komunikacji w 2 strony.

@NamingException: W Quarkusie np, możesz zmapować kafkowy topic na reactive Publisher, a następnie wystawić taki publisher jako SSE endpoint.

Czyli co ma od razu z kafki na front słać?

kafka -> Quarkus -> SSE
brzmi dobrze

Przykładowy kod:

    @Incoming("sseIncoming")
    @Outgoing("sseChannel")
    @Acknowledgment(Acknowledgment.Strategy.PRE_PROCESSING)
    public SpecificRecord toSSE(Message<SpecificRecord> message) {
        return message.getPayload();
    }

    @Inject
    @Channel("sseChannel")
    private Publisher<SpecificRecord> events;

    @GET
    @Path("/stream")
    @Produces(MediaType.SERVER_SENT_EVENTS)
    @SseElementType("text/plain")
    public Publisher<SpecificRecord> stream(String param) {
        return events;
    }

Sse-incoming jest zmapowany na kafka topic. Jak zaatakujesz ten endpoint z przeglądarki dostaniesz SSE eventy z każdym kafka eventem na topicu.

A jak to skalować? On na Kafce robi endpoint SSE, tak? Czy robi endpoint z kafki do SSE

Pobiera eventy z kafki i publikuje je ze swojego reactive Publishera (akurat w tym przypadku na tego publishera jest zmapowany topic kafkowy bo pasuje do Twojego use-casu, równie dobrze możesz utworzyć swojego publishera ze statycznych danych).
Jeśli chciałbyś mieć więcej takich serwisów, musiałbyś tworzyć każdy z inną kafka-consumer-grupą.

Ludzie przecież jaki kolega framework zastosuje jest absolutnie wtórne :D zmiana pakietu, z którego pochodzą adnotacje nie pomoże architekturze

@Charles_Ray: To była raczej kontynuacja Twojej myśli, żeby wykorzystać SSE by na biężaco updatować front.
Twój komentarz sugeruje, że websockety trudniej skalować niż SSE. Możesz rozwinąć dlaczego?

Utrzymywanie stałego dedykowanego połączenia websocketowego (pierwotne połączenie http + TCP) wymaga więcej zasobów na load balancerze. Hardkorowych detali nie znam, można doczytać na blogu haproxy.

Pytanie co tak naprawdę to ma robić. Zakładając, że UC jest taki - dane lecą z live-feedów i powinny trafiać zarówno do frontu, jak i na dysk - to pomiędzy Kafką i frontem potrzebujesz jakiegoś skalowalnego cache'a.
To może być albo taki faktyczny skalowalny cache (Ignite, Redis), albo timeseries database (to zależy od scenariusza - ja korzystałem tylko z InfluxDB, KDB+ i Azure TS Insights).
Jeśli chodzi o zapis na dysku to sky is the limit. Podobno nawet Kafka daje radę do trzymania danych, ale nigdy nie korzystałem - ale to by znaczyło, że stack technologiczny ładnie się redukuje do Kafka + cache + ewentualnie coś jako bramka do cache'u.