Note: This project was merged to Orleans main codebase. Starting on Orleans v7.2.0, all the providers are published to NuGet along with the core Orleans packages. New issues and contributions should be directed to https://github.com/dotnet/orleans.
Orleans is a framework that provides a straight-forward approach to building distributed high-scale computing applications, without the need to learn and apply complex concurrency or other scaling patterns.
Azure CosmosDB is Microsoft's globally distributed, multi-model database. It is a database for extremely low latency and massively scalable applications anywhere in the world, with native support for NoSQL.
Orleans.CosmosDB is a package that use Azure CosmosDB as a backend for Orleans providers like Cluster Membership, Grain State storage, Streaming and Reminders.
Installation is performed via NuGet
From Package Manager:
PS> Install-Package Orleans.Clustering.CosmosDB
PS> Install-Package Orleans.Persistence.CosmosDB
PS> Install-Package Orleans.Reminders.CosmosDB
PS> Install-Package Orleans.Streaming.CosmosDB
.Net CLI:
# dotnet add package Orleans.Clustering.CosmosDB
# dotnet add package Orleans.Persistence.CosmosDB
# dotnet add package Orleans.Reminders.CosmosDB
# dotnet add package Orleans.Streaming.CosmosDB
Paket:
# paket add Orleans.Clustering.CosmosDB
# paket add Orleans.Persistence.CosmosDB
# paket add Orleans.Reminders.CosmosDB
# paket add Orleans.Streaming.CosmosDB
It is not mandatory to use all the providers at once. Just pick the one you are interested in from the samples and you should be good as they don't depend on each other.
Example
var silo = new SiloHostBuilder()
.UseCosmosDBMembership(opt =>
{
// Use CosmosDB as the cluster membership table.
// Configure CosmosDB settings in opt.
})
.AddCosmosDBGrainStorageAsDefault(opt =>
{
// Configure CosmosDB persistence provider.
// Configure CosmosDB settings in opt.
})
.UseCosmosDBReminderService(op =>
{
// Configure CosmosDB reminders provider.
// Configure CosmosDB settings in opt.
})
.Build();
await silo.StartAsync();
Example
var clientConfig = new ClientConfiguration();
var client = new ClientBuilder()
.UseCosmosDBGatewayListProvider(opt =>
{
// Use CosmosDB as the Gateway list provider.
// Configure CosmosDB settings in opt.
})
.Build();
await client.Connect();
Great! Now you have Orleans configured to use Azure CosmosDB as the back storage for its providers!
By default the grain type is used as partition key, however this limits the storage size for a single grain type as a single logical partition has an upper limit of 10 GB storage.
It is possible to override the default by implementing a custom IPartitionKeyProvider
. The custom implementation of IPartitionKeyProvider
can be registered by using the dependency injection usual methods like:
services.AddSingleton<IPartitionKeyProvider, MyCustomPKProvider>();
There is also some overloads of AddCosmosDBGrainStorage
and AddCosmosDBGrainStorageAsDefault
that allow you to pass the IPartitionKeyProvider
implementation.
If no IPartitionKeyProvider
is used, the default one will be uses which use full name of the grain type will be used as partition key.
Example
public class PrimaryKeyPartitionKeyProvider : IPartitionKeyProvider
{
public ValueTask<string> GetPartitionKey(string grainType, GrainReference grainReference)
{
return new ValueTask<string>(grainReference.GetPrimaryKey().ToString());
}
}
The example above use the Primary key as partition key.
In order to prevent cross partition queries the partition key must be available to the client upon reading data, hence the delegate input is limited to the graintype and grainreference. The grain reference contains the grain id, with combination, and a type identifier.
For further details on partitioning in CosmosDB see https://docs.microsoft.com/en-us/azure/cosmos-db/partitioning-overview.
The change will not affect existing systems. Configuring a custom IPartitionKeyProvider
for an existing system will throw a BadGrainStorageConfigException stating incompatibility. To start using a custom partition key provider the old documents must be updated with a /PartitionKey
property where the value is set using the same functionality as in the GetPartitionKey
implementation in the custom IPartitionKeyProvider
. Once all documents are updated, the data must be migrated to a new CosmosDB collection using Azure Data Factory, CosmosDB Migration tool or custom code with colletions PartitionKey set to PartitionKey
With the 3.0.0 release, two breaking changes requires manual changes if you have pre-existent data:
Reminders, Streaming and Persistence providers doesn't rely on Stored Procedures anymore. You can safely remove them from your databases once you migrate to 3.0.0. The only stored procedures that are still used, are the ones from the Clustering packages since Orleans membership protocol requires some atomic operations that are only possible on CosmosDB by using stored procedures. All the rest can be killed.
Before 3.0.0, the reminders provider used to use a non-partitioned collection. Recently Microsoft requires that everyone using CosmosDB to migrate to partitioned collections. If you have data on your old collection, you need to migrate this data to a new one.
The new structure is defined as follow:
id
field:$"{grainRef.ToKeyString()}-{reminderName}"
PartitionKey
field:$"{serviceId}_{grainRef.GetUniformHashCode():X8}"
- Other fields remain the same.
This data migration can be performed whatever the way you prefer, as long as the id
and PartitionKey
fields are formated the way described here. The partition key path of the new collection must be /PartitionKey
.
The current indexing fork relies on CosmosDB stored procedures for lookup. As stored procedures must be executed against a specific partition, the use of custom partition key builders is not compatible with the Orleans indexing fork.
To use the Stream Provider you need to register it on your ISiloBuilder
:
.AddCosmosDBStreaming(config =>
config.AddStream("<provider name>", configure =>
{
// The information on FeedCollectionInfo property is related to the database that will be monitored by the change feed
configure.FeedCollectionInfo = new DocumentCollectionInfo
{
Uri = new Uri("<CosmosDB URI>"),
MasterKey = "<CosmosDB Master Key>" ,
DatabaseName = "<CosmosDB Database>",
CollectionName = "<CosmosDB Collection>"
};
// The information on LeaseCollectionInfo is related to the CosmosDB Change Feed lease collection
configure.LeaseCollectionInfo = new DocumentCollectionInfo
{
Uri = new Uri("<CosmosDB Change Feed Lease URI>"),
MasterKey = "<CosmosDB Change Feed Lease Master Key>" ,
DatabaseName = "<CosmosDB Change Feed Lease Database>",
CollectionName = "<CosmosDB Change Feed Lease Collection>"
};
}, typeof(PartitionKeyBasedStreamMapper)))
Then on your grain, you need to implement IAsyncObserver<Document>
in order to receive the document that has changed and published thru Cosmos DB Change Feed.
PRs and feedback are very welcome!