хабраиндекс
34,43
25 апреля 2011 в 10:10

Результаты сравнительного тестирования производительности CUBRID и MySQL до и после применения твердотельных накопителей (SSD) перевод

Добрый день, всем!

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

1. О тесте


В ходе следующего анализа производительности системы баз данных CUBRID и MySQL тестируются для определения их производительности в двух различных ситуациях:
  1. когда системы работают на сервере, оснащенном жестким диском;
  2. когда системы работают на сервере, оснащенном твердотельным накопителем.

1.1. Краткое описание

Принято считать, что хранение данных является основной задачей любой системы баз данных. Жесткий диск является популярным носителем, используемый предприятиями для хранения больших объемов данных. Однако известно, что производительность (ввода-вывода) жесткого диска уменьшается при рабочих нагрузках, ограниченных скоростью ввода-вывода (I/O Bound). Поэтому часто бывает необходимо найти более эффективный носитель для хранения данных. В этой статье мы представляем результаты применения и тестирования нового твердотельного накопителя (SSD), используемого в качестве основного носителя для хранения данных, который демонстрирует повышенную производительность баз данных.

1.2. Методы тестирования

Для выполнения теста каждая система баз данных (CUBRID и MySQL) была установлена на два отдельных сервера: один с жестким диском, а другой — с твердотельным накопителем. Повышение производительности в транзакциях в секунду непрерывно регистрировалось на всем протяжении эксперимента.

1.3. Среда тестового компьютера

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

Среда тестового компьютера

На компьютеры с жестким диском и твердотельным накопителем были установлены системы баз данных CUBRID и MySQL. При тестировании использовались приведенные ниже версии баз данных.
  • CUBRID 2008 R3.0
  • MySQL 5.1.47 (innoDB)

Ниже приведены конфигурации, использованные по умолчанию в системах баз данных CUBRID и MySQL. Оба сервера баз данных были настроены с буфером данных размером 4 ГБ. Остальные наскройки для тестирования использовались по умолчанию.

CUBRID Configurations (cubrid.conf)

[service]
service=server,broker,manager

[common]
data_buffer_pages=25000
sort_buffer_pages=16
log_buffer_pages=50
lock_escalation=100000
lock_timeout_in_secs=-1
deadlock_detection_interval_in_secs=1
checkpoint_interval_in_mins=720
isolation_level="TRAN_REP_CLASS_UNCOMMIT_INSTANCE"
cubrid_port_id=15097
max_clients=50
auto_restart_server=yes
replication=no
java_stored_procedure=no

checkpoint_every_npages=100000000
data_buffer_pages=262144
error_log_level=notification
communication_histogram=yes
num_LRU_chains=200
async_commit=yes
group_commit_interval_in_msecs=1000


MySQL Configurations (my.cnf)

[client]
socket = /home1/mysql/mysql/tmp/mysql.sock

[mysqld]
user = mysql
port = 3306
basedir = /home1/mysql/mysql
datadir = /home1/mysql/mysql/data
tmpdir = /home1/mysql/mysql/tmp
socket = /home1/mysql/mysql/tmp/mysql.sock

default-character-set = utf8
default_table_type = InnoDB
skip_name_resolve

back_log = 100
max_connections = 500
max_connect_errors = 999999
max_allowed_packet = 16M
max_heap_table_size = 64M
tmp_table_size = 64M
binlog_cache_size = 1M
thread_cache_size = 128

table_cache = 1024
sort_buffer_size = 8M
join_buffer_size = 8M
read_buffer_size = 2M
read_rnd_buffer_size = 16M
query_cache_size = 64M
query_cache_limit = 2M

# MyISAM options
key_buffer_size = 32M
bulk_insert_buffer_size = 64M
myisam_sort_buffer_size = 128M
myisam_max_sort_file_size = 10G
myisam_max_extra_sort_file_size = 10G
myisam_repair_threads = 1
myisam_recover
ft_min_word_len = 4

# INNODB options
innodb_buffer_pool_size = 4G # 50 ~ 70% of main memory
innodb_log_buffer_size = 8M
innodb_additional_mem_pool_size = 16M
innodb_data_file_path = ibdata1:100M:autoextend
innodb_file_per_table
innodb_log_file_size = 256M
innodb_log_files_in_group = 3
innodb_support_xa=0
innodb_thread_concurrency = 16
innodb_lock_wait_timeout = 60
innodb_flush_log_at_trx_commit = 0 # 0 for slave, 1 for master

