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