Planet MySQL
Planet MySQL -

  • MariaDB 10.0.10 uploaded to Debian experimental
    If you’re watching the NEW queue, you’ll notice that MariaDB 10.0.10 has been uploaded targeting Debian/experimental. Package description, and to think the bug was only opened on April 2nd – pretty quick turnaround. Related posts: MariaDB in Debian unstable Debian releases Lenny, MySQL 5.1 soon MariaDB in Gentoo; updates for Solaris/Debian SPARC

  • Really large NLP corpora
    Jeeze people. You’re all noisy. I’m sure it was all done for posterity’s sake. 23M irclogs/MagNET/#perl.log 29M irclogs/freenode/#mysql.log 36M irclogs/freenode/#debian.log 37M irclogs/foonetic/#xkcd.log 39M irclogs/OFTC/#debian.log 43M irclogs/freenode/#jquery.log 44M irclogs/freenode/#perl.log

  • FYI: Galera is just a provider
    No news in telling Galera is the synchronous multi master solution for MySQL. But Galera is just a provider. What do you mean by provider? Remember configuring “Galera”? There are two options wsrep_provider and wsrep_provider_options These define the provider (Galera) and the options for the provider. The rest of the wsrep_ options are for wsrep. wsrep API defines a set of application callbacks and replication library calls necessary to implement synchronous writeset replication of transactional databases and similar applications. It aims to abstract and isolate replication implementation from application details. Although the main target of this interface is a certification-based multi-master replication, it is equally suitable for both asynchronous and synchronous master/slave replication. So yes, other providers than galera are possible \o/ I.e. an asynchronous replication provider could already benefit from the parallel applying provided by wsrep :) Have fun Erkan

  • Concurrent, read-only, not cached: MongoDB, TokuMX, MySQL
    I repeated the tests described here using a database larger than RAM. The test database has 8 collections/tables with 400M documents/rows per table. I previously reported results for this workload using a server with 24 CPU cores and a slightly different flash storage device. This time I provide a graph and use a server with more CPU cores. The goal for this test is to determine whether the DBMS can use the capacity of a high-performance storage device, the impact from different filesystem readahead settings for MongoDB and TokuMX and the impact from different read page sizes for TokuMX and InnoDB. It will take two blog posts to share everything. I think I will have much better QPS for MongoDB and TokuMX in my next post so I won't list any conclusions here.SetupI used my forked Java and C sysbench clients. The test query fetches one document/row by PK. The test database has 8 collections/tables with 400M rows per collection/table. All are in one database. I still need to enhance the Java sysbench client to support a database per collection. I tested the configurations listed below. I don't think these are the best configurations for TokuMX and MongoDB and am running more tests to confirm. The test server has 144G RAM, 40 CPU cores and a fast flash storage device.fb56.handler - 740G database, MySQL 5.6.12 with the Facebook patch, InnoDB, page_size=8k, data fetched via HANDLERfb56.sql - 740G database, MySQL 5.6.12 with the Facebook path, InnoDB, page_size=8k, data fetched via SELECTorig57.handler - 740G database, official MySQL 5.7.4, InnoDB, page_size=8k, data fetched via HANDLER. orig57.sql - 740G database, official MySQL 5.7.4, InnoDB, page_size=8k, data fetched via SELECTtokumx32 - 554G database, TokuMX 1.4.1, quicklz, readPageSize=32K, 16K filesystem readaheadtokumx64 - 582G database, TokuMX 1.4.1, quicklz, readPageSize=64K, 32K filesystem readaheadmongo24 - 834G database, MongoDB 2.4.9, powerOf2Sizes=0, 16K filesystem readaheadmongo26 - 874G database, MongoDB 2.6.0, powerOf2Sizes=1, 16K filesystem readaheadResultsResults for MySQL 5.7.4 are not in the graph to keep it readable and are similar to MySQL 5.6.12. Note that MySQL is able to get more than 100,000 QPS at high concurrency, TokuMX reaches 30,000 and MongoDB isn't able to reach 20,000. I think MongoDB and TokuMX can do a lot better when I reduce the filesystem readahead for both and reduce the read page size for TokuMX and results for that are in my next post. MongoDB also suffers in this test because the PK index is so large that all leaf nodes cannot fit in RAM so there is more than one disk read per query. This isn't something that goes away via tuning. The workaround it to make sure the database:RAM ratio isn't too big (and spend more money on hardware).This lists the QPS from the graph.point queries per second     8     16     32     40  clients 39928  63542 102294 107769  fb56.handler 33630  56834  91132 102336  fb56.sql 39714  63359 101987 106205  orig57.handler 33561  56725  90900 101476  orig57.sql 12586  22738  31407  32167  tokumx32 10119  16373  18310  18232  tokumx64 12782  16639  17350  17435  mongo24 12503  17474  17988  18022  mongo26AnalysisThese tables list the average disk read rate from iostat r/s and the average number of disk reads per query. InnoDB is by far the most efficient with the smallest number of disk reads per query. TokuMX benefits from having the smallest database courtesy of quicklz compression but might suffer from a larger read page size (32k and 64k). But I don't think that is the only reason why the disk reads per query ratio is so much larger than InnoDB and TokuMX. I am repeating tests with an 8k read page size to confirm. MongoDB suffers from a PK index that is too large to be cached so disk reads are done for it and the document store. Both TokuMX and MongoDB might also do extra reads because of the filesystem readahead and I am repeating tests with smaller values for it to confirm.iostat r/s     8     16     32     40  clients 33661  53502  86028  90616  fb56.handler 29120  49155  78748  88423  fb56.sql 33776  53702  86193  89755  orig57.handler 29244  49268  78801  88027  orig57.sql 26756  47813  65885  67840  tokumx32 23728  37442  41357  42089  tokumx64 18966  24440  25147  25322  mongo24 18312  25313  25701  25781  mongo26disk reads per query     8     16     32     40  clients  0.84a  0.84   0.84   0.84  fb56.handler  0.86   0.86   0.86   0.86  fb56.sql  0.85   0.84   0.84   0.84  orig57.handler  0.87   0.86   0.86   0.86  orig57.sql  2.12   2.10   2.09   2.10  tokumx32  2.34   2.28   2.25   2.29  tokumx64  1.48   1.46   1.44   1.45  mongo24  1.54   1.44   1.42   1.43  mongo26

  • Help fill the MySQL Track At SELF
    Help fill up the MySQL track at the Southeast Linux Fest. RFP for #self2014 has been extended to Mon April 28th at 9 PM ET. Last chance! Get those talk submissions in!