На этом сайте используются файлы cookie. Нажимая ПРИНЯТЬ или продолжая просмотр сайта, вы разрешаете их использование. Подробнее
ПРИНЯТЬ
Сравнение Exadata X7
и X9M на разных типах нагрузки
и X9M на разных типах нагрузки
В сентябре 2021 года компания Oracle анонсировала новое поколение Exadata – Х9М.
В новом оборудовании много изменений по сравнению даже с предыдущим поколением:
-1-
На 33% больше физических ядер
(64 против 48)
(64 против 48)
-2-
На 33% больше объем оперативной памяти
(до 2Т против 1,5Т)
(до 2Т против 1,5Т)
-3-
На 28% больше дисковой ёмкости (диски 18Т против 14Т)
-4-
Новое поколение шины PCIe v.4.0 с удвоенной производительностью, по сравнению предыдущим поколением.
При сравнении технических характеристик X9M с X8M становится очевидным скачок поколений. Новая машина стоит столько же, сколько и старая, но обеспечивает на 72% больше операций ввода-вывода в секунду для OLTP-приложений. X9M также предоставляет больше ресурсов для консолидации базы данных, позволяет повысить отдачу и снизить совокупную стоимость владения. Помимо OLTP, X9M также хорошо подходит для аналитических рабочих нагрузок: X9M может обеспечить до 87% более высокую пропускную способность при сканировании данных.
Сводная таблица технических характеристик разных поколений
Поэтому, в ряде случаев, имеет смысл заменять Exadata быстрее не дожидаясь окончания амортизации оборудования, чтобы получить значительную прибавку ресурсов
При переходе от поколения к поколению стоимость Oracle Exadata не изменяется, но характеристики оборудования - растут высокими темпами: Х9М-2 превосходит Х5-2 по ёмкости дисков в 4,5 раза, по количеству ядер БД в 1,77 раза, но по цене обе машины примерно одинаковы. Поэтому целесообразно не затягивать с заменой старого оборудования на новое, а купить новую Exadata, затем перенести лицензии со старого оборудования на новое и работать на новом оборудовании в несколько раз быстрее. Обновление технических характеристик происходит так быстро, что одна новая стойка Exadata примерно равна двум стойкам поколения 5 летней давности.
Для сохранения инвестиций заказчиков в Exadata применяется Capacity-On-Demand - возможность заблокировать "лишние" ядра на серверах БД, чтобы ограничить количество лицензий на СУБД Oracle. Для Х9М-2 по-прежнему разрешённый минимум - это 14 ядер на сервер базы данных (эта планка не изменяется с поколения Х4, 2013 год). Т.е. оборудование Exadata позволяет заблокировать избыточные ядра, а лицензии на СУБД Oracle и Exadata Storage Software - перенести с предыдущего оборудования на новое оборудования. При этом, количество лицензий останется неизменным, но характеристики оборудования - сами ядра, объем оперативной памяти, объем дисков и т.д. – станут современнее. Таким образом, каждая лицензия на СУБД и на Exadata Software станут более «сильными».
Capacity-On-Demand - это запас на будущее и быстрое масштабирование: при необходимости можно очень быстро увеличить вычислительную мощность Exadata путем разблокировки ядер, не придётся ждать доставки запчастей и вызывать специалиста.
Capacity-On-Demand - это запас на будущее и быстрое масштабирование: при необходимости можно очень быстро увеличить вычислительную мощность Exadata путем разблокировки ядер, не придётся ждать доставки запчастей и вызывать специалиста.
В компании ФОРС Дистрибуция
выполнили сравнительное тестирование поколений Х9М и Х7, чтобы оценить производительность Exadata X7 и Exadata X9M на разных типах нагрузок:
выполнили сравнительное тестирование поколений Х9М и Х7, чтобы оценить производительность Exadata X7 и Exadata X9M на разных типах нагрузок:
Аналитическая нагрузка
Транзакционная нагрузка
Смешанная (аналитическая + транзакционная) нагрузка
Для сравнения были взяты две Exadata: поколение Х7 и поколение Х9М, обе - Quarter rack. В обоих случаях использовались контейнерная база версии 19.12 и Grid Infrastructure 21.3, Exadata Storage Software 21.2.3. База данных во всех тестах работала в конфигурации Real Application Cluster (два узла).
Этот эксперимент позволяет пользователям Exadata оценить выгоды от перехода на новое оборудование.
Этот эксперимент позволяет пользователям Exadata оценить выгоды от перехода на новое оборудование.
1
Аналитическая нагрузка
При помощи приложения Swingbench в базе данных была сгенерирована схема Sales History (SH) объёмом около 1Т с Range partitioning. Для генерации нагрузки использовалось приложение Swingbench в режиме аналитических запросов. Работали 10 сессий одновременно, интервал между запросами (think time) – 0, продолжительность нагрузки – 2 часа. Предварительно обе системы были откалиброваны путём прогона таких же тестов продолжительностью 30 минут с разными степенями параллелизма (16, 32, 64). На обеих системах степени параллелизма выше 32 не дали выигрыша во времени выполнения, но увеличили нагрузку на узлы баз данных и сервера хранения. Поэтому при основном тестировании степень параллелизма была ограничена 32. Нагрузка состояла исключительно из операторов SELECT. Типичные операторы – запросы с соединением (join) нескольких таблиц и различными агрегированиями.
Во всех случаях лидерами Top SQL являлись одни и те же запросы, планы запросов не изменились
Выводы по аналитической нагрузке:
Выводы по аналитической нагрузке:
На Exadata X9M аналитические запросы выполняются в среднем в 2.7 раза быстрее, чем на X7. Загрузка CPU на серверах хранения практически не изменилась.
Загрузка CPU на серверах баз данных увеличилась незначительно (поскольку серверы БД выполнили в 2 с лишним раза больше работы, поэтому небольшой рост загруженности CPU вполне оправдан)
2
Tранзакционная нагрузка (только DML)
При помощи приложения Swingbench в базе данных была сгенерирована схема объёмом около 100G. Для создания нагрузки использовалось приложение Swingbench в режиме OLTP, одновременно запускалось 300 сессий, интервал между запросами (think time) - 0. В Swingbench были активированы только операции, выполняющие модификацию данных: Customer Registration, Update Customer Details, Order Products, Process Orders. База данных работала в конфигурации Real Application Cluster.
Для транзакционных нагрузок важным показателем является время ожидания при записи в журнал транзакций (redo log file), чем быстрее выполняется запись - тем больше транзакций сможет выполнить БД. В Exadata Х9M-2 для этой цели установлен акселератор - память PMEM. Как показывают тесты, наличие PMEM даёт значительный прирост производительности для транзакционных нагрузок:
Выводы по транзакционной нагрузке:
Среднее количество транзакций в секунду на Exadata X9M в 1.5-1.8 раза больше, чем на X7.
Скорость записи в redo на Exadata X9M при использовании PMEM Log в 10 раз выше, чем на X9M без PMEM Log, и в ~30 раз выше, чем на X7
Загрузка CPU на узлах БД и серверах хранения на X9M и X7 отличаются незначительно
3
Консолидированная (OLTP+OLAP) нагрузка)
Одновременно выполнялись тесты Аналитической + Транзакционной нагрузки с теми же параметрами (300 и 10 сессий соответственно, интервал между запросами – 0)
Выводы по консолидированной нагрузке:
Exadata X9M выполняет в 1.8 раза больше транзакций в секунду по сравнению с X7
Среднее время выполнения аналитического запроса на Exadata X9M в 2.4 раза меньше, чем на X7
На Exadata X9M, как и на Exadata X7, количество транзакций в секунду составляло около 70% от результата чистой транзакционной нагрузки
На Exadata X9M, как и на Exadata X7, среднее время выполнения аналитического запроса было в 1.2-1.3 раза больше, чем при чистой аналитической нагрузке.
Выводы:
При консолидированной нагрузке (при выполнении двух нагрузок одновременно) показатели изменились меньше, чем сумма нагрузок. Это показывает, что Exadata при консолидированной нагрузке эффективно использует ресурсы узлов БД и серверов хранения, не допуская серьёзной потери производительности ни по одному виду операций.
Прокомментируем этот важный факт подробнее: зачастую транзакционная БД используется для генерации отчётности. Но с ростом объемов БД две нагрузки – транзакционная и аналитическая - начинают мешать друг другу, и владельцы БД разделяют транзакционную базу на две: оставляют небольшую транзакционную БД на одном сервере, а всю историю переносят в хранилище. Под хранилище приобретается отдельный сервер, отдельная СХД, создаётся стендбай. Разделение одной БД на две создаёт много проблем и головной боли: выделение дельты, синхронизация хранилища с транзакционной БД через db link или с помощью GoldenGate. Две базы данных требуют также двукратного хранения, т.е. фактически - дублирования данных. Т.е. затраты на поддержку двух БД значительно вырастают.
Имея Exadata, владельцам хранилищ не придётся разделять OLTP и Хранилища. Используя Exadata, вы можете использовать одну БД при любых объемах, не разделяя её на две базы. В Exadata происходит автоматическое разделение нагрузок: аналитические запросы в значительной степени выполняются в системе хранения и минимально влияют на выполнение транзакционных нагрузок, которые выполняются на серверах базы данных.
