kadishmal Apr 25 2011 at 10:10

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

9 min

Translation

Comments 19

mark_ablov Apr 25 2011 at 10:23

Почитал этот и ваш предыдущий топики, но так и не понял, зачем всё же использовать CUBRID, а не MySQL/PgSQL/NoSQL/…?
Какие у него преимущества?

kadishmal Apr 25 2011 at 10:37

Есть тому разные причины. Если начать с самого базового, то это лицензионная политика. Как Вы знаете, чтобы использовать MySQL в своих комерческих продуктах, Вы, как юридическое лицо, должны приобрести коммерческую лицензию от Oracle, нижняя планка цены которой в прошлом году поднялась до 2000 USD за стандартную версию, позоволяющую использовать в серверах с максимум 4-мя сокетами. Чтобы использовать CUBRID в комерческих целях, никому платить не надо. Все клиентские приложения могут распространяться под лицензией BSD. Более подробно об этом с примерами могу объяснить в отдельной статье.

kibitzer Apr 25 2011 at 10:50

Да у них же вроде GPL (mysql), как она мешает использовать ее(СУБД) в коммерческих продуктах? Если исходники их не использовать и не менять. Хотя в любом случае, есть еще и постгре.

mark_ablov Apr 25 2011 at 10:58

может то что вы тоже должны будете распространять свой продукт в GPL?
Коммерческая лицензия, которая стоит 2-10 килобаксов, включает в себя еще и саппорт.

mark_ablov Apr 25 2011 at 10:59

а, тьфу, не так вас понял, да никто не мешает юзать MySQL, не включая её сорцев в свой продукт.

kadishmal Apr 25 2011 at 11:07

Если хорошенько прочитать GPL, то там говорится, что актор проекта, где используется другой проект с открытым кодом, обязан открыть свой код под этой же лицензией. Поэтому продавать свой продукт ты не имеешь права. Для этого существует другая лицензия, например BSD (их много), которая не обязывает открывать свой код, даже если используешь проект с открытым кодом. В случае CUBRID, даже если он распространяется под GPL, все производные проекты могут распространяться под BSD, т.е. как автор, ты никому ничего не должен.

kadishmal Apr 25 2011 at 10:55

Одно из технических отличий, которое является одним из самых важных при выборе СУБД для решения критически важных, — это встроенная поддержка Высокой Доступности CUBRID, чего нет в MySQL. Для этого необходимо либо использовать MySQL Cluster, либо решения третьих лиц, например, DRBD или Linux Heartbeat. А CUBRID имеет свой родной компонент.

Другое отличие — CUBRID предоставляет 100% гарантию при репликации (синхронная, асинхронная, полу-синхронная), в то время как MySQL предоставляет только асинхронную и полу-синхронную репликацию, что не гарантирует согласованность данных. Были сбои, значит данные будут утеряны, и об этом мы не узнаем. А в CUBRID репликация происходит на основе транзакций, поэтому и возможна синхронная репликация.

kuber Apr 25 2011 at 10:32

А где модели и маркировки дисков? SSD диск SSD диску рознь.

kadishmal Apr 25 2011 at 14:01

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

philpirj Apr 25 2011 at 11:51

Простите, а зачем Вы MyISAM на SSD тестируете?
Возьмите Percona Server с XtraDB, и попробуйте побить их, а не детей.
Даже если не побьёте, а будете близко — к вам потянутся люди, если у вас поддержка будет дешевле Percona'овских 100 евро в час стоить.

Mear Apr 25 2011 at 11:57

MySQL 5.1.47 (innoDB)

Они вроде не MyISAM тестировали

kadishmal Apr 25 2011 at 12:03

Да, сравнение с новым комплектом MySQL 5.1.х (innoDB) и 5.5 уже в планах. Как проведем, сразу опубликую результаты.

kadishmal Apr 25 2011 at 12:01

До того, как в прошлом году Oracle объявил об установлении InnoDB по-умолчанию, MyISAM использовался в большинства проектах. Поэтому тестирование на то время проходило с MyISAM. Что касается Percona Server с XtraDB, то не многие пользователи и даже компании смогут потянуть на их услуги. В дальнейшем, мне самому интересно, обязательно проведем тест, но с уже настроенным CUBRID, чтобы все честно было.

si14 Apr 25 2011 at 12:26

Сам PerconaServer GPL'нутый и совместим с MySQL. Платный саппорт совсем не обязательное условие использования.

kadishmal Apr 25 2011 at 12:19

Фу, ты! Неправильно понял. Какой нафиг MyISAM! Тест был с InnoDB. MyISAM конфигурации — это все по-умолчанию. А идентичный тест с MyISAM проводили еще в 2009 с CUBRID 8.2.2, но тогда CUBRID отставал. А это результаты 2010 года. А в CUBRID 8.3.0 был изменен алгоритм индексации, что изменило результаты в пользу CUBRID. Если достану данные прошлого теста, опубликую здесь. Думаю Вам будет интересно узнать, какая разница между CUBRID 8.2.2 и 8.3.0.

philpirj Apr 25 2011 at 16:45

Прошу прощения, что прозевал в описании среды, но увидев 5.1 и то, что при «CREATE TABLE tbl_200;» не указан InnoDB в качестве ENGINE, я подумал, что используется MyISAM, который в 5.1, как помню, был по умолчанию.
В случае InnoDB тест заслуживает ещё более пристального внимания.

kadishmal Apr 26 2011 at 08:20

В CREATE TABLE не указан ENGINE, так как этот скрипт описывает общую схему таблицы, которая использовалась и в CUBRID, и в MySQL. А так правильно, в случае MySQL также уточнялся и ENGINE.

SonicGD Apr 25 2011 at 12:03

А почему мускул 5.1, а не 5.5? Там же неплохо производительность подняли.

kadishmal Apr 25 2011 at 12:07

Производительность 5.5 в основном подняли для Винды, а тест проводился на Линуксе. А вообще, в то время еще не было 5.5.