https://github.com/reubenbond/fabrictableservice
Distributed database on Service Fabric which uses ESENT as the storage engine
https://github.com/reubenbond/fabrictableservice
Last synced: about 1 year ago
JSON representation
Distributed database on Service Fabric which uses ESENT as the storage engine
- Host: GitHub
- URL: https://github.com/reubenbond/fabrictableservice
- Owner: ReubenBond
- License: mit
- Created: 2015-12-03T23:04:59.000Z (over 10 years ago)
- Default Branch: master
- Last Pushed: 2015-12-03T23:46:14.000Z (over 10 years ago)
- Last Synced: 2025-03-19T05:24:57.606Z (over 1 year ago)
- Language: C#
- Size: 84 KB
- Stars: 17
- Watchers: 2
- Forks: 5
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
#Service Fabric Table Service
An ESENT-based database on Service Fabric. Demonstrates how to write a distributed, reliable database which uses Service Fabric for replication.
The `ReliableTable` class can take part in transactions along with Service Fabric's existing `IReliableDictionary` & `IReliableQueue` providers.
## Suggestions welcome via [Twitter: @ReubenBond](https://twitter.com/reubenbond) or GH issues :)
## Example:
In your StatefulService's `RunAsync` method, obtain a reference to a table:
```C#
var journal = await this.StateManager.GetOrAddAsync>("journal");
```
Then, access the table from one of your service's methods like so
```C#
public async Task Insert(string key, string partition, byte[] value)
{
using (var tx = this.StateManager.CreateTransaction())
{
journal.SetValue(tx, key, value);
await tx.CommitAsync();
}
}
```
## Ideas for improvement:
* Use a wholly managed database to avoid calls into native code.
* Alternatively: chunkify the marshalling via a native library.
* Use ProtoBuf for serialization of operations, instead of manual binary serialization.
* Profile & improve performance.
For a higher performance database, implement the `IStateProvider2` interface manually and replicate the database journal instead of the application-level operations (is that possible with ESENT?). This implementation uses the `TransactionalReplicator` from Service Fabric, which maintains its own transaction log, ESENT also maintains a transaction log internally, so there is a duplication of effort.
I give zero guarantees about any of this.
Credits to [ManagedEsent](https://managedesent.codeplex.com/) which this project borrows from and leverages.