Использование машинного обучения для характеристики рабочих нагрузок баз данных

Jun 27, 2023

Базы данных помогают нам управлять нашими данными на протяжении десятилетий. Как и большинство технологий, с которыми мы работаем ежедневно, мы можем начать воспринимать их как должное и упускать возможность изучить их использование — и особенно их стоимость.

Например, Intel хранит большую часть своего огромного объема производственных данных в системе управления реляционными базами данных (RDBMS) с массовой параллельной обработкой (MPP). Чтобы держать под контролем затраты на управление данными, ИТ-отдел Intel решил сравнить нашу текущую СУБД MPP с альтернативными решениями. Прежде чем мы смогли это сделать, нам нужно было лучше понять рабочие нагрузки наших баз данных и определить эталонный тест, который хорошо отражает эти рабочие нагрузки. Мы знали, что тысячи инженеров-технологов запрашивали данные, и знали, какой объем данных поступает в систему. Однако нам нужно было больше подробностей.

«Какие типы заданий составляют общую рабочую нагрузку базы данных?»

«Какие бывают запросы?»

«Сколько одновременных пользователей имеется для каждого типа запроса?»

Позвольте мне представить пример, чтобы лучше проиллюстрировать тип информации, которая нам нужна.

Представьте, что вы решили открыть салон красоты в своем родном городе. Вы хотите построить объект, который сможет удовлетворить сегодняшний спрос на услуги, а также обеспечить рост бизнеса. Вам следует прикинуть, сколько людей будет в магазине в час пик, чтобы знать, сколько станций нужно установить. Вам необходимо решить, какие услуги вы будете предлагать. Сколько человек вы сможете обслужить, зависит от трех факторов: 1) скорости работы косметологов; 2) сколько косметологов работает; и 3) какие услуги хочет клиент (например, просто стрижка или маникюр, окраска волос и массаж). «Рабочая нагрузка» в данном случае зависит от того, чего хотят клиенты и от их количества. Но это также меняется со временем. Возможно, бывают периоды, когда многие клиенты просто хотят подстричься. В другие периоды (скажем, перед Днем святого Валентина) спросом пользуются как стрижка, так и окраска волос, а в другое время массаж может быть почти единственным спросом (скажем, люди, использующие все эти подарочные карты на массаж, которые они только что получили на День святого Валентина). . Оно может быть даже на первый взгляд случайным, не связанным ни с каким календарным событием. Если у вас будет больше клиентов в часы пик, и у вас не будет достаточного количества станций или квалифицированных косметологов, людям придется ждать, а некоторые могут посчитать, что здесь слишком многолюдно, и уйти.

Итак, теперь вернемся к базе данных. Для нашей СУБД MPP «сервисы» — это различные типы взаимодействия между базой данных и инженерами (потребление) и системами, отправляющими данные (прием). Прием состоит из стандартного извлечения-преобразования-загрузки (ETL), ETL критического пути, массовых загрузок и запросов на вставку, обновление и удаление внутри БД (как больших, так и малых). Потребление состоит из отчетов и запросов — некоторые выполняются как пакетные задания, некоторые — для конкретного случая.

В начале нашей характеристики рабочей нагрузки мы хотели определить виды «сервисов» базы данных, которые выполнялись. Мы знали, что, как в примере с салоном красоты «обрезка» и «полное обслуживание», SQL-запросы могут быть очень простыми, очень сложными или где-то посередине. Чего мы не знали, так это того, как обобщить большое количество этих запросов во что-то более управляемое, не упустив при этом чего-то важного. Вместо того, чтобы доверять своей интуиции, мы хотели подойти к этому методично. Мы применили новый подход к полному пониманию SQL-запросов: мы решили применить методы машинного обучения (ML), включая кластеризацию k-средних и деревья классификации и регрессии (CART).

В нашем примере с салоном красоты мы могли бы использовать кластеризацию k-средних и CART для анализа клиентов и выявления групп со схожими чертами, например «только парикмахерские услуги», «услуги по уходу за волосами и ногтями» и «только ногтевые услуги».

Для нашей базы данных наши усилия по кластеризации k-средних и CART показали, что запросы ETL состоят из семи кластеров (по прогнозам по времени ЦП, максимальному количеству операций ввода-вывода потока и времени выполнения), а запросы SQL могут быть сгруппированы в шесть кластеров (в зависимости от времени ЦП). ).