Is not advisable to move calculations from MySQL to PHP? - php

Question

I got stuck with the question/problem I've asked earlier about – How to optimise a table for AVG query? It turns out that #MichaelT was right about one thing – calculating AVG is faster using PHP than MySQL (like 80% faster with 5m records and 24 GB RAM machine).
It isn't always even an options. However, consider this code example (dataset size 5m records).
The MySQL way.
1) aggregate data (creating a temporary data) (500ms)
CREATE TEMPORARY TABLE `temporary_grouped_data` AS
(
SELECT
`r1`.`id`,
`c1`.`wt`,
`c1`.`cpu`,
`c1`.`mu`,
`c1`.`pmu`
FROM
`requests` `r1`
INNER JOIN
`request_hosts` `rh1`
ON
`rh1`.`id` = `r1`.`request_host_id`
INNER JOIN
`request_uris` `ru1`
ON
`ru1`.`id` = `r1`.`request_uri_id`
INNER JOIN
`calls` `c1`
ON
`c1`.`id` = `r1`.`request_caller_id`
WHERE
1=1 {$sql_query['where']}
);
2) get overall AVG (300ms)
SELECT COUNT(`id`), MIN(`wt`), MAX(`wt`), AVG(`wt`), MIN(`cpu`), MAX(`cpu`), AVG(`cpu`), MIN(`mu`), MAX(`mu`), AVG(`mu`), MIN(`pmu`), MAX(`pmu`), AVG(`pmu`) FROM `temporary_grouped_data`;
3) calculate 95th percentile (200ms)
SELECT `wt` FROM `temporary_grouped_data` ORDER BY `wt` ASC LIMIT 1726, 1;
SELECT `cpu` FROM `temporary_grouped_data` ORDER BY `cpu` ASC LIMIT 1726, 1;
SELECT `mu` FROM `temporary_grouped_data` ORDER BY `mu` ASC LIMIT 1726, 1;
SELECT `pmu` FROM `temporary_grouped_data` ORDER BY `pmu` ASC LIMIT 1726, 1;
4) calculate mode (200ms)
SELECT `wt`, COUNT(`wt`) `quantity` FROM `temporary_grouped_data` GROUP BY `wt` ORDER BY `quantity` DESC LIMIT 1;
SELECT `cpu`, COUNT(`cpu`) `quantity` FROM `temporary_grouped_data` GROUP BY `cpu` ORDER BY `quantity` DESC LIMIT 1;
SELECT `mu`, COUNT(`mu`) `quantity` FROM `temporary_grouped_data` GROUP BY `mu` ORDER BY `quantity` DESC LIMIT 1;
SELECT `pmu`, COUNT(`pmu`) `quantity` FROM `temporary_grouped_data` GROUP BY `pmu` ORDER BY `quantity` DESC LIMIT 1
The PHP way.
1) Get all the relevant records into an array (200ms).
SELECT
`r1`.`id`,
`c1`.`wt`,
`c1`.`cpu`,
`c1`.`mu`,
`c1`.`pmu`
FROM
`requests` `r1`
INNER JOIN
`request_hosts` `rh1`
ON
`rh1`.`id` = `r1`.`request_host_id`
INNER JOIN
`request_uris` `ru1`
ON
`ru1`.`id` = `r1`.`request_uri_id`
INNER JOIN
`calls` `c1`
ON
`c1`.`id` = `r1`.`request_caller_id`
2) Perform all the calculations (200ms).
The PHP approach is by far faster. Is there any reason why I shouldn't use PHP to perform these calculations?

Answer 1

Shifting the work off to PHP means having to transfer the whole result set over the wire, which could be really bad depending on the size. Also, I am not a database person by any stretch of the imagination but these results are unexpected. You should look into the possibility you are doing things the wrong way in the database version.

Answer 2

Speed isn't everything. I'd put it where it belongs to.
Will it scale in PHP?
Also with the PHP approach, you have to transfer all the data from the db to php. How much RAM does it cost, etc.
Maybe your database isn't well optimized. Your DB's disks might be bad, etc.
Seriously, I'd leave it in the db and check to see why it performs so badly.