# Loging Configuration
log-bin=mysql-bin
expire_logs_days=5
log_warnings
log_slow_queries
log_slow_admin_statements
long_query_time = 2
log_long_format

# Replication setting
server-id = 1


1.4. Сценарий тестирования

1.4.1. Схема таблиц, использованная при тестировании

Для измерения результатов производительности были созданы 40 таблиц tbl_200 ~ tbl_239 с приведенной ниже схемой.

CREATE TABLE tbl_200;

ALTER TABLE tbl_200 ADD COLUMN
	id character varying(20) NOT NULL,
	seq integer NOT NULL,
	col3 character varying(16) NOT NULL,
	col4 character varying(5) NOT NULL,
	col5 character varying(50) NOT NULL,
	col6 character varying(1000),
	col7 character varying(300) NOT NULL,
	col8 character varying(150),
	col9 timestamp NOT NULL,
	col10 smallint DEFAULT 0 NOT NULL,
	col11 timestamp NOT NULL,
	col12 character varying(15) NOT NULL,
	col13 character(1) NOT NULL,
	col14 character(1) NOT NULL,
	col15 timestamp DEFAULT timestamp '04:25:44 PM 07/30/2010' NOT NULL;

ALTER TABLE "tbl_200" ADD PRIMARY KEY("id","seq");
CREATE UNIQUE INDEX "iuk_tbl" ON "tbl_200"("id","col3","col4","col5");
CREATE INDEX "ink1_tbl" ON "tbl_200"("id","col9" DESC,"col14");


Используя приведенную выше табличную схему, необходимую для создания тестовых таблиц, машины, оборудованные жестким диском и твердотельным накопителем, прошли три типа тестов:
  • После создания базы данных для вставки 25 миллионов записей данных в 40 таблиц производительность измеряется при нагрузке «INSERT FULL» (ПОЛНАЯ ВСТАВКА) в течение 30 минут.
  • После создания базы данных для вставки 64 миллионов записей данных в 40 таблиц производительность измеряется при нагрузке «SELECT» (ВЫБОР), ограниченной возможностями ЦП (CPU Bound).
  • После создания базы данных для вставки 64 миллионов записей данных в 40 таблиц производительность измеряется при нагрузке «SELECT», ограниченной скоростью ввода-вывода (I/O Bound).

Все вышеперечисленные нагрузки создавались в 40 потоках. Одна нагрузка «ВСТАВКА» состоит из одного запроса INSERT, тогда как нагрузка «ВЫБОР» состоит из трех запросов SELECT с первичным ключом, уникальным индексом и неуникальным индексом в каждом.

2. Обзор результатов теста


2.1. Тест с рабочей нагрузкой «Вставка», ограниченной скоростью ввода-вывода

После создания базы данных с 40 таблицами, каждая из которых должна содержать приблизительно 625,000 записей данных (в общей сложности 25 миллионов), оба компьютера (с жестким диском и твердотельным накопителем) были подвергнуты тестированию производительности с нагрузкой «ПОЛНАЯ ВСТАВКА» в течение 30 минут. В следующей таблице приведены результаты тестирования производительности.

Результаты тестирования производительности при рабочей нагрузке \"Вставка\", ограниченной скоростью ввода-вывода.

На следующей диаграмме показано изменение количества транзакций в секунду.

Изменение количества транзакций в секунду

По результатам вышеописанного теста с нагрузкой «FULL INSERT» можно сделать приведенные ниже выводы.
  • Производительность системы баз данных CUBRID на компьютере с твердотельным накопителем примерно в пять раз выше, чем на компьютере с жестким диском.
  • Производительность системы баз данных MySQL на компьютере с твердотельным накопителем примерно в 2,5 раза выше, чем на компьютере с жестким диском. (Примечание. На компьютере с твердотельным накопителем MySQL не загружает ресурсы на 100%, поэтому можно дополнительно повысить производительность).

2.2. Тест с рабочей нагрузкой «SELECT», ограниченной возможностями ЦП

После создания базы данных с 40 таблицами, каждая из которых должна содержать приблизительно 1,600,000 записей данных (в общей сложности 64 миллиона), оба компьютера (с жестким диском и твердотельным накопителем) были подвергнуты тестированию производительности с нагрузкой, ограниченной возможностями ЦП, в течение 10 минут. В данной нагрузке с SELECT запросами, область поиска запроса должна быть сужена для того, чтобы полностью разместить необходимую страницу в буфере памяти и поддерживать желаемое 100% значение результативности буфера. Поскольку при этой нагрузке операции ввода-вывода не выполняются, разница в производительности между компьютерами с жестким диском и твердотельным накопителем измеряется для всех компонентов, кроме ввода-вывода. В следующей таблице приведены результаты тестирования производительности.

