Najlepsze praktyki programowania funkcjonalnego Scala lub Clojure

11

Dużo sam kodowałem, miałem trochę doświadczenia z równoległymi modelami programowania: aktorzy, pamięć transakcyjna oprogramowania, przepływ danych.

Kiedy próbuję zastosować te architektury w prawdziwym życiu - do aplikacji sieciowej o dużym obciążeniu - żaden model nie obsługuje trwałości i trwałości danych. Rzeczywiste zadania wymagają zapisania danych na końcu. Oznacza to, że nadal muszę używać DB i pułapek synchronizacji DB, możliwych skalowalności szyjek butelek itp.

Czy ktoś zna dobry przykład architektury (src, tekst, diagram lub plany), która korzysta z Akka Actors lub pamięci transakcji oprogramowania i implementuje trwałość na końcu?

Każdy dobry przykład / pomysł na pamięć transakcyjną, aktorów, przepływ danych, przestrzenie krotkowe w rzeczywistych aplikacjach jest mile widziany.

scala clojure functional-programming

— komar
źródło

Potrzebujesz zarówno akka, jak i stm?

— om-nom-nom

Wydaje się niezwykłe, że traktujesz wytrwałość jako „na końcu”. Uważam, że „pułapki synchronizacji DB, możliwe wąskie gardła skalowalności itp.” stanowią problem właśnie dlatego, że znajdują się w środku rzeczy, a nie na końcu.

— Dan Burton

Zgadzam się, że upór zdarza się częściej niż na końcu

@Stas W jaki sposób pytanie dotyczy (1) Scali i Clojure, (2) najlepszych praktyk? To, co przeczytałem, to (1) niezależne od języka i (2) związane tylko z współbieżnością (w szczególności Trwałością / Wytrzymałością).

— sakisk

5

Modele aktora / STM i trwałość bazy danych są nieco ortogonalne - możesz łatwo mieć jeden bez drugiego, i myślę, że istnieje niebezpieczeństwo pomylenia tych dwóch.

Osiągnięcie trwałości (D w ACID) jest niezwykle złożone w otoczeniu transakcyjnym, a zwłaszcza w środowisku rozproszonym, w którym aktorzy / procesy są koordynowani przez przekazywanie wiadomości. Wpadasz na drażliwe problemy, takie jak problem generałów bizantyjskich .

W rezultacie myślę, że zawsze będzie pewien stopień dostosowania rozwiązania, aby spełnić określone wymagania dotyczące trwałości. Nie ma rozwiązań „jednego rozmiaru dla wszystkich”.

Warto zobaczyć (perspektywa Clojure):

— mikera
źródło

5

Model aktora działa całkiem dobrze z segregacją odpowiedzialności za polecenia / zapytania (CQRS) , ponieważ komunikaty dla aktorów wykonujących manipulację danymi mogą być używane jako odpowiedniki „polecenia”.

Co to ma wspólnego z twoim problemem uporczywości? Cóż, pracujesz na pamięci i zapisujesz wszystkie polecenia w dzienniku, co jest tańszą operacją, ponieważ jest to tylko append, i od czasu do czasu zrzuć migawki, aby w razie potrzeby skrócić czas potrzebny na ponowne załadowanie bazy danych (a także umożliwić odzyskać miejsce używane przez dziennik).

To dość powszechna technika. Poszukaj inspiracji w VoltDB i Redis.

— Daniel C. Sobral
źródło

4

Rich Hickey ma zupełnie nowe dziecko o nazwie Datomic. To nowe podejście do trwałości, oddzielania pamięci, zarządzania transakcjami i zapytań. Opiera się na niezmiennych zapisach i używa języka zapytań o nazwie Datalog (udostępnia funkcje Prologowi). Głównym celem było umożliwienie łatwej dystrybucji i wdrażania w chmurze. Opiera się na pamięci masowej jako usłudze (a więc nie jednej konkretnej implementacji, ale luźno sprzężonej za pośrednictwem interfejsu API over-the-wire).

W Clojure mamy STM, który daje nam ACI, brak D. Datomic dodaje D.

— Marko Topolnik
źródło