As part of #27 and #23 we get a SequentialReplication strategy, we should look to improvise it to support parallel writes on the nodes.

Some PRs have really nice commit messages and discussions (#27 being my favourite). We should start documenting the internal decisions and workings of the system in a markdown somewhere so we could generate a documentation if needed in a later point of time.

We should surface the examples much more as something like recipes which folks could just copy-paste and take it from there. Also with #12 we should write scaladocs for external facing APIs.

A quickstart guide for general users of the library would also be great. We've already made an attempt as part of #19 but we could do better.

• Basic Documentation Infra
• Add examples as recipes
• Quick Start
• Getting Started

Today we've a ConsistentHashRing which supports find, add and remove. While this is great, it would really help if we can build abstractions on top that would help us visualise it as a HashRing and token ranges between the nodes in the ring.

This would help us when we try out rebalancing of data among the nodes.

• Membership
  • Ability to register a set of nodes onto a cluster
  • Tests with members going up & down
  • Ability to query any node and check for the available members

We're still on scala 2.10.4, while scala 2.11.x is nearing it's end by end of this year. We should probably upgrade to get a lot of compiler improvements.

Today we open and close a channel for every message especially while replicating or forwarding. Looks like we can reuse the same connection and they're automatically multiplexed.

PR Comments from https://github.com/ashwanthkumar/suuchi/pull/53/files#r83402588

• gRPC <-> HTTP
• GET - input key, return back the data as "bytes"
• PUT - input key, data bytes
• HEALTH - Report health of the node
• SHARD_INFO - Should report current shards that this node manages

• Integrate Cluster into Server abstraction built as part of #13
• Support for Shard related information to be used for replication / rebalancing (#4)
• Support dynamic rebalancing of data

• Add support for getting multiple nodes from CHRing. - #23
• Replication Interceptor for doing synchronous replication as writes happen. - #23 and #27

Hi! I imported this project into intellij as sbt project and ran sbt compile. I get a lot of compiler errors across the project. Please help me with the steps to setup this repo. Thanks

Today as part of scanner and versionScanner we do a full store san and then filter for Data Keys or Version keys. This is very inefficient on very large stores and takes a long time. Instead we can always push the VERSION_KEY or DATA_KEY prefix to the underlying store there by reducing the search space of the whole scans.

When a RPC service is routed using ReplicationHandler, the service must have an ability to know if it's the replication invocation or the original invocation. We can use Context to store and retrieve that information.

This is especially useful when we're going to send a metric for that replication request, you don't want to end up doing double counts of that.

Today we don't have much ScalaDocs written as part of our code. One of the things we might have to do for wider adoption is to write sensible documentation what the method does so it's easy for the developers to consume them.

Following needs to be done to get a working cluster with membership in place.

• Build a Node abstraction
• Compose membership, partitioner & services as part of it.
• When the node is started, it should expose a listen port & should be able to handle GET / PUT requests.

References

• https://wiki.apache.org/cassandra/AntiEntropy
• http://stackoverflow.com/questions/13222713/why-is-the-word-entropy-present-in-anti-entropy-protocols
• http://distributeddatastore.blogspot.in/2013/07/cassandra-using-merkle-trees-to-detect.html
• https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/utils/MerkleTree.java

• Would we need to support async replication?
  • HintedHandoff
  • Read Repair

Use cluster versioning -- Node A was part of the cluster at version V.

Folks using Raft tend to use term as the version number (since it's unique).

Feedback from @sriram-srinivasan during https://dsconf.in/ talk.

Add ability for the cluster to

• scale out - addition of new nodes
• scale down - nodes going down.
• Anti Entropy - Refer #50 for more details

Tasks

• It's relatively easy to do data rebalancing with ConsistentHashRing, but given the generic nature of the RoutingStrategy. We need to decide on the interactions of Rebalancer with that of RoutingStrategy
• Implement / integrate membership with the Server. Once we've Membership, think about how would it integrate with Partitioner / RoutingStrategy for maintaining the list of nodes.

Dependencies

• While re-balancing we need to know what keys to migrate which needs an Anti-entropy implementation #50

Checking Github notifications.

Now that we've moved away from SnapCI, we need a way to perform auto releases from travis. With SnapCI it was easy as a single click of a stage in the pipeline. We need a different mechanism to handle this on the travis world.

We need an ability to store written timestamp of the record which we can use for auto purging old versions in an upstream system.

We should consider to write integration and/or property based tests for our components. Check out the below references for some motivation and contexts.

Ref

• https://github.com/CaitieM20/TheVerificationOfDistributedSystem
• https://www.youtube.com/watch?v=kDh5BrqiGhI&feature=youtu.be&list=PLEx5khR4g7PIfvppVcaTPa5IKWTjoASRU&utm_content=buffer4e412&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer
• https://vimeo.com/23220830

Current implementation is for Unary methods only. Need to add support for streaming aggregation as well.

Today we don't do any try .. catch anywhere in the project. gRPC seems to be throwing a lot of RuntimeException at different places. We need to track each of them and address them. This is more of an epic which will be on-going for a while.

For any PRs or commits that has discussions related to this, please tag them with this issue so it's automatically tracked.

With #27 (and #23 ) we now have a pluggable replication in place. And we've special interceptors for writes, so it should be easy to do the same for reads as well.

We can do a digest query on all the nodes for starts to give out a very consistent response.

• Membership using Atomix
• Implementation a simple HandleOrForward using consistent hashing - #2 and #11
• Build replication
• Build rebalancing (and dynamic scale out)

Today we set the key of VRecord as V_. Now this is a little useless because if we want to get back the data from versionScanner().scan. It wouldn't be possible. We need to make sure we return the actual key in the VRecord along with the list of versions for that key.

As part of #27 and #23 we get a SequentialReplication strategy, we should look to improvise it to support chained writes across the replica nodes.

Related - #30

While doing scatter we send requests to all the nodes in the cluster (incl. the node that's doing the scatter).

Publish the suuchi project to maven central.

As part of #34 we seem to have Synchronous ParallelReplication support. But the withReplication on Server still has only SequentialReplicator hard-coded. We have to make it pluggable.

Ensure that all classes have appropriate access control for us to split them later into modules.

Any operation(get or put) on the cluster, should translate to a HandleOrForward operation.
based on the key, the node should be able to localize if it can handle the request or it should be able to forward the request an appropriate node.

@ashwanthkumar below is my stab at at the contract. Thoughts?
def handleOrForward(key: K): Node

PS: Is this a good way to write down issues.

House keeping to enforce certain practices in the project.

• Implement an in-memory store that support the operations of the Store trait.

trait Store {
  def get(key: Array[Byte]) : Array[Byte]
  def put(key: Array[Byte], data: Array[Byte]) : Unit 
}

For users that have been using Store - a single store instance directly (like RocksDB) and want to migrate to ShardedStore (introduced as part of #53) because you can effectively parallelize the writes across multiple stores in parallel (on the same node).