I've found MySQL to have issues with datasets that don't fit into the innodb buffer pool. Are you doing a lot of partitioning to make everything work well?
If everything is behind an ORM, have you considered trying out PostgreSQL w/ the MySQL FDW? pgsql 10's improvements to FDW's make it a truly viable option.
Also to clarify: I'm just saying this as pgsql seems to handle queries that involve disk access and large datasets much better. I have found that as long as your hot dataset fits into the innodb buffer pool and/or you're doing only key lookups (e.g.: select * from tbl where pk=1;) MySQL is most certainly faster for real-world usage. If you're pulling and sorting/filtering millions (or billions) of rows per query, I find that pgsql stands up extremely well to that. Even in a single huge server setup.
Also a semi-unrelated ditty, but as someone who has to run migrations on pretty big (100m rows) tables, ALTER TABLE LOCK=NONE ALGORITM=INPLACE is pretty great (here's a table of what you can user per-situation https://dev.mysql.com/doc/refman/5.6/en/innodb-create-index-...)
If you made it this far in my comment you'll probably realize I didn't grasp the article well. I just re-read it and tl;dr, MyRocks works well (as expected) with datasets that don't fit into the innodb buffer pool. :)
Our workload is application specific and currently requires MySQL - 100% of queries are on primary keys so most 'hot' paths I think tend to stay resident, at least as far as query operations go. Also, we tend to fetch 'chunks' and operate on those in memory rather than running server side so some of the processing is offset by local operations.
Would be good to dig a bit deeper into this - thanks for the pointers.
If everything is behind an ORM, have you considered trying out PostgreSQL w/ the MySQL FDW? pgsql 10's improvements to FDW's make it a truly viable option.
Also to clarify: I'm just saying this as pgsql seems to handle queries that involve disk access and large datasets much better. I have found that as long as your hot dataset fits into the innodb buffer pool and/or you're doing only key lookups (e.g.: select * from tbl where pk=1;) MySQL is most certainly faster for real-world usage. If you're pulling and sorting/filtering millions (or billions) of rows per query, I find that pgsql stands up extremely well to that. Even in a single huge server setup.
Also a semi-unrelated ditty, but as someone who has to run migrations on pretty big (100m rows) tables, ALTER TABLE LOCK=NONE ALGORITM=INPLACE is pretty great (here's a table of what you can user per-situation https://dev.mysql.com/doc/refman/5.6/en/innodb-create-index-...)
If you made it this far in my comment you'll probably realize I didn't grasp the article well. I just re-read it and tl;dr, MyRocks works well (as expected) with datasets that don't fit into the innodb buffer pool. :)