MySQL, Memcache, PHP revised
Some time ago I was writing about the InnoDB Memcache Daemon plugin already for the MySQL server. Back then we had a labs release with a little preview only. Meanwhile quite some time passed and new developments were made - just in time for the MySQL 5.6 RC announced this weekend by Tomas.
The innodb_memcache daemon plugin is a plugin for the MySQL Server end contains an embedded memcached. This embedded memcached is configured to use MySQL's InnoDB engine as storage backend. By using this data stored inside an InnoDB table can be accessed using memcache's key-value protocol. Back in the times of the previous blog post this was limited to data from a single table, which maps easily to the key-value nature of memcache but is a clear limitation. The InnoDB obviously knows that and improvd it:
A user may now define multiple configurations at the same time and therefore access different tables at the same time - or the same table using different key-columns as memcache key, for accessing the data the memcache key names will then be prefixed by specially formatted configuration names.
Let's take a look at an simple example. Assume we have this configuration inside innodb_memcache.containers:Name: prefix_test schema: test table: test key column: id key name: PRIMARY KEY value columns: lastname
We can then use the memcache configuration using a key like this:set @@prefix_test.1 SchlAter get @@prefix_test.1
The first call will store my last name with id=1 in the test.test table. For accessing multiple configurtions we simply add entries to the containers list.
Of course we can still access miltiple columns, as in the previous version:Name: test_first_last schema: test table: test key columns: id key name: PRIMARY value columns: firstname,lastname
And then we add my firstname:set @@test_first_last.1 Johannes,SchlAter get @@test_first_last.1
The configurations above are, obviously, just a short introduction. For full information please check the documentation.
Now this blog entry is tagged a s PHP. Hs is that coming into play? - Well, on the one side we have this fast memcache interface, which allows to access almost arbitrarry data from the database. On the other side we have our PHP mysqlnd plugin interface where we can add special features, like query caching or load balancing, transparently to any PHP application. Why not combine those two things? - Good question. That's what we have done in the PECL mysqlnd_memcache PHP extension. This PHP extension is a plugin to mysqlnd intercepting queries sent to the server. In a quick analysis it tries to identfy whether an SQL statement can - transparently - be converted into memcache requests. We therefore exchange some computing power on the PHP server and gain more performance from the MySQL server. As SQL is a rather complex language and memcache is a quite limited key-value protocol this will only work for a limited subset of common queries though.
So let's take a look at some PHP code:addServer("localhost", 11211); mysqlnd_memcache_set($mysql, memcache); ?
Here we ceate a MySQL connection using mysqli as well as a memcache connection using the pecl/memcached extension. Instead of mysqli we could, as with any mysqlnd plugin, use ext/mysql or the MySQL PDO driver. We then associate the MySQL connection with the memcache connection. As a consequence of this code the mysqlnd_memcache plugin will query the MySQL server for the current memcache configuration. Subsequently it will analyse SQL queries sent to the server:query("SELECT firstname, lastname FROM test WHERE id = 1"); $q2 = $mysqli-query("SELECT * FROM test"); ?
These are two normal queries and nothing special on first sight. In case there's no error $q1 and $q2 will hold mysqli_result instances where rows can be read using fetch_row() or in other provided ways. But there are things going on in the back: The PHP extension will see that the first one can be translated to a memcche request and then fetch the data using this shortcut. The second call tries to read all data from the table. The memcache protocol provides no way for doing that so this query will use the "classic" way of sending the SQL to the MySQL server
Truncated by Planet PHP, read more at the original (another 560 bytes)