CLUSTER DESIGN CONSIDERATIONS

memory. When there is not enough memory left, some data is ejected from memory and will only exist on disk. Accessing data from disk is much slower than accessing data in memory. As a result, if ejected data is accessed frequently, cluster performance suffers. Use the formula provided in the next section to verify your configuration, optimize performance, and avoid this situation.

• Number of Nodes: Once you know how much memory you need, you must decide whether to have a few large nodes or many small nodes.
o Many small nodes: You are distributing I/O across several machines. However, you also have a higher chance of node failure (across the whole cluster).
o Few large nodes: Should a node fail, it greatly impacts the application.
o It is a trade off between reliability and efficiency.

• Couchbase prefers a client-side moxi (or a smart client) over a server-side moxi. However, for development environments or for faster, easier deployments, you can use server-side moxis. A server-side moxi is not recommended because of the following drawback: if a server receives a client request and doesn’t have the requested data, there’s an additional hop. See client development and Deployment Strategies for more information.

• Number of cores: Couchbase is relatively more memory or I/O bound than is CPU bound. However, Couchbase is more efficient on machines that have at least two cores.

• Storage type: You may choose either SSDs (solid state drives) or spinning disks to store data. SSDs are faster than rotating media but, currently, are more expensive. Couchbase needs less memory if a cluster uses SSDs as their I/O queue buffer is smaller.

• WAN Deployments: Couchbase is not intended to be used in WAN configurations. Couchbase requires that the latency should be very low between server nodes and between servers nodes and Couchbase clients.