The main implementation of the high-throughput API is
This is based on
Which is implemented by:
The underlying implementation, and the part which would need to be reworked first, is in the following package:
This package is relatively general and the unit tests do not presume key-range sharding, so it is possible to establish a different partitioning scheme for the data. For the purposes of this issue, the desired partitioning scheme should be the data service UUID for the target data service. Thus, all writes which are mapped onto the same data service would be buffered by the same buffer.
The next step would be to refactor the AsynchronousStatementBufferFactory to use the per-data-service buffering.
Since the data service will now be receiving writes bound for multiple local shards, we also need to change how we transmit the data, accept it, and process it on the data service. Today, the data is transmitted inside of an RMI object which targets a specific shard. If the shard has been moved, split, or joined, then the client handles the error, which may includes repartitioning the data into different buffers when we handle a shard move, and then reissues the request to the appropriate data service.
This needs to be changed to decouple the data flow and the message flow , not only to improve the performance, but also to pass along the handling of the per-shard processing to the data service since it will now receive tuples bound for different local shards in the same data transfer.
The client side of the code should be modified to be a single-threaded NIO transfer of the buffered data to the target data service. The target data service should use a fixed #of local NIO buffers to retain data from the clients to bound its memory demands. A strategy will need to be developed to (a) move the data from these buffers onto the target shards in an efficient and timely manner; and (b) handle redirects if the target shards have been moved without requiring the client to reissue all writes against a data service if only one shard has been moved/split/joined and without losing writes if the leader for the data service quorum (in HA mode) fails over.