Как ускорить запросы MySQL в приложении реального времени

#mysql #bigdata

Вопрос:

Я создал блестящее приложение, которое отображает графики, таблицы и карты, запрашивая в режиме реального времени базу данных MySQL. Поскольку мы говорим о больших данных (т. е. 12 миллионах строк), выполнение запросов занимает много времени, как в SQL, так и в Spark (с использованием scala и python). У вас есть какие-либо предложения по ускорению этих запросов? Я подумывал о переходе на Cassandra, но миграция данных из реляционной базы данных в базу данных NoSQL является сложной задачей …

Справочная информация базы данных: Данные об обнаружении транспортного средства в заданную метку времени и заданную станцию Bluetooth. Есть две таблицы: одна для местоположения и названия станций и одна с отметкой времени, станцией и количеством транспортных средств.

Ниже приведен пример запроса, в котором я группируюсь по месяцам, чтобы получить общее количество транспортных средств, обнаруженных в каждом месяце.

 SELECT MONTH(timestamp) as month,SUM(count) as c
FROM bluetoothstations.measurement
GROUP BY month(timestamp);
 

Заранее благодарю вас!

Комментарии:

1. Как 12-миллиметровые строки можно считать большими данными?

Ответ №1:

Данные не меняются после их вставки, правильно? В этом случае дополняйте «сводную таблицу» каждую ночь (или по мере поступления данных INSERTed ). Тогда сводная таблица позволит гораздо быстрее генерировать COUNT (или другие агрегированные данные).

Дополнительные обсуждения: http://mysql.rjweb.org/doc.php/summarytables

Комментарии:

1. Большое вам спасибо! Я действительно пробовал это решение сегодня, и оно ускоряет работу всего приложения. Затем я использовал некоторые триггеры, чтобы обновить их.

2. Да, это «ускоряет все», делая эти запросы менее агрессивными.

Ответ №2:

Я думаю, что MONTH(timestamp) это вызывает полное сканирование таблицы. Я предполагаю, что если бы вы сохранили MONTH(timestamp) как отдельный столбец в bluetoothstations.measurement, скажем , вызвали, month а затем добавили индекс month , то вы могли бы запустить

 SELECT month,SUM(count) as c
FROM bluetoothstations.measurement
GROUP BY month;
 

который, как я ожидал, будет работать быстрее.

Используйте DESCRIBE (aka EXPLAIN ), чтобы получить план выполнения вашего запроса; это должно дать вам лучшее представление о том, что замедляет ваш запрос и где вам нужны индексы.

Комментарии:

1. Этот подход превращает сканирование всей таблицы в полное сканирование индекса . Это может немного помочь, но не обязательно сильно.

2. Согласованный. Запрос, как написано, должен будет достичь 12 миллионов чего- то , и это будет не быстро. Использование сводной таблицы, безусловно, было бы лучше.

3. Я думал об этом варианте, но, во-первых, я должен изменить уже автоматизированный скрипт, который вставляет новые данные в БД, а во-вторых, он добавляет избыточность в основную таблицу, не принося реальных преимуществ. Я имею в виду, что я должен сделать то же самое для дня недели и часа. Однако спасибо вам за ваше предложение 🙂