It is unfortunate that this ticket has yet to be addressed. I'd like to use the memcached api to hook PHP sessions into - I can do this on mysql 5.6 but not MariaDB.

To me this feature is critical.

Hi:
My name is Zenan Meng from China. I’m now a grade three CS student in Peking University. I hope to participate in GSOC this year, I'm quite interest in this project and I want to contribute on this project. so I didn't hesitate to leave a comment.
I'm familiar with using Mysql and Memcached, I was reading the source code of Memcached recently. I haven't use MariaDB but I heard of how powerful MariaDB was a lot and I'll try it right now. I think it must be a great honor if I can contribute to MariaDB as my first step into open source.
I have modest project experience and I've been intern in several top companies. this Summer, I plan to spend the whole summer for GSOC full-time. I think can complete this project on time.
Given my great interest in join this project. I'm approaching you as soon as I saw this project. I would like to hear from mentor, so that we can start to know each other and discuss about formal proposal and the next step.
Looking forward to hear from the mentor. my email address is : thisismzn@gmail.com.
Best Regards
Zenan Meng

It might be worthwhile to consider, (at least for when there is sufficient memory in the memached server), to tie setting and removing data similar to an after trigger, IE. after insert set memcached data, after update set memcached data, after delete remove memcached data, doing this (essentially a transparent trigger), the memcached server that the table is attached to is at least table data consistent, (assuming that inserts, updates and deletes occur only in the database), this sort of behavior would work reasonably well with an external memcache server and would allow for db operations to push to the caching server and not worry about whether the cache is going to update the db, as an option it be worthwhile to indicate as a per table option to indicate the table key to memcache key method, (IE. how to handle compound primary keys), the benefit of doing this is that you create a flexible yet consistent method for internal APIs to retrieve data,also it might be worthwhile to have a memcache server pool configuration so that the data is set against a full pool of memcache servers.

Thank you ,for your suggestions ,these pointers would help me with my approach towards the project for GSOC 2015, meanwhile please have a look at this raw proposed architecture here: https://lists.launchpad.net/maria-developers/msg08338.html and further give your suggestions.

I took a look at your proposed architecture.

A couple of items. By limiting yourself and your approach to a single local custom memcache server instance tied to the database table you are complicating other developers designs when they will be trying to implement a service against this memcached table.

First consider that almost every implementation of memcache in a service chain has as part of its get data from memcache server method, a statement that says if data doesn't exist in memcache retrieve from underlying data source and store into memcache.
Second, if you are planning for crud operations in memcache to control the contents of the innodb table then that means you are creating a custom version of memcache that needs to talk to the attached table, additionally it sounds as though you are planning to use a custom memcache server instance per table, one table per instance per port. Furthermore you would be allowing out of memory issues to reduce the contents of the table when most users would expect the rows to be persisted in the DB.

Most architects wanting to implement a database against a memcache server either already has one or more memcache servers in house, or is expecting the same behavior out of this plugin as the default memcache server provides.

My approach would be as follows:

Consider for a moment how the federated table engine presents itself to users.
There is a custom table containing config options in the mysql database, and there is a custom sql command, create server that enters data into the mysql.servers table.

