Операция Актера и Базы Данных AKKA

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

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

Поэтому у меня есть следующие вопросы:

1 - Поддерживает ли база данных время открытия соединения все время?

2 - Как это работает вместе с пулом соединений, как предлагалось многими базами данных?

3. Соединяем ли мы оба, и DatabaseActors запрашивают новое соединение из пула каждый раз, когда они запрашиваются. Если нет, разве это не означает, что соединение открыто в любое время плохое?

4 - Может кто-нибудь объяснить мне тонкую вещь, которая делает его подход, который избегает голодания. Например, с помощью Play или спрей обработка запроса является асинхронной задачей, однако, если для этой задачи нужен доступ к базе данных, и мы отправляем запрос в DatabaseActor, делает ли блок в базе данных Actor (если это происходит) не вызывать, блок в асинхронной задаче, ведущий к возможному голоданию потока?

5 - На 100% уверен, что свойство БД ACID обеспечивает безопасность множественного чтения и записи и, следовательно, происходит до отношения.

6 - Я использую семантическую базу данных, также называемую тройным хранилищем, и использую семантические рассуждения во время моего запроса. Я также выполняю большой доступ на запись, любые рекомендации относительно настройки параметров объединения и номеров актеров или выделенного контекста выполнения?

Бест,

M

Ответ 1

1 - Поддерживает ли база данных время открытия соединения все время?

Актеры Akka имеют статус stateful, т.е. вы можете безопасно сохранять состояние (в данном случае соединение DB) внутри актера. Вы можете либо написать свою собственную логику управления подключением, либо использовать ту, которая предоставляется вашим драйвером базы данных.

2 - Как это работает вместе с пулом соединений, предлагаемым многими базами данных?

3. Соединяем ли мы оба, и DatabaseActors запрашивают новое соединение из пула каждый раз, когда они запрашиваются. Если нет, разве это не означает, что соединение открыто в любое время плохое?

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

4 - Может кто-нибудь объяснить мне тонкую вещь, которая делает его подход, который избегает голодания. Например, с помощью Play или спрей обработка запроса является асинхронной задачей, однако, если для этой задачи нужен доступ к базе данных, и мы отправляем запрос в DatabaseActor, делает ли блок в базе данных Actor (если это происходит) не вызывать, блок в асинхронной задаче, ведущий к возможному голоданию потока?

Если ваш драйвер базы данных блокируется, вам также придется блокировать. Рекомендуемая практика заключается в том, чтобы выполнить эту блокирующую часть кода в отдельном контексте/пуле потоков. Или, если у вас есть опция, выберите хранилище данных, в котором есть реактивный драйвер базы данных (например, ReactiveMongo для MongoDB), который полностью асинхронный и неблокирующий.

5 - На 100% уверен, что свойство БД ACID обеспечивает безопасность множественного чтения и записи и, следовательно, происходит до отношения.

Я не понимаю, что вы подразумеваете под этим.

6 - Я использую семантическую базу данных, также называемую тройным хранилищем, и использую семантические рассуждения во время моего запроса. Я также выполняю большой доступ на запись, любые рекомендации относительно настройки параметров объединения и номеров актеров или выделенного контекста выполнения?

Вы должны определенно использовать другой контекст выполнения. Поворот параметров действительно зависит от конфигурации вашего оборудования и других особенностей вашего программного обеспечения (тип базы данных, удаленный db vs embedded db, request/second и т.д.).

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

Ответ 2

В этом сообщении в блоге есть некоторые действительно хорошие моменты, почему бы не использовать соединение Actor per DB.

В частности, это означает, что вам нужно управлять уровнем concurrency вместо того, чтобы позволить собственному пулу подключений обрабатывать его для вас. Это также может ввести вас в заблуждение, чтобы ваш код работал параллельно, в то время как ваш код запускается серийно.