Service-fabric: Feature Request: Please consider providing lowlevel KV operations without serialization.

[mkosieradzki]

It would be really nice to be able to use Get, Put, Delete operating on binary keys. Most preferable solution would be to be able to use upcoming Span<T> or ReadOnlySpan<T> such operation can operate on unmanaged memory in a safe way without any unnecessary heap allocations.

[MedAnd]

Hi @mani-ramaswamy, could the low level shims you are developing for SF state store handle the above?

[mkosieradzki]

@MedAnd did you mean SF volume driver?

[MedAnd]

one level lower @mkosieradzki... in a talk @mani-ramaswamy said his team is working on exposing SF state store directly, for even better perf (I think the volume driver uses the SF state store under the covers).

[mkosieradzki]

@MedAnd Thanks for clarification, would you mind sharing appropriate Ignite (?) talk? What I have learned from public talks today is:

1. Currently reliable collections uses: ESENT on Windows, RocksDB on Linux + managed layer on top of it.
2. There is an effort taken by Mani and his team to rewrite native persistence layer (ESENT, RocksDB) + managed layer to a native Reliable State Provider (250 000 lines of C++).
3. They are planning to expose multiple programming primitives on top of their new native Reliable State Provider. I believe that SF volume driver can be considered as such primitive.

Intention of my request is to show the demand for exposing the primitives a layer below current Reliable Collections (without serialization).

The specific benefit I would like to achieve is to remove need for implicit type marshalling between native and managed worlds, which introduces significant overhead in areas of unnecessary managed memory allocations.

This might be a bit challenging due to the way of handling range-queries. (weak ordering, key-prefixes, etc.).

If you have a talk presenting intent to expose the native API directly it would be a really good news for me.

[MedAnd]

hopefully @mani-ramaswamy will be able to clarify but this is his talk: Orchestrating one million containers with Azure Service Fabric

[mkosieradzki]

Thanks a lot. That's a really bad title for an awesome talk (that's why I just ignored it). I wish it was called "Data-aware orchestration with Azure Service Fabric" - it actually explains A LOT.

[mani-ramaswamy]

Million containers ain't awesome enough, eh? :) But yes, it had two parts and the latter focused on the data-aware part. To answer Marcin's question, I don't think we'll expose anything below RelColl (the volume driver and the interfaces across other languages will build on this).

[mkosieradzki]

Thanks Mani,

Of course it is an awesome achievement, but let's say that the data-aware part is a "bit" ;) more applicable at our scale :).

I love the idea of shims for most popular databases. SF will eventually become a Multi-model, synchronously replicated, in-proc, autonomous database - the holy grail of databases.

I suppose that the native API version of RelColl would be definitely good enough. If it's enough for volume driver - it must be enough for other consumers :).

[yizhang82]

It would be really nice to be able to use Get, Put, Delete operating on binary keys.

You would get this today with byte[]. We use BinaryWriter that writes byte[] directly. This goes for any primitive types and arrays of primitive types.

Most preferable solution would be to be able to use upcoming Span or ReadOnlySpan such operation can operate on unmanaged memory in a safe way without any unnecessary heap allocations.

I agree this might be helpful in a advanced scenario. This is something we can evaluate in future releases. But I think the native API version of ReliableCollection (that Volume Driver uses) might be more attractive to you :)

[mkosieradzki]

@yizhang82 Thanks a lot for your response

Native API version of ReliableCollection is definitely on my radar :). Could you point me out on .h files so I can try invoking those APIs? Unfortunately System.Fabric.dll is still closed source what makes it difficult to find examples of using the native API's.

I was also considering to try to create some proposal of replacing BinaryReader/BinaryWriter with PipeReader/PipeWriter, but unless System.Fabric.dll is open source it is impossible…

I think that your suggestion might be also a good solution to microsoft/service-fabric-issues#100 - so if you could give me some pointers how/where to start (or even: "just wait until 6.x") - I would really appreciate that.