socket.io vs RethinkDB changefeed

Najpierw wyjaśnijmy związek między socket.io / align = "left" / Socket.io jest przeznaczony do komunikacji w czasie rzeczywistym pomiędzy klientem (przeglądarką) a serwerem (węzłem.js). RethinkDB changfeeds to sposób na twój serwer (Node.js) do nasłuchiwania zmian w bazie danych. Klient nie może komunikować się bezpośrednio z RethinkDB.

Bardzo typową architekturą dla aplikacji w czasie rzeczywistym jest RethinkDB changefeeds Subskrybuj zmiany w bazie danych, a następnie użyj socket.io na przekaż te zmiany klientowi. Klient zazwyczaj emituje również wiadomości, które mogą zostać zapisane do bazy danych, w zależności od logiki aplikacji.

Tak, możesz po prostu emitować wszystkie wiadomości przez socket.io następnie przekaż wszystkie wiadomości do wszystkich klientów, a następnie po prostu zapisz te wiadomości do bazy danych dla trwałości. Prawdą jest również, że jest to szybsze, ale istnieje wiele wad tego podejścia.

1. Baza danych jako jedno źródło prawdy

The najprostszym problemem do wykrycia jest:

• co się stanie, jeśli Twoja aplikacja nie będzie w stanie napisać czegoś do baza danych?
• co się stanie, jeśli dane, które próbujesz wstawić do bazy danych, są nieprawidłowe lub zduplikowane? Czy piszesz logikę aplikacji do obsługi tego?
• co się stanie, jeśli węzeł.serwer js pada przed wysłaniem napisz zapytanie?

To tylko kilka szybkich przykładów, w których, ze względu na swoją architekturę, stracisz lub masz brak synchronizacji danych. I żeby to powtórzyć, stracisz dane, ponieważ głównym źródłem prawdy jest pamięć. Możesz również mieć rozbieżności między danymi w węźle.aplikacja js i twój DB.

Chodzi o to, że baza danych powinna być zawsze twoim jedynym źródłem prawdy i powinieneś potwierdzić dane tylko wtedy, gdy są zapisywane na dysku. Nie jestem pewien, jak ktoś mógłby spać w nocy inaczej.

2. Zaawansowane Zapytania

Jeśli zdasz wszystkie nowe wiadomości od wszystkich klientów do wszystkich klientów poprzez socket.io musisz teraz mieć dość złożoną logikę w swoim kliencie, aby odfiltrować wszystkie dane, które są rzeczywiście ważne. Weź pod uwagę, że przekazujesz wiele bezużytecznych danych przez sieć, których Klient nie użyje.

Alternatywą jest napisanie systemu pub/sub, w którym subskrybujesz określone kanały (lub coś w tym stylu), aby odfiltrować dane, które są rzeczywiście ważne dla klient.

RethinkDB rozwiązuje to poprzez dostarczenie własnego języka zapytań, który możesz dołączyć do changefeeds. Jeśli klient, na przykład, potrzebuje wszystkich użytkowników w mojej tabeli users w wieku od 20 do 30, którzy mieszkają w stanie Kalifornia, 10 mil od San Francisco, i którzy kupili książkę w ciągu ostatnich 6 miesięcy, może to być wyrażone w ReQL (RethinkDB ' s query language) I changefeed może być ustawiony dla tego zapytania, tak że klient otrzymuje powiadomienie tylko wtedy, gdy istotne zmiany. To jest o wiele trudniejsze do zrobienia z tylko Socket.io i węzeł.js.

3. Skalowalność

Ostatnim problemem, który rozwiązuje RethinkDB jest to, że jest to znacznie bardziej skalowalne rozwiązanie do przechowywania wszystkiego w pamięci (poprzez Socket.io i węzeł.js). Ponieważ RethinkDB jest zbudowany od podstaw do dystrybucji, możesz mieć klaster ponad 20 węzłów RethinkDB z odłamkami i replikami. Każde Twoje zapytanie RethinkDB jest domyślnie dystrybuowane. Teraz możesz mieć 20 + innych węzłów.węzły js, które są bezpaństwowe i wszystkie słuchają changfeeds. Ponieważ baza danych jest głównym źródłem prawdy, nie stanowi to problemu.

Alternatywą byłoby ograniczenie się do jednego serwera, posiadanie jakiegoś innego systemu pub/sub (zbudowanego na czymś takim jak na przykład Reddis), posiadanie tylko jednej bazy danych, którą sprawdzasz... Pewnie jest więcej przykładów, ale widać do czego zmierzam.