Arenadata под нагрузкой

Исследования
106530
0
Александр Кондиайн, главный архитектор по хранилищам данных департамента аналитических систем, R-Style Softlab
Компания R-Style Softlab приступила к созданию хранилища данных, которое вместо СУБД Oracle будет использовать новый стек технологий — аналитическую распределенную СУБД Arenadata DB (ADB), построенную на MPP-системе с открытым исходным кодом Greenplum. Прежде чем сделать выбор в пользу данной СУБД, мы провели ее нагрузочное тестирование. Предлагаем ознакомиться с результатами этого исследования.


Цель тестирования

RS-DataHouse разрабатывается в R-Style Softlab с 2003 года и представляет собой систему для построения хранилищ данных, которая базируется на СУБД Oracle и широко использует ее возможности, в том числе объектно-ориентированное программирование. Однако в последнее время заказчики все чаще стали спрашивать о возможности построения хранилищ данных на альтернативных СУБД. Причина такого интереса кроется не только в пресловутом импортозамещении, но и в возможности удешевить стоимость внедрения.
Описание текущей версии системы RS-DataHouse вы найдете на сайте компании
ПЕРЕЙТИ К ОПИСАНИЮ ПРОДУКТА
Оценив имеющиеся на рынке решения, мы обратили внимание на Arenadata DB (версии 6), которая разрабатывается одноименной российской компанией и базируется на свободно распространяемой БД Greenplum, и решили проверить, годится ли она для использования в качестве СУБД для хранилища данных.

Различие подходов OLTP и OLAP

Прежде чем погрузиться в тонкости проведенного нами тестирования, нужно сделать небольшое отступление и заметить, что по виду нагрузки на оборудование системы, использующие СУБД, условно разделяются на OLTP и OLAP.
OLTP-подход состоит в совершении множества небольших транзакций, которые производит множество сессий (пользователей). Чем меньше условная стоимость транзакции, тем лучше. Цель оптимизации в таких условиях — уместить на оборудовании максимальное количество сессий и выполнить за определенное время максимальное число транзакций.
OLAP-подход, напротив, предполагает выполнение нескольких массивных запросов, каждый из которых обрабатывает большой объем информации. Количество одновременно работающих сессий в OLAP-системе невелико. Цель оптимизации состоит в том, чтобы получить результаты расчетов через минимальный промежуток времени. При этом допускается и даже приветствуется возможность загружать одним запросом сразу много процессоров, если это дает ускорение.
Кстати, о том, как распределяется нагрузка в OLTP- и OLAP-системах мы уже подробно рассказывали в статье «Практика оптимизации работающих решений на Oracle», поэтому останавливаться на этом вопросе подробней не будем. Скажем лишь, что RS-DataHouse является системой построения хранилищ данных, поэтому для тестирования необходимо воспроизвести именно OLAP-профиль нагрузки.

Методика тестирования

Процесс тестирования состоял из трех этапов:
  1. Создание подходящей для тестов БД.
  2. Запуск на БД нескольких запросов.
  3. Сравнение результатов запросов, а именно длительности их выполнения.

Типовые запросы в ХД имеют вид «insert … select …» — для передачи данных из одних таблиц в другие с преобразованием, а также «select …» — с массовым чтением, фильтрацией и группировками для вывода результатов. Таким образом, нам достаточно было создать два характерных запроса и сопоставить между собой результаты их выполнения.

Время выполнения запросов должно было составлять от 1 до 10 минут. При меньшем времени увеличивается погрешность сравнения (как, например, сравнить запросы длиной 0,2 сек и 0,6 сек?), при большем – увеличивается общая продолжительность тестирования. Исходя из этого условия выбирались и общий объем данных в БД, и объем данных, с которыми оперируют запросы.

Кроме того, мы сочли целесообразным сравнить скорость запросов при разных вариантах объявления таблиц (со сжатием и без, с поколоночным хранением и нет).

Оборудование

Для проведения тестирования был создан стенд из 11 серверов:
  • 1 сервер для ADCC,
  • 1 сервер для ADCM,
  • 1 сервер для главного узла — 8 CPU 2.5 GHz, 32 GB RAM,
  • 8 серверов для подчиненных узлов — 4 CPU 2.5 GHz, 32 GB RAM.
Для хранилищ данных традиционно узким местом является подсистема хранения данных (СХД), поэтому ей необходимо было уделить особое внимание. Путем копирования простого файла была измерена скорость дисковой системы:


Скорость СХД составляла ~300 Мб/сек, то есть запросы, которые читают и пишут 300 Мб, не могут выполняться быстрее одной секунды, более того, сложные запросы, агрегирующие данные и производящие на ходу вычисления с ними, должны выполняться гораздо дольше. То есть максимальный теоретический объем, который мог быть обработан запросом за 10 минут, составляет 600 сек * 300 Мб/сек = 180 000 Мб.

