Комментарии 7
Горячий кеш, который падает 300 раз в секунду. Теперь я видел всё!
Шутка...
Шутка-то шутка, но я своими глазами видел, как соседи выставили процессу параметры перезапуска в :infinity и у них что-то стало немного притормаживать.
Процесс запускался, пытался вычитать откуда-то данные, это откуда-то было криво настроено и оно падало, и перезапускалось. Так вот число 300/сек взялось именно оттуда, и если бы не задержка чтения из этого самого откуда-то — было бы несколько десятков тысяч.
Спасибо за контент по Эрлангу и Эликсиру!
Я потихоньку начинаю изучать акторную модель. В данный момент не могу понять следующее:
Цитата: Хранить таким образом сумму на банковском счете клиента не сто́ит. А как сто́ит? Либо я бы сделал актора "Аккаунт" и на каждую мутацию делал бы запись в event log / DB. Overhead минимум, потому что только пишем, агрегат собирать не надо как в stateless модели. А как бы сделали вы исходя из вашего опыта?
Еще вопрос по работе с памятью. Предположим эрланг умеет в миллионы процессов. Предположим, что мы разрабатываем что-то типа GitHub. Репозитории за счет картинок, документов и тд могут занимать мегабайты. Получается, это терабайты оперативной памяти на миллион репозиториев. И В GitHub 420 миллионов репозиториев. Понятное дело, что из них активных на запись/чтение только часть (допустим, 10%). Это еще не говоря о других метаданных вроде пользователей, issues, pull requests и тд. Это огромный ресурс. Насколько адекватно модель обрабатывает подобные случаи? Понятно, что хранение в памяти повышает производительность как чтения, как и мутации, но разумно ли держать в памяти так много данных?
С точки зрения гибкости: как работать с мультиязычностью? Например у меня есть Актор, который должен выполнить "ИИ" анализ некоторых данных и держать контекст открытым, пока не придет явный сигнал на закрытие контекста. У меня есть модуль на Python, который умеет это делать - как мне встроить его в Акторную модель Эрланга?
С точки зрения применимости, возникает ощущение, что Акторная модель показывает себя блестяще там, где необходимо обрабатывать данные часто и быстро: например трейдинг, игровые сессии и тд. Т.е. там, где лучшее решение это держать в памяти объекты, что обеспечит возможность поддерживать быстрые мутации. Преимущество Акторной модели по сравнению с тем, чтобы просто насоздавать объектов и положить их в хэшмэп, это: отдельный процессинг луп под Актора, который позволяет Акторам работать конкуретно и минимально влиять друг на друга с точки зрения блокировок, при этом обеспечивая строгий поток выполнения в рамках одного Актора. При этом в Акторах вообще нет смысла в каких-то аналитических задачах, построении отчетов и работе с достаточно статической информацией (типа информация об объектах на Яндекс.Карты).
Добро пожаловать в клуб!
Цитата: Хранить таким образом сумму на банковском счете клиента не сто́ит. А как сто́ит? Либо я бы сделал актора "Аккаунт" и на каждую мутацию делал бы запись в event log / DB. Overhead минимум, потому что только пишем, агрегат собирать не надо как в stateless модели. А как бы сделали вы исходя из вашего опыта?
Так бы и сделал. И я ровно так делаю вот тут. Акторная модель вообще не отменяет базу, а дополняет её. Можно рассматривать акторы — как горячий кэш объектов.
Еще вопрос по работе с памятью. Предположим эрланг умеет в миллионы процессов. Предположим, что мы разрабатываем что-то типа GitHub. Репозитории за счет картинок, документов и тд могут занимать мегабайты.
Картинки не нужно держать в памяти процесса же, пусть себе лежит на диске. Еще можно (если осторожно) процессы подвергать гибернации (вот тут про :hibernate). Есть такое почти общее правило: в стейте процесса не должно быть больше нескольких килобайт. Остальное — ну пусть себе лежит в хранилищах. Основное преимущество акторной модели — не умение быть горячим кэшем, а умение из коробки корректно обрабатывать высокую конкурентность.
Понятно, что хранение в памяти повышает производительность как чтения, как и мутации, но разумно ли держать в памяти так много данных?
Неразумно, и не нужно. Это не молоток, а всё вокруг — не гвозди.
С точки зрения гибкости: как работать с мультиязычностью? Например у меня есть Актор, который должен выполнить "ИИ" анализ некоторых данных и держать контекст открытым, пока не придет явный сигнал на закрытие контекста. У меня есть модуль на Python, который умеет это делать — как мне встроить его в Акторную модель Эрланга?
Обычно это делают через Port. Еще можно почитать про работу Шона Мориарти и перевести питон на эликсир :)
С точки зрения применимости, возникает ощущение, что Акторная модель показывает себя блестяще там, где необходимо обрабатывать данные часто и быстро: например трейдинг, игровые сессии и тд. Т.е. там, где лучшее решение это держать в памяти объекты, что обеспечит возможность поддерживать быстрые мутации. Преимущество Акторной модели по сравнению с тем, чтобы просто насоздавать объектов и положить их в хэшмэп, это: отдельный процессинг луп под Актора, который позволяет Акторам работать конкуретно и минимально влиять друг на друга с точки зрения блокировок, при этом обеспечивая строгий поток выполнения в рамках одного Актора.
Это так.
При этом в Акторах вообще нет смысла в каких-то аналитических задачах, построении отчетов и работе с достаточно статической информацией (типа информация об объектах на Яндекс.Карты).
А вот это не так. Линейные алгоритмы не нуждаются в акторной модели, это правда; но их обвязки — нуждаются, и еще как. За счет правильного параллелизма у вас из коробки есть инструмент, который позволяет работать со статической информацией (не обязательно тонны оной держать в стейте, как я выше уже говорил) — из разных потоков. Вот есть библиотека Flow, например. Подсуньте её примитивы вместо Stream в чтение гигантского CSV-файла — и вы получите ускорение почти в N раз (где N — число процессоров) вообще без единой строки дополнительного кода (и гарантированно без гонок).
Долгоживущий процесс и восстановление стейта после падений