Będę musiał wysyłać często informacje między różnymi instancjami na tym samym serwrze.
Używałem redisa pub/sub i działało całkiem miło, lecz chciałbym spróbować czegoś innego. Myślałem nad rabbitmq, ale może coś jeszcze ciekawego znajdę.
RabbitMQ to nie baza tylko Message broker. A co do baz noSQL to reaktywne mongoDB daje czadu.
Poza tym, co ma częste wysyłanie informacji między instancjami do utrwalania tychże danych?
Najszybsza baza
a potem
redisa pub/sub
rabbitmq
WTF? :D
Napisz jasno co chcesz osiągnąć i jaki typ komunikacji cię interesuje:
- synchroniczny/asynchroniczny?
- jeden odbiorca/wielu odbiorców?
- możliwe duplikaty wiadomości czy nie?
- odczytanie wiadomości ją "usuwa" czy może chcesz mieć możlowość przetworzenia wiadomości jeszcze raz od jakiegoś miejsca?
Bo generalnie wygląda jakbyś chciał coś w stylu -> message queue albo notyfikacje publish/subscribe albo event stream, ale trudno ocenić nie wiedząc co dokładnie chcesz osiągnąć. Niemniej NIC z tego nie brzmi jak baza
.
async, pojedyńczy odbiorca, wystarczy że raz przetworzy, brak duplikatów
ma to bardziej służyć do komunikacji między instacjami
No to generalnie brzmi to jak klasyczne Message Queue, a konkretna kolejka to już kwestia twojego wyboru. Możesz dla prostoty napisać to w oparciu o JMS a potem wpiąć sobie takiego providera jakiego uznasz za najlepszego (albo przetestować ich kilka).
To jak jużsię pojawił taki temat to spytam ekspertów.
Jaka będzie najbardziej optymlana baza danych dla obrobki 20/30GB danych dla kazdego klienta (zalozmy ze jest ich 1000) raz dziennie dla kazdego? Zalezy mi na jak najszybszym czasie wyliczenia tychże plus w bazie bedzie znajdowac sie okolo paru tera danych historycznych do ktorych dostep bedzie potrzebny raz na jakis czas
@komuher AWS S3 + Athena? Albo analogicznie rozwiązanie w stylu Google BigQuery. Athena kosztuje 5 centów / 1TB przeskanowanych danych.
Doprecyzuj co u Ciebie znaczy obróbka danych? Mały zbiór danych wejściowych może wygenerować Ci masę zapisów, a ograniczony RAM masę odczytów.