1M queries doesn't make sense if most of them actually use Memcached as backend. You can run more than 1M queries like "select 1", it does the same thing. The magic is Memcached.
MySQL 5.7 includes a NoSQL interface, using an integrated memcached daemon that can automatically store data and retrieve it from InnoDB tables, turning the MySQL server into a fast “key-value store” for single-row insert, update, or delete operations. You can still also access the same tables through SQL for convenience, complex queries, bulk operations, application compatibility, and other strengths of traditional database software.
With this NoSQL interface, you use the familiar memcached API to speed up database operations, letting InnoDB handle memory caching using its buffer pool mechanism. Data modified through memcached operations such as ADD, SET, INCR are stored to disk, using the familiar InnoDB mechanisms such as change buffering, the doublewrite buffer, and crash recovery.
==== 8< ====
this is what is being benchmarked here, not pure memcached.
As far as I can tell this is just a a memcached interface to ordinary InnoDB tables, so yes. 1000k queries per second also sounds plausible since stock PostgreSQL can reach almost 400k queries per second with normal SQL queries.
The storage engines of relational databases are this fast (for read-only queries to datasets which fit in memory).
Yes but this doesn't change the fact that the queries use Memcached as the backend. If all of 1M queries hit the InnoDB tables, then I would be impressed. Also note that it's read-only performance, I think MySQL acts like a bridge here for most of the queries. (Correct me if I'm wrong.)
