- 188.8.131.52 Adapting an Existing MySQL Schema for a memcached Application
- 184.108.40.206 Adapting an Existing memcached Application for the Integrated memcached Daemon
- 220.127.116.11 Tuning Performance of the InnoDB memcached Plugin
- 18.104.22.168 Controlling Transactional Behavior of the InnoDB memcached Plugin
- 22.214.171.124 Adapting DML Statements to memcached Operations
- 126.96.36.199 Performing DML and DDL Statements on the Underlying InnoDB Table
Typically, writing an application for the
InnoDB memcached interface
involves some degree of rewriting or adapting existing code that
uses MySQL or the memcached API:
Instead of many memcached servers running on low-powered machines, you have the same number of memcached servers as MySQL servers, running on relatively high-powered machines with substantial disk storage and memory. You might reuse some existing code that works with the memcached API, but some adaptation is likely needed due to the different server configuration.
The data stored through this interface all goes into
BLOBcolumns, and must be converted to do numeric operations. You can do the conversion on the application side, or by using the
CAST()function in queries.
Coming from a database background, you might be used to general-purpose SQL tables with many columns. The tables accessed by the memcached code likely have only a few or even just a single column holding data values.
You might adapt parts of your application that do single-row queries, inserts, updates, or deletes, to squeeze more performance out of critical sections of code. Both queries (read) and DML (write) operations can be substantially faster when performed through the memcached interface. The speedup for writes is typically greater than the speedup for reads, so you might focus on adapting the code that performs logging or records interactive choices on a web site.
The following sections explore these aspects in more detail.