Correctness problem and suggestions

[jessebenson]

Correctness problem and suggestions

[jessebenson]

Yes - persistent indexing reduces the throughput and increases latency per operation, and Service Fabric doesn't deal well with large transactions. The implementation is greatly simplified and the error cases are handled by the built-in transaction support.

I was going to implement the in-memory indexes (see the empty https://github.com/jessebenson/service-fabric-indexing/tree/master/src/ServiceFabric.Extensions.Data.Indexing.Memory), but I never got around to it. The implementation using notifications is significantly more complex and error-prone, and recovery becomes an expensive operation.

[jessebenson]

@chandramouleswaran - thanks for your interest! The "index" is itself a separate reliable collection that is updated as part of the same transaction. Therefore, if an exception occurs or if tx.CommitAsync is not called, the entire transaction will get rolled back (including changes to the index).

For example, let's look at the implementation of SetAsync(). It first updates the original dictionary using the provided transaction:
https://github.com/jessebenson/service-fabric-indexing/blob/master/src/ServiceFabric.Extensions.Data.Indexing/ReliableIndexedDictionary.cs#L216

Then we update the other reliable collections (i.e. the indexes) as part of the same transaction:
https://github.com/jessebenson/service-fabric-indexing/blob/master/src/ServiceFabric.Extensions.Data.Indexing/ReliableIndexedDictionary.cs#L426

[chandramouleswaran]

Thanks for the quick reply. My mistake - I assumed this was kept in memory 😃
If the index is persisted then there is no correctness problem - but there could be a performance problem. If we commit a small set of data but index is big - then we will run into commit failures or timing out as other posts are pointing out.

In our team, we are looking for an indexing solution where we do not have to persist more data than needed. We have a working model with notifications for basic cases but we want to explore OSS first before building something new.