Ткань Azure Service Fabric, по-видимому, ориентирована на сценарии, в которых все данные могут вписываться в ОЗУ, а постоянство используется в качестве хранилища резервных копий. Надежные службы предназначены для хранения информации в "Надежных коллекциях", в которой используется система регистрации log-checkpoint , где записываемая информация записывается в ОЗУ. Между тем, для Надежных Акторов поставщик состояния актора по умолчанию является" распределенным хранилищем ключевого значения, предоставляемым платформой Service Fabric ". Это, по-видимому, указывает на то, что будут применяться те же ограничения.
Однако могут быть ситуации, в которых вы хотели бы использовать Сервисную Ткань для "горячих данных", но пишите "холодные данные" в какую-то постоянную память. Каковы наилучшие методы обработки этого перехода?
В Орлеане это, похоже, обрабатывается автоматически, используя хранилище сохранения, такое как таблицы Azure. Но, по-видимому, основная цель дизайна Сервисной ткани и надежных коллекций заключается в том, чтобы избежать необходимости использования внешних сервисов, тем самым улучшая местоположение данных. Текущая документация предполагает возможность переместить данные в какой-либо постоянный магазин для аварийного восстановления и аналитики, но не обсуждает возможность перемещения данных вперед и назад между поддерживаемыми постоянством актерами в памяти и более постоянными формами хранения.
Возможный ответ заключается в том, что Service Fabric уже делает это. Возможно, надежный словарь имеет встроенный механизм переключения между хранящимся в памяти хранилищем и постоянным хранилищем.
Или, может быть, ответ заключается в том, что нужно управлять этим. Один из подходов может заключаться в том, чтобы актер следил за тем, как он "горячий", и, при необходимости, переключая его хранилище персистентности. Но это жертвует одним из преимуществ модели Actor, автоматического распределения и освобождения актеров. Аналогичным образом мы можем периодически удалять элементы из надежного словаря и добавлять его в какой-либо другой хранилище сохранения, а затем добавлять их обратно. Опять же, это требует знания того, когда имеет смысл сделать переход.
Несколько примеров могут помочь в кристаллизации этого:
(1) Предположим, что мы реализуем многопользовательскую игру со множеством разных "комнат". Нам не нужны все комнаты в памяти сразу, но мы должны перенести их в память и использовать локальное сохранение в качестве резервной копии, когда игроки присоединятся к ним.
(2) Предположим, что мы реализуем только B-Tree с добавлением только как часть базы данных. Искушение состояло бы в том, чтобы каждый B-Tree node был субъектом с точки зрения состояния. Мы хотим, чтобы горячие b-деревья оставались в памяти, но, конечно, весь индекс не может быть в памяти. Похоже, что это основной сценарий, который уже реализован для таких вещей, как DocumentDB, но мне не ясно, из документации, как это можно сделать.
Связанный вопрос, который я нашел, здесь. Но этот вопрос фокусируется на том, когда использовать Azure Service Fabric и внешние сервисы. Мой вопрос заключается в том, есть ли необходимость перехода между ними, или у Azure Service Fabric уже есть все возможности, необходимые здесь.