Экспертное мнение таково: запросы работают в 5–10 раз медленнее «скорости света» в данной физике, поэтому достаточно, чтобы запрос читал-писал порядка 20–30 Гб информации.

Сам размер данных в БД необходимо было сделать на порядок больше для проверки того, как разные СУБД работают с секционированными данными и действительно ли они эффективно читают лишь те объемы данных, к которым сделан запрос.

Тестовая схема данных

Схема данных приведена на рисунке ниже и состоит из 6 таблиц: 
  • D_DEPARTMENT – подразделения, 30 строк. 
  • D_SUBJECT – клиенты, N строк.
  • D_ACCOUNT – лицевые счета, 5*N строк.
  • F_CARRY – транзакции, 5*N/10 строк за каждый день, секционирована по дням.
  • F_EVENT – события по лицевым счетам, 2*5*N/10 строк за каждый день, секционирована по дням.
  • A_ACC_REST – агрегат остатков-оборотов по лицевым счетам, является целевой расчетной таблицей, секционирована по дням. Прогноз – 1.9*5*N/10 строк в день.

Данная схема представляет собой сильно упрощенное ядро Главной книги в RS-DataHouse, коэффициенты соотношений выбраны исходя из экспертного мнения.

Для тестирования на Arenadata таблицы D_DEPARTMENT, D_SUBJECT, D_ACCOUNT были сделаны обычными, а таблицы F_CARRY, F_EVENT, A_ACC_REST с колоночным хранением:


Все дальнейшие объемы зависят от количества клиентов N и количества дней, загруженных в схему, — T. Для данного тестирования были подобраны следующие значения этих параметров:
  • N = 2 000 000
  • T = 730 (два года)
Общее количество записей в таблицах приведено на рисунке выше.

Полученный объем базы данных — около 500 Гб.

Запросы к БД

Тест 1 выполнялся запросом:


Запрос выполнял сканирование 31 секции таблицы F_CARRY за январь 2021 года дважды, соединял результат с D_ACCOUNT и D_DEPARTMENT и записывал суммарные остатки-обороты по лицевым счетам в таблицу A_ACC_REST. С такими значениями параметров считывалось 15 Гб информации, записывалось 12 Гб, запрос работал от 3 до 10 минут в разных тестах.


Тест 2 выполнялся запросом:


Запрос выполнял сканирование 31 секции F_CARRY и 28 секций F_EVENT, объединял результаты с D_ACCOUNT и D_DEPARTMENT, преобразовал данные, группировал по подразделениям и выводил 30 строк результата. Считывалось 11 Гб информации, запрос работал от 12 секунд до 2 минут в разных тестах.

Параметры базы данных были выставлены следующим образом:

Дополнительно к основному были проведены модифицированные тесты:
  • Большие таблицы создавались с компрессией zstd 1.
  • Большие таблицы создавались не с колоночным, а с обычным хранением данных.
  • Тесты на пересозданном кластере из 2 узлов вместо 8.
  • Отдельным тестом мы попытались «положить» систему, запустив на выполнение одновременно 40 запросов номер 1.Таким образом, гарантированно загружались все 32 ядра подчиненных узлов. Arenadata выдержала испытание: загрузка на всех узлах была 100%, но все запросы выполнились и вернули результаты — каждый через 11 минут 30 секунд после начала выполнения. Во время выполнения система не «зависла», принимала новые подключения и новые запросы.

Результаты

Вариант Тест 1. Insert-select, сек Тест 2. Select, сек
Таблицы колоночные, без компрессии, 8 серверов 22814,5
Таблицы колоночные, с компрессией zstd 1, 8 серверов21014,0
Таблицы обычные, 8 серверов21813,7
Таблицы колоночные, без компрессии, 2 сервера
268
45,1
Лучший результат Oracle на прошлых тестах для сравнения, parallel=842866
Лучший результат PostgreSQL на прошлых тестах для сравнения, parallel=674286



Таким образом, тестирование показало, что:
  • Arenadata действительно демонстрирует горизонтальную масштабируемость.
  • Сравнивать результаты Arenadata и Oracle напрямую нельзя ввиду принципиально разной архитектуры стендов. Однако скорость работы дисковой подсистемы на наших тестах была примерно одинаковой.
В ходе испытаний СУБД Arenadata DB показала себя подходящим вариантом для построения OLAP-ориентированного решения. Поэтому свое новое хранилище данных компания будет строить на этом стеке технологий.



Все статьи

Комментарии



Подписка на рассылку
Сортировать
Теги:
Все теги
Выберите интересующий Вас продукт компании
Любой продукт
Сортировать по году:
2015 2017 2022