MySQL/MariaDB run single query on multiple cores

Question

I have a decently strong database server with around 24 cores and 48 GB of RAM. We are running MariaDB 10.0 as our database engine. All my tables are running on InnoDB engine.I have a few queries that employ rather extensive joins over large tables and hence are naturally slow. One thing I am struggling to do is to try and leverage the power of multiple cores. Here are my observation:

1. If I run 2 queries in parallel, then I can see 2 cores being utilized
2. If I run 1 query, I see only 1 core being utilized at 100%

Now, is this the normal behavior? What I mean is that is there no way in MariaDB/MySQL to utilize more than one core for a single query? It will be great if a single heavy query can run faster by utilizing multiple CPU cores.

I did try and search multiple forums and have played with different parameters like Innodb_thread_cocurrency, but so far haven't been able to run a single query on multiple cores.

Is there any other engine which can help me do that (I am currently reading about XtraDB)?

UPDATE:

Well, actually I am trying to analyze social media data. So imagine a database with 2-3 million tweets. Naturally we are talking associated tables with USer data, hashtags, images, links etc. So all in all a decently large database. In certain cases there are queries which require some joins on multiple tables and are naturally slow. So, imagine , for instance a dashboard query with 5-6 different queries. When a single user logins, this puts load on a single core and the entire core is utilized for n seconds. If I have 12 cores with me, and suppose 12 users simultaneously try to access the system, then I have a serious bottleneck. I understand completely, that options like sharding, clustering, distributed DB, partitioning could help me. But right now I am trying to understand how best to Scale a system vertically before I look at horizontal scaling (wherein I introduce more servers). Utilization of multiple cores would have been a great option, but I guess now I understand that, MySQL isn't inherently designed as such. I think I will start looking at various [possible architectures to scale the DB over multiple instances.

Answer 1

Though this thread is more than half a year old, some of the comments raise some concern. As a hardcore database performance tuner, I'd like to add a little input here:

1) As of this writing, MariaDB and MySQL do not support running a single query on multiple processors ( unless you are talking about sharding of course). It does not mean they won't support it in the future.

2) Parallelizing query can be done in other RDBMS ( DB2, Oracle, SQLServer, Postgres, etc), and it's an important feature for environment such as data warehouse.

3) For long running query, more often than not, parallelizing it would shorten the execution time, though the improvement may not be linear. So, it is incorrect to say that 'it does not make sense one query uses multiple cores to make it work faster'. It makes perfect sense for certain workload, unless we have a different definition of 'work faster'.

4) Bottelnecking CPU does not necessarily imply 'you are using database the wrong way'. Yes, it's true that some people do write horrible query ( or procedure that drive queries) and choke the database to death, but that's a different issue altogether.

5) Parallelism would reduce concurrency. If your goal is to support more users (ie, higher concurrency), you will have to give up running query on multiple processors ( or just running on less processor per query). It's a trade off you will need to make. At the risk of over-generalizing, you would want OLTP environment query to run in serial,and OLAP query to run in parallel.

Cheers!

Answer 2

As Mjh explained , if CPU is the bottleneck, then you must be using your database the wrong way.

InnoDB does not support parallelisation of a single query. You might be able to achieve some kind of parallelisation by spreading your tablespaces across several physical drives (but I am not even sure performance is the primary target for this feature, and if this improves anything, then it does when IO is the bottleneck).

Answer 3

There is a partial solution for some queries. Innodb is highly optimized to run large numbers{1000's} of small {50 - few 1000 rows} requests. So let's take a simple task {copy a 100 M row table to another table}. The simple approach is INSERT ... SELECT... FROM... However, doing this will run a long time and if interrupted roll back takes even longer.

Now take the same problem and write a small procedure that walks the PK 1000 rows at a time thru the table. This runs faster because the process is dominantly memory contained, if interrupted rollback is almost instant and you can restart where it was interrupted.

Now take this procedure and run it twice concurrently, 1 on the 1st half of the range and 2 on the second half. Because INNODB has row level locking this runs almost twice as fast as the single.

Now create some events that wake up frequently and run the procedure for their respective thread. If I have a 16 core server with INTEL processors, I can run say 10 concurrent threads and see CPU in top at 1000%. I have this running for the last 4 years in production. It only takes < 10 tables and < 10 procedures to support it. As an added benefit one of the procedures will output % complete by thread.

Any sql that walks all or part of a numerical range can use this approach. That includes group by where the 1st column in the group is numeric. So not a solution for all queries but for those that it works for we commonly get 5X to 10X elapsed time reduction. In many cases there is also essentially no I/O wait in top so other queries are minimally impacted.