Гранулярность субъектов в Azure Service Fabric по сравнению с Project Orleans

Возьмем простой пример: у меня есть служба с 1 000 000 пользователей, и у каждого пользователя есть некоторая информация о профиле. Я хочу управлять CRUD-операциями с этой информацией профиля с помощью субъектов.

Я понимаю, что в Project Orleans у меня будет одно зерно на пользователя, поэтому 1000000 виртуальных граней одного и того же типа актора (которые будут созданы только в случае использования), и каждое зерно будет управлять информацией профиля. одного пользователя, хранящегося в его состоянии. По мере роста моих пользователей растет и количество зерен.

В Service Fabric, если я правильно интерпретирую документацию, все будет работать несколько иначе. У меня был бы тип актора с отслеживанием состояния, который управлял бы операциями CRUD для всех пользователей, и для масштабируемости я бы разделил актор, дав каждому разделу ответственность за подмножество пользовательских данных. Учитывая параметры разделов, я могу ' Я не вижу очевидного способа реализовать это так же детально, как Project Orleans.

Мне очень нравится подход в Project Orleans. Актер просто обрабатывает данные для одного пользователя, и масштабируемость очевидна (чем больше пользователей, тем больше гранул). Модель памяти также проста: отдельный актер гидратируется по запросу с небольшим количеством состояний.

Похоже, реализация Service Fabric была бы немного сложнее. Каждый субъект имеет дело с набором пользователей, и для масштабируемости я должен заранее решить, сколько разделов я должен сделать, поскольку это не может быть изменено позже. Что касается модели памяти, объем данных, которыми управляет каждый субъект, растет по мере роста числа пользователей.

Итак, мой вопрос: правильно ли я понимаю, что субъекты в Service Fabric просто более грубые, чем в Project Orleans?

Обновить

Спасибо за ответы. Моя ошибка заключалась в том, что я думал, что раздел содержит один экземпляр актора, который будет содержать и управлять состоянием для всех идентификаторов акторов в разделе. Это совершенно неверно. Майкл указывает, что раздел содержит несколько экземпляров акторов, по одному на каждый идентификатор актора. Следовательно, акторы могут быть реализованы так же, как и в Project Orleans. Теперь это имеет больше смысла, спасибо.


azure-service-fabric actor orleans
person James Thurley    schedule 27.11.2015    source источник

Ответы (2)


arrow_upward
7
arrow_downward

ActorType фактически размещен в службе. Эта служба разделена. Каждый раздел будет содержать несколько экземпляров вашего ActorType (в соответствии с указанными вами диапазонами и количеством разделов).

Используя API, вы можете получить экземпляр Actor (вам не нужно явно его создавать):

var actor = ActorProxy.Create<IActorType>(new ActorId("some id"), "fabric:/application");

В Орлеане зерно разложено по бункерам, а не перегородками. Таким образом, Орлеан может переместить один экземпляр в другой бункер, если захочет. В Service Fabric все это делается на уровне секций. Таким образом, все экземпляры в разделе перемещаются вместе.

person Michiel Overeem    schedule 27.11.2015
comment
Спасибо, Мишель, это прояснило мне ситуацию. - person James Thurley; 27.11.2015

arrow_upward
2
arrow_downward

Я мало что знаю о Project Orleans, но думаю, что вы могли спутать понятия актера и типа актера в Service Fabric.

Актер - это экземпляр типа актора - отношения аналогичны отношениям между классами и объектами в объектно-ориентированных языках.

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

person charisk    schedule 27.11.2015
comment
Спасибо за ответ, я понимаю эту разницу, но на самом деле ваш ответ мне понравился. Я собираюсь провести несколько тестов и обновить свой вопрос. - person James Thurley; 27.11.2015
comment
Привет, Чариск, после нескольких тестов, а также с ответом Мишеля, я могу лучше понять, о чем говорилось в вашем последнем абзаце. Он также ответил на мой вопрос, но я пометил Мишель как ответ, так как он был для меня немного понятнее. Спасибо! - person James Thurley; 27.11.2015