Результаты тестирования производительности с рабочей нагрузкой \"SELECT\", ограниченной возможностями ЦП

На следующей диаграмме показано изменение количества транзакций в секунду.

Изменение количества транзакций в секунду

При отсутствии операций ввода-вывода производительность CUBRID с использованием твердотельных носителей падает примерно на 17% по сравнению с использованием жестких дисков, а производительность MySQL возрастает примерно на 6%. Разница в производительности всех компонентов, кроме ввода-вывода, на обоих компьютерах указана выше.

2.3. Тест с рабочей нагрузкой «SELECT», ограниченной скоростью ввода-вывода

После создания базы данных с 40 таблицами, каждая из которых должна содержать приблизительно 1,600,000 записей данных (в общей сложности 64 миллиона), оба компьютера (с жестким диском и твердотельным накопителем) были подвергнуты тестированию производительности с нагрузкой, ограниченной скоростью ввода-вывода, в течение 10 минут. Чтобы не размещать необходимую страницу в буфере памяти полностью и предотвратить частую замену страниц, область поиска запроса SELECT в этой нагрузке должна быть расширена. Количество операций ввода-вывода увеличивается, так как рабочая нагрузка весьма интенсивна. В следующей таблице приведены результаты тестирования производительности ддя обеих систем.

Результаты тестирования производительности с рабочей нагрузкой \"SELECT\", ограниченной скоростью ввода-вывода

На следующей диаграмме показано изменение количества транзакций в секунду.

Изменение количества транзакций в секунду

По результатам вышеописанного теста с нагрузкой «SELECT», ограниченной скоростью ввода-вывода, можно сделать следующие выводы.
  • Производительность CUBRID (в транзакциях в секунду) на компьютере с твердотельным накопителем возрастает примерно в 4,2 раза по сравнению с компьютером с жестким диском.
  • Производительность MySQL в транзакциях в секунду на компьютере с твердотельным накопителем возрастает примерно в 2,8 раза по сравнению с компьютером с жестким диском.

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

2.4. Cистематизация результатов теста «SELECT»

В следующей таблице объединены результаты двух тестов, рассмотренных выше.

Результаты теста \"SELECT\"

На диаграмме, приведенной ниже, результаты теста, ограниченного возможностями ЦП, приведены в левом столбце, а результаты теста, ограниченного скоростью ввода-вывода — во втором. Во всех случаях уровень производительности (в транзакциях в секунду) при тестировании, ограниченном возможностями ЦП, выше, чем при тестировании, ограниченном скоростью ввода-вывода. Таким образом, операции ввода-вывода, можно считать, являются главной причиной снижения производительности систем баз данных. Наиболее интересной характеристикой, обнаруженной в ходе эксперимента, является незначительная разница в производительности CUBRID при выполнении операций, ограниченных возможностями ЦП, и операций, ограниченных скоростью ввода-вывода, на компьютере, оснащенном твердотельным накопителем. Другими словами, CUBRID, вероятно, использует все преимущества работы на компьютере с твердотельным накопителем. (Скорость произвольного доступа компьютера с твердотельным накопителем, использованного в этом тесте, считается очень высокой).

Разница производительности в транзакциях в секунду при ограниченных возможностях ЦП и при ограниченных возможностях ввода/вывода

3. Заключение


Настоящий эксперимент подтверждает, что уровни производительности систем баз данных CUBRID и MySQL повышаются на компьютерах, оснащенных твердотельным накопителем. При нагрузке, ограниченной скоростью ввода-вывода, производительность CUBRID увеличивается в 4,2 раза, а производительность MySQL — в 2,8 раза. Системы баз данных CUBRID и MySQL не настраивались на компьютерах с твердотельным накопителем для этого эксперимента. Поэтому в данном эксперименте мы не обсуждаем пригодность компьютеров с твердотельным накопителем для конкретной системы баз данных. Тем не менее, поскольку оба CUBRID и MySQL работали на компьютерах, оснащенных твердотельным накопителем, можно заключить, что возможно еще повысить производительность операций, ограниченных скоростью ввода-вывода. В будущем можно получить более интересные результаты, проводя различные тесты с такими же спецификациями оборудования и операционной системой (устанавливая другие жесткие диски и твердотельные накопители), но уже с оптимизированными настройками систем баз данных CUBRID и MySQL.

4. Разъяснительное замечание


