Below are a number of deployment strategies that you may want to employ when using Membase Server.
Using Membase Embedded Proxy
The first deployment option is to communicate with the embedded proxy in Membase over port 11211. It allows one to install Membase and begin using it with an existing application, via an on-the-client (OTC) memcached client library, without installing additional software. The downside to this approach is that there are two network hops, so while the performance is still very good, it's not as good as it could be with other deployment options. As shown in detail below, in a worst case scenario, server mapping will happen twice (e.g. using ketama hashing to a server list on the OTC client, then using vbucket hashing and server mapping on the proxy) with an additional round trip network hop introduced.
Assume there is an existing application, with an OTC memcached client, with a server list of 3 servers (Servers A, B and C). Membase is installed in place of the memcached server software on each of these 3 servers. As shown in the figure above, when the application wants to Get(KEY), it will call a function in the OTC client library. Client library will hash(KEY) and be directed, based on the server list and hashing function to Server C.
The Get operation is sent to Server C, port 11211. When it arrives to membase (now a proxy port), the Key is hashed again to determine its vBucket and Server mapping. This time, the result is Server A. The proxy will contact Server A on port 11210, perform the get operation and return the result to the client.
Standalone Proxy
The second option is to deploy a standalone proxy, which performs substantially the same way as the embedded proxy, but potentially eliminating a network hop. A standalone proxy deployed on a client may also be able to provide valuable services, such as connection pooling. The diagram below shows the flow with a standalone proxy installed on the application server.
The memcached OTC client is configured to have
just one server in its server list (localhost), so all operations
are forwarded to localhost:11211 — a port
serviced by the proxy. The proxy hashes the key to a vbucket, looks
up the host server in the vBucket table, and then sends the
operation to the appropriate membase server on port 11210.
Using s vBucket aware Client
In the final case, no proxy is installed anywhere in the data flow. The client has been updated and performs server selection directly via the vBucket mechanism. In addition, these clients could send additional information using a modified on-the-wire membase protocol, for example to explicitly encode the destination vBucket. This data could be used to optimize system performance.
