This question is mostly theoretical and i want to see if i’ve understood couchbase architecture currently.
Say i have a social website and a single post becomes very viral (X10000 activity compare to average post).
I can add nodes until its a single document per node/1024 nodes.
But if i will need more throughput for that document i have nothing to do (on the couchbase level)
I’m not sure if I understood your question 100%, but I think I know what you’re asking for:
Every document has one active location and up to 3 replica locations. You always read from the active node, from the replicas ONLY in failure cases. This also means that one document only is put on one server only and it won’t be copied to the other nodes (other than for replica purposes).
Nevertheless, I’d argue that Couchbase Server has enough power to even satisfy this use case, because a read operation is very cheap. If this post is very large (1MB or more, which doesn’t seem to be the case here) you might consider splitting it up into multiple docs and fetch them in parallel.
So my advice is: just don’t bother with those one for now, I’d say its premature optimization. Couchbase Server has strong roots in caching and is able to handle up to millions of ops/s.
Thank to for the informative response,
I’ve just read about bidirectional XDCR that if i understand correctly can give you somekind of more then one active node if its really needed. i’m not there yet but i want to understand the limits of the tools i’m going to use before i design the architecture.
I don’t think XDCR fits your purpose here. Architecturally, it can be used for many things like:
Uni or bidirectional eventual consistent data between datacenters
But it’s not intended to do read scaling if you want to have one document copied to more masters if you know what I mean, other than if you want to localize your data closer to your users (IE a data center in New York and one in Tokyo)