Знакомство с CUBRID — СУБД оптимизированная для Веб приложений

    Приветствую всех, дорогие Хабравчане!

    Лично мы не представляли нашу разработку пользователям Хабры, но скорее всего Вы уже читали о СУБД CUBRID в хабратопике Льва Хомича. Некоторые моменты в статье не совсем корректны, что хочу исправить в этом топике. Поэтому предлагаю познакомиться поближе и узнать более подробно, почему мы представляем CUBRID как самую оптимизированную СУБД для Веб приложений. Также буду рассказывать о тех нюансах, о которых Вы не найдете нигде (пока), даже на официальном сайте проекта http://www.cubrid.org. Таким образом и Вы узнаете многое и, надеюсь, расскажете, посоветуете или предложите нам свои идеи и мнения в комментариях. Поэтому уверен, Вы будете довольны нашему знакомству.

    Во-первых, когда началась разработка CUBRID?

    В разных источниках приводятся разные даты: 15 лет назад, либо 2006 год. Поистине СУБД продавалась и пользовалась очень большим спросом еще задолго до того, как появился MySQL, и даже сам CUBRID. Она была одной из первых с объектно-ориентированной архитектурой, которая широко используется и в наши дни в игровой и мультимедийной индустриях. СУБД стала настолько популярной, что Oracle предложил купить исходный код и лицензию на ее дальнейшее развитие и продажу за 1 миллиард американских долларов. Но разработчики отклонили предложение и вместо этого нашли спонсоров с активом в 2 миллиарда долларов. Это было еще в начале 90-х годов. Поэтому в хабратопике Льва Хомича и некоторых других источниках говорится о пятнадцатилетнем и более стаже.

    Однако официально годом начала разработки CUBRID мы, разработчики СУБД, определяем как 2006 год, когда корпорация NHN, главный игрок в поисковом рынке Южной Кореи с 74% долей, объединила в команду из 40 человек своих главных архитекторов и программистов и организовала проект CUBRID. Занимая 13-е место в мировой IT индустрии, NHN обладал достаточными человеческими и финансовыми ресурсами для успешного старта проекта. К тому времени NHN уже предоставлял более 100 Веб сервисов для пользователей Южной Кореи, Японии, Китая и Соединенных Штатов, включая множество онлайн игр, поисковых, социальных и других сервисов. Мы были уверены, что именно Веб сервисы, которые становились все более и более популярными и разнообразными во всем мире, будут определять ход развития IT индустрии. Поэтому мы поставили себе цель разработать самую оптимизированную систему управления баз данных для Веб сервисов и открыть ее код под лицензией GPL версии 2.0.

    Таким образом, компания определяет создать объектно-реляционную СУБД, которая предоставляла бы все преимущества и ООСУБД, которая так часто используется в онлайн играх и мультимедийных службах, и РСУБД, которая стала самым популярным решением для всех других отраслей. С такой целью компания приобретает лицензию на ту самую ООСУБД с 15 летним стажем, а за основу реляционной части берет уже к тому времени открытый стандарт SQL 92 года. Так было положено начало разработки СУБД CUBRID.

    Первый открытый код

    В течение двух лет мы разрабатывали CUBRID, и к октябрю 2008 года мы выпустили версию 1.0 нового СУБД, ориентированного на использование с Веб приложениями. Первый стабильный выпуск был задействован во внутренних службах самого NHN. Затем к следующему месяцу мы дорабатываем СУБД и уже публично аносируем CUBRID, как первый СУБД с открытым кодом Южной Кореи.

    Популярность CUBRID на внутреннем рынке выросла насколько быстро, что в течение года уже несколько тысяч пользователей начали разрабатывать и адаптировать разные приложения для работы с СУБД CUBRID, как LACP (Linux, Apache, CUBRID, PHP/Perl/Python) и LnCP (Linux, nginx, CUBRID, PHP/Perl/Python) стэки, Windows установщики, а также известные CMS (WordPress, phpBB, Joomla). За этот первый год CUBRID был введен в внутренние системы управления Белого Дома Кореи, Национальной налоговой службы Кореи, множества министерств и корпораций.

    Таким образом, первый год считался очень удачным. Однако в связи с тем, что большинство пользовательских разработок ограничивалось поддержкой только корейского языка, меня и многих других в команде это не устраивало. Ведь мы разрабатывали СУБД не только для пользователей Кореи, а для всего IT пространства. Поэтому ровно через год после первого выпуска в октябре 2009 года мы переносим исходный код проекта на новый ресурс Sourceforge.net, чтобы пользователи во всем мире могли следить за развитием проекта. Таким образом SF.net становится главным SVN, а основным языком разработки и документации становится английский.

    Основные возможности и характеристики

    На сегодняшний день СУБД CUBRID разрабатывается для двух основных операционных систем. Это Линукс и Windows, для которых доступны серверная часть CUBRID, все клиентские приложения и интерфейсы программирования. Для Mac OS X на данный момент доступны только клиентские приложения, с помощью которых можно полноценно работать с удаленными серверами CUBRID. Однако разработки основной серверной части CUBRID для Mac OS в планах еще нет.

    Серверная часть CUBRID разрабатывается на языке программирования C/C++ и распространяется под лицензией GPL версии 2.0 или выше. Клиентские приложения разработаны на разных языках и обычно распространяются под лицензией BSD (более подробно о лицензионной политике CUBRID расскажу в следующем блоге). Основные инструменты для администрирования базами данных CUBRID Manager, Query Browser и Migration Toolkit написаны на языке Java. А интрефейсы программирования разрабатываются на C.

    Как я уже сказал ранее, в реализации реляционной части CUBRID мы ссылаемся на открытый стандарт SQL 92 года. Многие СУБД его поддерживают, но каждая из них реализовывает его по разному. Возьмем системные таблицы, которые хранят метаданные о всех существующих или об определенной базе. Для этого в MySQL, MSSQL и некоторых других СУБД существуют отдельные системные базы, например, INFORMATION_SCHEMA, которые доступны для прямого редактирования только самой системе. Всё, в принципе, удобно за исключением того, что при переносе баз данных на другой сервер, системные базы/таблицы на новом сервере (и на старом тоже) должны быть обновлены. Обычно это происходит автоматически при восстановлении баз данных, что требуют дополнительных ресурсов, особенно если в базе сотни или тысячи таблиц. Но это можно пережить. Страшнее всего — это когда системные таблицы не обновляются вообще или доступ к ним меняется. В данном случае требуется прямое вмешательство администратора или изменение клиентских приложений.

    В CUBRID системные таблицы реализованы немного по-другому. Каждая база в CUBRID, которую Вы создаете, имеет свои системные классы-каталоги и виртуальные классы-каталоги, которые держат в себе данные об этой базе, включая все индексы, столбцы, пользователи, триггеры и т.д. Переносы баз проходят без головной боли. Лично мне такая реализация нравится больше.

    Были разговоры о том, что в CUBRID нет таблиц, столбцов и много другого, что есть в обычных реляционных СУБД. В CUBRID есть и таблицы, и столбцы, и процедуры, и все остальное. Доступ к данным в CUBRID возможен разными способами. Для доступа к таблице, можно использовать и таблицы (реляционный подход), и классы (объектный подход). Для доступа к строкам, можно использовать и строки (реляционный подход), и экземпляры классов (объектный подход). Столбцы, либо атрибуты. Процедуры или методы. Таким образом можно использовать обычный SQL (SELECT index_name FROM db_index)), чтобы извлечь, например, все имена индексов, которые используются во всей базе. Нет необходимости ссылаться на внешнюю базу. Можно также уточнить, чтобы индексы были только первичные, либо обратные или уникальные, либо только внешние ключи. Если Вы привыкли к реляционной концепции, Вы не заметите никакой разницы от любой другой РСУБД.

    В CUBRID реализован ACID (Атомарность, Согласованность, Изолированность, Долговечность), таким образом есть полная поддержка транзакций. В CUBRID можно производить разделение, репликацию, сжатие, проверку и восстановление данных. Также возможно делать горячий/онлайн бэкап, создавать обновляемые представления, триггеры, иерархические и вложенные запросы. В CUBRID нет ограничений на размеры базы данных, количество таблиц или строк, и даже на размеры определенных типов данных, как BLOB и CLOB. В нем есть курсоры, а также встроенные функции-счетчики, о которых подробно рассказал Лев. CUBRID также позволяет кэщировать и планировать запросы. Есть много способов для моментальных оптимизации запросов с помощью SQL подсказок. Одной из главных особенностей CUBRID является его собственная поддержка Высокой Доступности (High-Availability). Эта встроенная функция высокой доступности сама по себе — довольно большая тема, поэтому более подробно о ней расскажу с удовольствием в отдельном хабратопике.

    Где мы сами используем CUBRID?

    В целом, CUBRID — это полнофункциональная система управления базами данных, которая может предоставить бесперебойную работу с данными при очень высоких нагрузках. К примеру, в NHN мы используем СУБД CUBRID на серверах поисковой службы NAVER, которая принимает запросы от более, чем 17 миллионов уникальных пользователей в день. CUBRID используется в системе мониторинга результатов поиска на сайте NAVER.com и непосредственно отвечает за хранение данных о качестве результатов. Для улучшения релевантности результатов запросов и борьбы со спам-сайтами нам необходимо вести запись ключевых слов, которые используются в поиске, и ассоциировать каждую из них со всеми Веб страницами, которые уже проиндексированы поисковым сервером. Миллионы записей то вводятся, то обновляются, и конечно же, извлекаются из базы, и CUBRID справляется с этим безупречно.

    Вам, вероятней всего, интересно, насколько хорошо CUBRID справляется со сбоями в системе. Как Вы знаете, причины могут быть разные, но нам в NHN важно, чтобы доступ был девять девяток, нижний предел — шесть. Поэтому на всех серверах мы обязательно включаем опцию Высокой Доступности CUBRID. Однажды был случай, когда мастер сервер одной из служб вышел из строя, и то из-за физических неполадок. Сбой главного сервера мог полностью отключить весь сервис, но благодаря функции Высокой Доступности CUBRID, тогда роль мастер сервера была автоматически передана первичному подчиненному серверу. Это произошло настолько быстро в течение тайм-аута, установленного в системе извещения, что даже сами администраторы баз данных не заметили сбой железа, пока по плану не заглянули в логи. Это был первый раз, и пока единственный, когда активный сервер упал в производстве.

    Текущий статус

    На сегодняшний день мы разработали очень большое количество функций в CUBRID, множество из которых полностью совместимы с другими РСУБД, как MySQL или MSSQL, и в то же время есть очень много уникальных особенностей. Для удобства пользователей мы стремимся предоставить максимальную совместимость с MySQL, чтобы при переходе на CUBRID пользователи могли без труда адаптировать свои приложения. С этой целью мы запланировали несколько фаз «Совместимости с MySQL» на уровне SQL и интерфейсов программирования. Первая фаза c довольно широким пакетом MySQL совместимых функций была завершена и включена в версию CUBRID 8.3.0. Параллельно обновляются интерфейсы программирования. Остались несколько PHP функций, которые еще не полностью совместимы с mysql. В начале следующего месяца (май 2011) мы планируем выпустить новую версию CUBRID 8.4.0 со второй фазой, которая будет покрывать почти 90% SQL синтаксиса MySQL. Завершающую третью фазу мы запланировали на конец лета. Таким образом, к началу осени, надеюсь, мы загладим все разногласия между CUBRID и MySQL.

    Дополнительные нюансы, ход разработок, планы, а также другие интересные истории из жизни CUBRID расскажу в следующих топиках. Надеюсь, эта статья даст Вам много пищи для размышления. Пожалуйста, скачивайте CUBRID, поработайте в нем, и расскажите в коментариях свои впечатления, замечания, и пожелания.
    CUBRID
    20,00
    Компания
    Поделиться публикацией

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

      +19
      Звучит интересно, но слышу о CUBRID первый раз.
        +1
        Хотелось бы сравнения CUBRID с MySQL, раз уж речь зашла о БД для веб-приложений. Или может быть ссылочку подкините?
          0
          Есть несколько статей на офф. сайте www.cubrid.org/performance_results на английском языке, описывающие разницу в производительности между CUBRID, MySQL и другими СУБД при изначальных конфигурациях. Думаю, перевод смогу опубликовать на этой неделе.
          +2
          Вам, вероятней всего, интересно, насколько хорошо CUBRID справляется со сбоями в системе.

          Таким образом, к началу осени, надеюсь, мы загладим все разногласия между CUBRID и MySQL.


          Мне, скорее, интересно знать зачем она вообще нужна если есть postgre (если говорить об оосубд) или mysql (если говорить о популярных субд вообще) о_О
            0
            Зачем говорить об Ubuntu, если есть FreeBSD (если говорить о серверных системах), или Windows (если говорить о популярных ОС вообще).

            PS: nothing personal…
              +1
              Дело в том, что с моей колокольни это выглядит так: есть Ubuntu, FreeBSD, Windows… и нашему вниманию представлена MyVeryOwnFuckAllUnixOLOLOSuper OS
                0
                Наверное, здесь мы передадим привет «ОС Попова»… )

                Ну а на самом деле, это очень хорошо, что на хабре пишут о разных базах, языках и т.д., необходимо всеравно расширять свой кругозор. В свое время так же воспринимали и NoSQL-БД, «зачем если есть то-то»… А оно вон как повернулось… Поэтмоу всяко дело имеет право на жизнь. :)
                  0
                  Мне интересно, у Вас такая же реакция была, когда придумали NoSQL?
                    +1
                    Так, ладно. Меня неверно поняли.

                    Если Вы привыкли к реляционной концепции, Вы не заметите никакой разницы от любой другой РСУБД.


                    Смысл вопроса в следующем: какие очевидные преимущества/концептуальные новшества представляет CUBRID для юзеров перед уже имеющимися решениями?
                      +3
                      Вообще присоединяюсь к вопросу — на сайте в бенчмарках (ссылка выше) не нашел существенных преимуществ перед MySQL. А с появлением интерфейса, позволяющего пользовать InnoDB-таблицы как NoSQL в MySQL из коробки — я таки вообще очень серьезно сомневаюсь в необходимости что-то подобное творить. Я понимаю еще MariaDB. Но здесь выглядит как игра в «догонялки». Никаких существенных преимуществ лично я не могу узреть. Только чтобы была альтернатива? Хм…
            • НЛО прилетело и опубликовало эту надпись здесь
                0
                Спасибо за комментарий! Заголовок состоит нетолько из второй части. Я постарался описать систему, познакомить Вас с ним, как минимум, что и как, и откуда. А вторую часть, почему и как она оптимизирована, я буду рассказывать в следующих статьях. Я не прошу переходить на CUBRID сегодня, поэтому прошу терпенья. Спасибо заранее.
                  +1
                  да, было бы хорошо выделить заголовки и написать хоть какие-то цифры страждующей аудитории. вроде «на 10% быстрее работает при выборке 10000 записей по сравнению...» а так пищи для размышления немного. Судя по ссылке о производительности CUBRID больше нагружает дисковую систему по сравнению с MySQL, т.к. прирост призводительности при переходе на SSD больше. Это так?
                    +1
                    Думаю, Вы не совсем точно интерпретируете данные. Оценка производительности систем (в 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 серверов).
                    0
                    Да, конечно, интересно, но мне кажется, что никто не станет рисковать из за двухкратного прироста производительности при остальных неизвестных.
                    В конце концов есть Percona. Для экстремальщиков есть чуть ли не сотня разных движков для MySQL.
                      0
                      А что насчет интерфейса для Python?
                      0
                      шрифт в лого такой же, как у oracle $))
                        0
                        Расшифровка ACID порадовала, спасибо.

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

                        Самое читаемое