До того, как в прошлом году Oracle объявил об установлении InnoDB по-умолчанию, MyISAM использовался в большинства проектах. Поэтому тестирование на то время проходило с MyISAM. Что касается Percona Server с XtraDB, то не многие пользователи и даже компании смогут потянуть на их услуги. В дальнейшем, мне самому интересно, обязательно проведем тест, но с уже настроенным CUBRID, чтобы все честно было.
Если хорошенько прочитать GPL, то там говорится, что актор проекта, где используется другой проект с открытым кодом, обязан открыть свой код под этой же лицензией. Поэтому продавать свой продукт ты не имеешь права. Для этого существует другая лицензия, например BSD (их много), которая не обязывает открывать свой код, даже если используешь проект с открытым кодом. В случае CUBRID, даже если он распространяется под GPL, все производные проекты могут распространяться под BSD, т.е. как автор, ты никому ничего не должен.
Одно из технических отличий, которое является одним из самых важных при выборе СУБД для решения критически важных, — это встроенная поддержка Высокой Доступности CUBRID, чего нет в MySQL. Для этого необходимо либо использовать MySQL Cluster, либо решения третьих лиц, например, DRBD или Linux Heartbeat. А CUBRID имеет свой родной компонент.
Другое отличие — CUBRID предоставляет 100% гарантию при репликации (синхронная, асинхронная, полу-синхронная), в то время как MySQL предоставляет только асинхронную и полу-синхронную репликацию, что не гарантирует согласованность данных. Были сбои, значит данные будут утеряны, и об этом мы не узнаем. А в CUBRID репликация происходит на основе транзакций, поэтому и возможна синхронная репликация.
Есть тому разные причины. Если начать с самого базового, то это лицензионная политика. Как Вы знаете, чтобы использовать MySQL в своих комерческих продуктах, Вы, как юридическое лицо, должны приобрести коммерческую лицензию от Oracle, нижняя планка цены которой в прошлом году поднялась до 2000 USD за стандартную версию, позоволяющую использовать в серверах с максимум 4-мя сокетами. Чтобы использовать CUBRID в комерческих целях, никому платить не надо. Все клиентские приложения могут распространяться под лицензией BSD. Более подробно об этом с примерами могу объяснить в отдельной статье.
Думаю, Вы не совсем точно интерпретируете данные. Оценка производительности систем (в TPS) происходило при двух случаев: первое, когда система упирается в возможности CPU; второе, когда система упирается в возможности I/O. Иначе говоря, когда можно утилизировать максимум ЦПУ — какой прирост? И когда можно утилизировать максимум I/O операций — какой прирост?
В результате выяснилось, что при 100% утилизации ресурсов обеих систем, используя SSD, TPS выше в случае максимальной утилизации CPU, чем в случае максимальной утилизации I/O.
Это означает, что именно I/O операции у обеих систем являются причиной спада производительности, особенно у MySQL, производительность которой падает почти в 3 раза при максимальной I/O (разница в 580 TPS), в то время как у CUBRID эта цифра почти не меняется (разница в 50 TPS). В результате TPS CUBRID выше MySQL при использовании SSD дисках. Поэтому после этого теста в прошлом году мы произвели массовую замену всех хардов на SSD (где-то более 10,000 серверов).
Спасибо за комментарий! Заголовок состоит нетолько из второй части. Я постарался описать систему, познакомить Вас с ним, как минимум, что и как, и откуда. А вторую часть, почему и как она оптимизирована, я буду рассказывать в следующих статьях. Я не прошу переходить на CUBRID сегодня, поэтому прошу терпенья. Спасибо заранее.
Есть несколько статей на офф. сайте www.cubrid.org/performance_results на английском языке, описывающие разницу в производительности между CUBRID, MySQL и другими СУБД при изначальных конфигурациях. Думаю, перевод смогу опубликовать на этой неделе.
Другое отличие — CUBRID предоставляет 100% гарантию при репликации (синхронная, асинхронная, полу-синхронная), в то время как MySQL предоставляет только асинхронную и полу-синхронную репликацию, что не гарантирует согласованность данных. Были сбои, значит данные будут утеряны, и об этом мы не узнаем. А в CUBRID репликация происходит на основе транзакций, поэтому и возможна синхронная репликация.
В результате выяснилось, что при 100% утилизации ресурсов обеих систем, используя SSD, TPS выше в случае максимальной утилизации CPU, чем в случае максимальной утилизации I/O.
Это означает, что именно I/O операции у обеих систем являются причиной спада производительности, особенно у MySQL, производительность которой падает почти в 3 раза при максимальной I/O (разница в 580 TPS), в то время как у CUBRID эта цифра почти не меняется (разница в 50 TPS). В результате TPS CUBRID выше MySQL при использовании SSD дисках. Поэтому после этого теста в прошлом году мы произвели массовую замену всех хардов на SSD (где-то более 10,000 серверов).