Details
-
Task
-
Status: Open (View Workflow)
-
Minor
-
Resolution: Unresolved
-
None
-
None
Description
Like mysql 5.6 - innodb memcached
we could map a TCP/UDP PORT to a mariadb db.table (no matter if it's aria,innodb or other engine)
I'm thinking something in configuration file like:
memcache-protocol=tcp;11211;database.table
memcache-protocol=udp;11211;database.table
memcache-protocol=tcp;11212;database.table2
memcache-protocol=udp;11212;database.table2
it will create 2 tcp and 2udp 'servers'
when a user send a GET/SET/other memcached command over a determined port, the server will lock the table (or the row when possible) of that port, and execute the get/set and return the value via memcached protocol
no query cache here (maybe we could implement?)
maybe we have many work done in mysql 5.6 code
i'm happy with handler protocol, but i have some old/new codes that still using a dedicated memcache server, and i want to remove them and use only one mariadb server (it's easier to solve problem with only one server)
Attachments
Issue Links
- is caused by
-
-
- Closed
-
- relates to
-
-
- Open
-
- links to
Activity
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.
@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?