This content has been marked as final. Show 3 replies
I assume you have gone through the sizing exercize in the Admin Guide and worked with the spreadsheet.
Whatever number of Rep Groups you end up having, NoSQL Database will evenly distribute the records across all of them. I'm not sure if your comment about many of the nodes going underutilized was in reference to that or not. Assuming a uniform workload across the keyspace, it will be a uniform workload across the Rep Groups.
All writes will go to the master Rep Node in the relevant Rep Group. Presently we do not have much support for 'maste affinity' but we may in a fututre release.
Depending on the Consistency parameter passed to the api call, a read may or may not go to a replica. It sounds like you are doing RMW, so it may be perfectly reasonable to use a Consistency policy which allows reading from a replica. The subsequent write would go to the master in any case.
I hope this is useful.
Almost useful :)
One clarification: With replication factor of 3, I have one node serving writes and two serving reads on each group. With all the writes going to the master, I have 50% of the workload going to 30% of the servers, and the other 50% of the workload going to 60% of the servers. That's the lack of balance I'm worried about.
The sizing exercise addresses disk space, and was helpful in that regard. It did not address throughput (or I missed something significant). In theory, I'd love to place one master on each storage node, to maximize the number of servers that serve writes.
You can have multiple Rep Nodes per Storage Node, but you have to be careful of resource contention (I.e. you should have each Rep Node on a separate spindle and you need to be careful that the Rep Nodes are from different Rep Groups). Also, we don't give you very good control of master affinity so it would be possible for multiple masters to end up on the same Storage Node. Better support for this may be available in the fututre.