The ever increasing performance demands of web-based services has generated significant interest in providing NoSQL access methods to MySQL - enabling users to maintain all of the advantages of their existing relational database infrastructure, while providing blazing fast performance for simple queries, using an API to complement regular SQL access to their data.
The HandlerSocket development at DeNA is a great example of community innovation, with a solution implemented as a custom plug-in and protocol for the MySQL server daemon.
We are hearing the community say they want NotOnly SQL - they want their trusted SQL RDBMS - plus, they want NoSQL techniques to access that data. So, we are previewing our NotOnlySQL solution for MySQL - delivered via memcached - with implementations to access both the InnoDB and MySQL Cluster (NDB) storage engines.
The purpose of this article is to provide more detail on the Memcached API for MySQL, specifically covering:
* Design rationale
* Implementation
* Getting started
Design Rationale
Using the memcached API, web services can directly access the InnoDB and MySQL Cluster storage engines without transformations to SQL, ensuring low latency and high throughput for read/write queries. Operations such as SQL parsing are eliminated and more of the server’s hardware resources (CPU, memory and I/O) are dedicated to servicing the query within the storage engine itself.
Over and above performance, there are a number of additional potential benefits in this approach for both developers and DBAs:
* Preserves investments in memcached infrastructure by re-using existing memcached clients and eliminates the need for application changes.
* Access to the full range of memcached client libraries and platforms, providing maximum deployment flexibility and consistently high performance across all supported environments.
* Extends memcached functionality by integrating persistent, crash-safe, transactional database back-ends offering ACID compliance, rich query support and extensive management and monitoring tools.
* Reduces service disruption caused by cache re-population after an outage (note that buffer pool reloading enhancements planned for a future milestone release will further improve recovery performance by warming the cache)
* Simplifies web infrastructure by compressing the caching and database layers into a single data tier, managed by MySQL.
* Reduces development and administration effort by eliminating the cache invalidation and data consistency checking required to ensure synchronization between the database and cache when updates are committed.
* Eliminates duplication of data between the cache and database, enabling simpler re-use of data across multiple applications, and reducing memory footprint.
* Flexibility to concurrently access the same data set with SQL, allowing complex queries to be run while simultaneously supporting Key-Value operations from memcached.
Of course, the memcached implementations for InnoDB and MySQL Cluster are still in their early phases of development (though MySQL Cluster is more mature at this stage), and so neither is suitable for production deployment. Nonetheless, developers can at least get a taste of what is possible as these features evolve.
Implementation
The initial memcached API implementations for InnoDB and MySQL Cluster take slightly different approaches, which are discussed below.
Note that both implementations are dependent on memcached 1.6.
Memcached and InnoDB
As illustrated in Figure 1, memcached protocol access for InnoDB is implemented via a memcached daemon plug-in to the mysqld process, with the memcached protocol mapped to the native InnoDB API.
Full article...
