Рекомендации по функциональному программированию Scala или Clojure

11

Я много занимался кодированием для самостоятельной работы, получил опыт работы с моделями параллельного программирования: актерами, программной транзакционной памятью, потоком данных.

Когда я пытаюсь применить эти архитектуры в реальной жизни - в веб-приложении с высокой нагрузкой - ни одна модель не поддерживает долговечность и постоянство данных. Реальные задачи требуют сохранения данных в конце. Это означает, что я все еще должен использовать DB и перехватывать синхронизацию DB, возможные узкие места масштабируемости и т. Д.

Кто-нибудь знает хороший пример архитектуры (src, текст, схема или чертежи), в которой используется Akka Actors или Software Transaction Memory и реализуется постоянство в конце?

Любой хороший пример / идея для транзакционной памяти, актеров, потока данных, пространств кортежей в реальных приложениях приветствуется.

scala clojure functional-programming

— комар
источник

Тебе нужны и акка и стм?

— om-nom-nom

Кажется необычным то, что вы считаете настойчивость «в конце». Я считаю, что «перехватывать синхронизацию БД, возможные узкие места масштабируемости и т. Д.» являются проблемой именно потому, что они находятся в середине вещей, а не в конце.

— Дэн Бертон,

Согласитесь, что настойчивость случается чаще, чем в конце

@Stas Как вопрос связан с (1) Scala и Clojure, (2) лучшими практиками? То, что я прочитал, (1) не зависит от языка и (2) связано только с параллелизмом (в частности, долговечность / постоянство).

— Сакиск

5

Модели Actor / STM и постоянство базы данных несколько ортогональны - вы легко можете получить одно без другого, и я думаю, что есть опасность смешать два.

Достижение долговечности (D в ACID) чрезвычайно сложно в транзакционной среде, особенно в распределенной среде, в которой участники / процессы координируются передачей сообщений. Вы попадаете в острые проблемы, такие как проблема византийских генералов .

В результате я думаю, что всегда будет определенная степень адаптации решения для удовлетворения ваших конкретных требований к постоянству. Не существует единого решения для всех.

Стоит посмотреть (в перспективе Clojure):

— mikera
источник

5

Модель актора прекрасно работает с сегрегацией ответственности «команда / запрос» (CQRS) , поскольку сообщения субъектам, которые выполняют манипуляции с данными, могут использоваться как «командные» эквиваленты.

Итак, какое это имеет отношение к вашей проблеме с постоянством? Что ж, вы работаете с памятью и записываете все команды в журнал, что является более дешевой операцией, поскольку она предназначена только для добавления, и время от времени создаете дамп-снимки, чтобы сократить время, необходимое для перезагрузки базы данных, если это необходимо (плюс возможность восстановить пространство, используемое журналом).

Это довольно распространенная техника. Посмотрите на VoltDB и Redis для дальнейшего вдохновения.

— Даниэль С. Собрал
источник

4

У Rich Hickey появилось новое детище под названием Datomic. Это новый подход к постоянству, отделению хранилища, управлению транзакциями и запросам. Он основан на неизменяемых записях и использует язык запросов, который называется Datalog (имеет общие функции с Prolog). Основная цель состояла в том, чтобы обеспечить простое распространение и развертывание в облаке. Он опирается на хранилище как сервис (то есть не на конкретную реализацию, а на слабую связь через проводной API).

В Clojure у нас есть STM, который дает нам ACI, D отсутствует. Datomic добавляет D.

— Марко Топольник
источник