A type-safe data context for AWS DynamoDB with LINQ and in-memory caching support. Allows to combine DynamoDB's durability with cache speed and read consistency
Now on Nuget!!!
PM> Install-Package Linq2DynamoDb.DataContext
PM> Install-Package Linq2DynamoDb.AspNet.DataSource
PM> Install-Package Linq2DynamoDb.DataContext.Caching.MemcacheD
PM> Install-Package Linq2DynamoDb.DataContext.Caching.Redis
AWS DynamoDB is a cool, highly-available and highly-durable NoSQL database. Yet, because of it's throughput capacity restrictions, it might get:
- unpredictably slow,
- unpredictably expensive.
AWS SDK for .Net (via it's Amazon.DynamoDB.DataModel namespace) provides a cool type-safe way to store and retrieve .Net classes from/to DynamoDB. Yet:
- it's still not very .Net-friendly and doesn't fit well with some other common data technologies on .Net platform like LINQ and data binding,
- it's objects cannot be directly cached in e.g. ElastiCache, because they're not serializable.
LINQ2DynamoDB tries to address all of those concerns.
translates LINQ queries into corresponding DynamoDB Get/Query/Scan operations (trying to choose the most effective
one) and stores query results in an in-memory cache (currently
are supported). When data is modified, it's saved both to DynamoDB and to cache. This mitigates another issue of DynamoDB: inconsistent reads (Get/Query operations
be consistent for a double price, Scan operations cannot). If Linq2DynamoDb.DataContext succeeds to load the data from cache, that data will for sure be of the latest version.
A very common scenario for using DynamoDB is storing some kind of user profiles or other user-specific data in one big table with HashKey set to some UserID. Linq2DynamoDb.DataContext gracefully supports this case by allowing you to specify a predefined HashKey
value for the entities. Then your DataContext instance represents (and correctly caches) a set of entities for a specific user (or whatever).
And now Linq2DynamoDb.DataContext
also supports OData
Currently, Linq2DynamoDb.DataContext is itself based on AWS SDK's Amazon.DynamoDBv2.DocumentModel namespace and uses Document's change-tracking mechanism. We'll try to slowly move away from it in future.
There're, of course, still many other things to do. They're now recorded as issues, so, please, vote for them (and add your own proposed tasks/features).
Bugs? Suggestions? Complaints? We'd love to hear them!
Would like to contribute? You're welcome!
Any other help? Greatly appreciated!
P.S. - And thanks a lot to
for his testing efforts! And to
for his samples!