ДАННОЕ ТЕСТИРОВАНИЕ ПРОВОДИЛОСЬ ТОЛЬКО ДЛЯ ВНУТРЕННЕГО ИСПОЛЬЗОВАНИЯ, ЧТОБЫ ОПРЕДЕЛИТЬ РАЗНИЦУ В ПРОИЗВОДИТЕЛЬНОСТИ ПРИ ИСПОЛЬЗОВАНИИ ТВЕРДОТЕЛЬНОГО НАКОПИТЕЛЯ В КАЧЕСТВЕ ОСНОВНОГО НОСИТЕЛЯ ИНФОРМАЦИИ, ПОЭТОМУ НИ ПРИ КАКИХ ОБСТОЯТЕЛЬСТВАХ КОМПАНИЯ, ПРОВОДИВШАЯ ИССЛЕДОВАНИЕ, НЕ НЕСЕТ ОТВЕТСТВЕННОСТИ ЗА ЛЮБЫЕ ПРЯМЫЕ, ОПОСРЕДОВАННЫЕ, СЛУЧАЙНЫЕ, ОСОБЫЕ, ШТРАФНЫЕ ИЛИ КОСВЕННЫЕ УБЫТКИ, ВКЛЮЧАЯ ПОТЕРЮ ДАННЫХ И ПРИБЫЛИ ИЛИ ПРЕРЫВАНИЕ ДЕЛОВОЙ ДЕЯТЕЛЬНОСТИ. РЕЗУЛЬТАТЫ ДАННОГО ТЕСТА НЕ ОЗНАЧАЮТ ПРЕВОСХОДСТВА ОДНОЙ БАЗЫ ДАННЫХ НАД ДРУГОЙ. ЧТОБЫ ТОЧНО ОПРЕДЕЛИТЬ РАЗНИЦУ В ПРОИЗВОДИТЕЛЬНОСТИ БАЗЫ ДАННЫХ ПРИ ИСПОЛЬЗОВАНИИ ЖЕСТКОГО ДИСКА И ТВЕРДОТЕЛЬНОГО НАКОПИТЕЛЯ, КОМПЬЮТЕРЫ ДОЛЖНЫ БЫТЬ ОДИНАКОВЫМИ. НЕСМОТРЯ НА ТО, ЧТО ДЛЯ ВНУТРЕННИХ ЦЕЛЕЙ ИСПОЛЬЗОВАНИЕ ОДИНАКОВЫХ КОМПЬЮТЕРОВ НЕ БЫЛО ПРИОРИТЕТНЫМ, ДЛЯ ЭТОГО ТЕСТА ИСПОЛЬЗОВАЛОСЬ ОБОРУДОВАНИЕ С ОЧЕНЬ ПОХОЖИМИ ХАРАКТЕРИСТИКАМИ (СМ. РАЗДЕЛ СРЕДА ТЕСТОВОГО КОМПЬЮТЕРА). ПОЭТОМУ РЕЗУЛЬТАТЫ ЭТОГО ТЕСТА ДОЛЖНЫ ИСПОЛЬЗОВАТЬСЯ ТОЛЬКО В ОБЩИХ ОБРАЗОВАТЕЛЬНЫХ ЦЕЛЯХ.
+2
3220
1
kadishmal 3,0

Комментарии (19)

0
mark_ablov, #
Почитал этот и ваш предыдущий топики, но так и не понял, зачем всё же использовать CUBRID, а не MySQL/PgSQL/NoSQL/…?
Какие у него преимущества?
0
kadishmal, #
Есть тому разные причины. Если начать с самого базового, то это лицензионная политика. Как Вы знаете, чтобы использовать MySQL в своих комерческих продуктах, Вы, как юридическое лицо, должны приобрести коммерческую лицензию от Oracle, нижняя планка цены которой в прошлом году поднялась до 2000 USD за стандартную версию, позоволяющую использовать в серверах с максимум 4-мя сокетами. Чтобы использовать CUBRID в комерческих целях, никому платить не надо. Все клиентские приложения могут распространяться под лицензией BSD. Более подробно об этом с примерами могу объяснить в отдельной статье.
+2
kibitzer, #
Да у них же вроде GPL (mysql), как она мешает использовать ее(СУБД) в коммерческих продуктах? Если исходники их не использовать и не менять. Хотя в любом случае, есть еще и постгре.
0
mark_ablov, #
может то что вы тоже должны будете распространять свой продукт в GPL?
Коммерческая лицензия, которая стоит 2-10 килобаксов, включает в себя еще и саппорт.
0
mark_ablov, #
а, тьфу, не так вас понял, да никто не мешает юзать MySQL, не включая её сорцев в свой продукт.
–1
kadishmal, #
Если хорошенько прочитать GPL, то там говорится, что актор проекта, где используется другой проект с открытым кодом, обязан открыть свой код под этой же лицензией. Поэтому продавать свой продукт ты не имеешь права. Для этого существует другая лицензия, например BSD (их много), которая не обязывает открывать свой код, даже если используешь проект с открытым кодом. В случае CUBRID, даже если он распространяется под GPL, все производные проекты могут распространяться под BSD, т.е. как автор, ты никому ничего не должен.
0
kadishmal, #
Одно из технических отличий, которое является одним из самых важных при выборе СУБД для решения критически важных, — это встроенная поддержка Высокой Доступности CUBRID, чего нет в MySQL. Для этого необходимо либо использовать MySQL Cluster, либо решения третьих лиц, например, DRBD или Linux Heartbeat. А CUBRID имеет свой родной компонент.