I personally (despite the fact I can't really write the necessary code) would present 3 tables in the mysql database the first would be a memcache_servers table as follows:
ServerAddress Varchar(255) not null primary key,
ServerPort int unsigned not null,
ServerProtocol ENUM('TCP','UDP') not null DEFAULT 'TCP',
RetryCount int unsigned not null DEFAULT 3,
RetryDelay int unsigned not null DEFAULT 500 COMMENT 'milliseconds'

The second would be a table called memcache_pools which should be as follows:
ServerPoolName varchar(255) not null primary key,
DB_Table_Key_Sep varchar(16) not null,
PriColumn_Key_Sep varchar(16) not null

And the third would be a table called memcache_pool_servers which should be as follows:
ServerPoolName varchar(255) not null primary key,
ServerAddress Varchar(255) not null primary key

In addition to these three tables I would have custom sql commands along the lines as follows:
Create memcache_server address port protocol;
Create memcache_pool name dbtablesep pricolkeysep;
Update memcache_pool name add/drop address;
Etc.

Presenting the configuration in this manner would allow for behavior along the lines of:
Alter table name memcache_pool="poolname";

This in conjunction with the transparent after trigger support I mentioned in my earlier comment would allow for some very highly consistent, and flexible behavior.

One of the benefits to this approach is that memcache support on a table becomes table engine agnostic, and can be integrated with an existing memcache server implementation with relative ease, additionally it would allow for some complex behaviors where certain memcache servers can share servers allowing for custom service permissions on the side of the service connecting to the memcache servers. Ie documents can be served to memcache pool 1 and 2 but memcache pool 1 gets user info and pool 2 gets admin info.
Another benefit is that unless the person implementing this plugin desires to put the memcache server on the database server they don't have to.
Furthermore because we are relying on an industry standard for memcache support the implementer will not have to write custom code to support a custom memcache implementation, and you as the person writing the plugin will not have to worry about having a port listener and implementing your own custom memcache, thus making for in theory at least a lighter weight plugin.

Finally this would allow for on the fly additions to memcached table data without server reconfiguration and restarts.

My name is Piotr Jurkiewicz. I am a last year MSc student at AGH University of Science and Technology in Krakow, Poland. I submitted my own GSoC proposal for this project. You can review it here:

http://www.google-melange.com/gsoc/proposal/public/google/gsoc2015/piotrjurkiewicz/5743522325987328

It includes everything, what has been said so far here, as well as my own ideas, based on my experience with MySQL InnoDB Memcached plugin.

I plan to base my implementation on the existing MySQL InnoDB Memcached plugin. In particular, I plan to retain all useful features, like multi-column support or transaction settings control. Changes, which I would like to introduce, are listed in Section 4 of my proposal.

@ramouton:

I find your idea to trigger update of external Memcached servers by SQL operations very interesting.

One can imagine traditional web application, which uses SQL to retrieve and modify data in db. Now, after each data modification, such an application has to update data copy in Memcached server. With the proposed triggers mechanism, it would be done automatically by SQL server. So application will be able to save one RTT to Memcached server, what should result in shorter response times. Such an application can still use SQL protocol to access db, or switch to Memcached protocol interface provided by my plugin.

However, I consider this feature fairly separate from my planned Memcached plugin.

My plugin will make MariaDB a server speaking Memcached protocol with its clients.

What you want, is to make MariaDB a client speaking Memcached protocol to external Memcached servers.

These two functionalities are orthogonal. Of course, they can be unified in one plugin. Nonetheless, I think that better way would be to provide them by separate plugins, as they can be perfectly used alone and do not rely on each other.

Maybe these ideas can be a subject of another GSoC project?

We could implement memcache/handlersocket with rocksdb?

For the record, the MySQL 5.6 and 5.7 implementation of the InnoDB Memcached plugin is based on the Memcached 1.6.0-beta1 release (April 2011). There has not been much going on in the engine-pu branch since then, and as far as I can tell, there also have not been any further merges of Memcached code to MySQL since then. The last merge from the master branch (which tracks the stable 1.4 series development) was in August 2011. There are only a few small commits after that merge, the last ones in 2013.
Compared to that, the master branch is very busy (last changed in January 2017, for the Memcached 1.4.34 release).

I do not think that it is OK to bundle an old snapshot of an apparently abandoned development branch of a library in a stable product. That is why I filed MDEV-12050 to remove the currently unused InnoDB part of the Memcached interface from MariaDB Server 10.2.

the memcache protocol and memcached software are stable, the important part here is remove SQL parser and others parts of mysql protocol/optimizer/parser to improve single CRUD operations (like handler socket do)

I have removed the fixVersion for this task as it is one of 5.5, 10.1, 10.2, 10.3, which are EOLed.

Please add a new fixVersion if you plan to work on this task for a not EOLed versions.