Using
memcached
1347
• Because the determination is handled within the client, the hashing algorithm returns the same value
for a given key; values are not affected or reset by differences in the server environment.
• Selection is very fast. The hashing algorithm on the key value is quick and the resulting selection of
the server is from a simple array of available machines.
• Using client-side hashing simplifies the distribution of data over each
memcached
server. Natural
distribution of the values returned by the hashing algorithm means that keys are automatically spread
over the available servers.
Providing that the list of servers configured within the client remains the same, the same stored key
returns the same value, and therefore selects the same server.
However, if you do not use the same hashing mechanism then the same data may be recorded
on different servers by different interfaces, both wasting space on your
memcached
and leading to
potential differences in the information.
Note
One way to use a multi-interface compatible hashing mechanism is to use the
libmemcached
library and the associated interfaces. Because the interfaces
for the different languages (including C, Ruby, Perl and Python) use the same
client library interface, they always generate the same hash code from the ID.
The problem with client-side selection of the server is that the list of the servers (including their
sequential order) must remain consistent on each client using the
memcached
servers, and the servers
must be available. If you try to perform an operation on a key when:
• A new
memcached
instance has been added to the list of available instances
• A
memcached
instance has been removed from the list of available instances
• The order of the
memcached
instances has changed
When the hashing algorithm is used on the given key, but with a different list of servers, the hash
calculation may choose a different server from the list.
If a new
memcached
instance is added into the list of servers, as
new.memc
is in the example below,
then a GET operation using the same key,
myid
, can result in a cache-miss. This is because the same
value is computed from the key, which selects the same index from the array of servers, but index 2
now points to the new server, not the server
c.memc
where the data was originally stored. This would
result in a cache miss, even though the key exists within the cache on another
memcached
instance.
Figure 15.6.
memcached
Hash Selection with New
memcached
instance
This means that servers
c.memc
and
new.memc
both contain the information for key
myid
, but the
information stored against the key in eachs server may be different in each instance. A more significant
problem is a much higher number of cache-misses when retrieving data, as the addition of a new
Summary of Contents for 5.0
Page 1: ...MySQL 5 0 Reference Manual ...
Page 18: ...xviii ...
Page 60: ...40 ...
Page 396: ...376 ...
Page 578: ...558 ...
Page 636: ...616 ...
Page 844: ...824 ...
Page 1234: ...1214 ...
Page 1427: ...MySQL Proxy Scripting 1407 ...
Page 1734: ...1714 ...
Page 1752: ...1732 ...
Page 1783: ...Configuring Connector ODBC 1763 ...
Page 1793: ...Connector ODBC Examples 1773 ...
Page 1839: ...Connector Net Installation 1819 2 You must choose the type of installation to perform ...
Page 2850: ...2830 ...
Page 2854: ...2834 ...
Page 2928: ...2908 ...
Page 3000: ...2980 ...
Page 3122: ...3102 ...
Page 3126: ...3106 ...
Page 3174: ...3154 ...
Page 3232: ...3212 ...