5 ms·
This is sorta misleading. A quote from the article, "The changes in the MariaDB source code leading to those impressive performance improvements are part of por
by suneilp 11y ago
This is sorta misleading. A quote from the article, "The changes in the MariaDB source code leading to those impressive performance improvements are part of porting MariaDB to Power8."
Pretty frustrating. I was pretty excited since MariaDB is a drop in replacement for MySQL (more or less). But you have to use it on a totally different architecture which can't be justified without a lot of deliberation.
- glogla 11y agoIt's also 2 socket, 20 core, 8 thread per core = 160 hardware thread system. And it's not general queries, but just "point selects" from 20 tables of 1 million rows combined. That's far from typical hardware to deploy maria/mysql on, and far from realistic workload.
- suneilp 11y agoYeah, I want to drool but utilizing that many threads in "practical" scenarios seems difficult. It would probably be great for messaging systems though!
- glogla 11y agoNot just that, but database performance drops quickly with writes. 1M transactions per second with 100 % reads might as well mean 10K transactions per second with 95 % readsm 5 % writes ("the usual OLTP workload" per common wisdom) and 1K transactions per second on 50 % reads 50 % writes. Or even less. Or much more. It's difficult to even quess.
- arielweisberg 11y agoWhat stood out to me was that the measurement was taken against 20 tables. That makes me wonder if a smaller number of tables would have hit contention even in a read only workload. Well it's not the only database that has this problem. I wonder if partitioning is enough or if you really need separate tables.
- hyperpape 11y ago"The data set is 1 million rows in 20 tables. Fewer tables can be used, but below 4 tables the performance drops somewhat due to a hot spot in the table definition cache."
- spudlyo 11y agoFrom my reading of the article, a lot of the performance improvements come getting rid of the mutex in front of their hash based metadata cache by using a lock free hashing algo. These changes originally came from Oracle's MySQL 5.7 work[1]. Looks like MariaDB merged the lock-free hashing stuff into their version, and applied it to the table definition hash which also suffered from lock contention. These are changes that all architectures can benefit from. [1]: http://mysqlserverteam.com/removing-scalability-bottlenecks-in-the-metadata-locking-and-thr_lock-subsystems-in-mysql-5-7/ http://mysqlserverteam.com/removing-scalability-bottlenecks-...
- morgo 11y agoSimilar numbers (1.6M) can be achieved with Intel and MySQL 5.7: http://www.infoworld.com/article/2994381/database/mysql-57-delivers-a-3x-speed-injection.html http://www.infoworld.com/article/2994381/database/mysql-57-d...