Открыть список
Как стать автором
Обновить

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

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

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

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

Информация

Дата основания
2006
Местоположение
Южная Корея
Сайт
www.cubrid.org
Численность
1 001–5 000 человек
Дата регистрации

Блог на Хабре