Другое отличие — CUBRID предоставляет 100% гарантию при репликации (синхронная, асинхронная, полу-синхронная), в то время как MySQL предоставляет только асинхронную и полу-синхронную репликацию, что не гарантирует согласованность данных. Были сбои, значит данные будут утеряны, и об этом мы не узнаем. А в CUBRID репликация происходит на основе транзакций, поэтому и возможна синхронная репликация.
+2
kuber, #
А где модели и маркировки дисков? SSD диск SSD диску рознь.
0
kadishmal, #
К сожалению, производителя диска, который был использован тогда, уже не помню. Масштабы результатов могут варьироваться при разных SSD, но направление результатов должно быть одинаковым, так как для обеих систем машины используются одни и те же и обе СУБД не оптимизируются под железо.
0
philpirj, #
Простите, а зачем Вы MyISAM на SSD тестируете?
Возьмите Percona Server с XtraDB, и попробуйте побить их, а не детей.
Даже если не побьёте, а будете близко — к вам потянутся люди, если у вас поддержка будет дешевле Percona'овских 100 евро в час стоить.
0
Mear, #
MySQL 5.1.47 (innoDB)

Они вроде не MyISAM тестировали
0
kadishmal, #
Да, сравнение с новым комплектом MySQL 5.1.х (innoDB) и 5.5 уже в планах. Как проведем, сразу опубликую результаты.
0
kadishmal, #
До того, как в прошлом году Oracle объявил об установлении InnoDB по-умолчанию, MyISAM использовался в большинства проектах. Поэтому тестирование на то время проходило с MyISAM. Что касается Percona Server с XtraDB, то не многие пользователи и даже компании смогут потянуть на их услуги. В дальнейшем, мне самому интересно, обязательно проведем тест, но с уже настроенным CUBRID, чтобы все честно было.
0
si14, #
Сам PerconaServer GPL'нутый и совместим с MySQL. Платный саппорт совсем не обязательное условие использования.
0
kadishmal, #
Фу, ты! Неправильно понял. Какой нафиг MyISAM! Тест был с InnoDB. MyISAM конфигурации — это все по-умолчанию. А идентичный тест с MyISAM проводили еще в 2009 с CUBRID 8.2.2, но тогда CUBRID отставал. А это результаты 2010 года. А в CUBRID 8.3.0 был изменен алгоритм индексации, что изменило результаты в пользу CUBRID. Если достану данные прошлого теста, опубликую здесь. Думаю Вам будет интересно узнать, какая разница между CUBRID 8.2.2 и 8.3.0.
0
philpirj, #
Прошу прощения, что прозевал в описании среды, но увидев 5.1 и то, что при «CREATE TABLE tbl_200;» не указан InnoDB в качестве ENGINE, я подумал, что используется MyISAM, который в 5.1, как помню, был по умолчанию.
В случае InnoDB тест заслуживает ещё более пристального внимания.
0
kadishmal, #
В CREATE TABLE не указан ENGINE, так как этот скрипт описывает общую схему таблицы, которая использовалась и в CUBRID, и в MySQL. А так правильно, в случае MySQL также уточнялся и ENGINE.
0
SonicGD, #
А почему мускул 5.1, а не 5.5? Там же неплохо производительность подняли.
0
kadishmal, #
Производительность 5.5 в основном подняли для Винды, а тест проводился на Линуксе. А вообще, в то время еще не было 5.5.

Только зарегистрированные пользователи могут оставлять комментарии.
Войдите, пожалуйста.