CUBRID

    imageПоследнее время, в области баз данных, внимание сконцентрировано на интенсивно развивающихся NoSQL решениях. Складывается обманчивое впечатление, что в секторе реляционных СУБД затишье: основные продукты давно известны, все ниши заняты. Казалось бы, новому игроку сюда так просто не попасть. Только если речь идёт не о проекте с пятнадцатилетней историей, не о развитой объектно-реляционной СУБД с открытым кодом, оптимизированной для использования в веб-приложениях, не о системе, которая имеет поддержку хранимых процедур, партиционирование, опции высокой доступности, репликацию и распределённые транзакции. Имя этой «тёмной лошадки» — CUBRID. И, судя по заявлениям создателей, она претендует на лавры MySQL.

    Лошадку «прятали» в Южной Корее, где она обрела популярность и начала использоваться в проектах госструктур и таких гигантов, как корпорации NHN. В конце 2008 года были открыты исходные коды, но международное лицо проект обрёл (с запуском официального сайта и публикацией на sourceforge) лишь в конце 2009.

    С MySQL эту СУБД роднит только сфера применения, они не имеют общей кодовой базы и различаются использованными подходами начиная с идей и заканчивая API. Высокая производительность для веб-приложений заложена в трёхзвенной архитектуре CUBRID.

    1. Серверная подсистема представлена как набор процессов, каждый из которых решает узкий набор задач:
      • распределение свободного пространства
      • логгирование
      • управление блокировками
      • управление транзакциями
      • обработка объектов и запросов
    2. Клиентская подсистема включает API для C, PHP, Python и Ruby, а также поддержку JDBC, ODBC и OLEDB и берёт на себя
      • парсинг и оптимизацию запросов
      • кэширование объектов и блокировок
      • управление объектами, транзакциями и триггерами
    3. Промежуточная подсистема (Broker) реализует
      • очередь задач
      • пул соединений
      • мониторинг
      • логгирование

    image

    Архитектура CUBRID ориентирована на масштабирование звеньев-брокеров, которые берут на себя задачи оптимизации запросов и пулинга соединений, разгружая сервер БД, а также повышают безопасность системы за счёт изолирования обработки запросов. Кроме того, 7 июня 2010 стартовал проект по кластеризации самой БД (к концу года запланирован выпуск стабильной версии).

    Также, данная СУБД обладает рядом уникальных возможностей, актуальных именно для веб-приложений. Приведу пример. Представьте что ваша БД используется для хранения большого количества статей. Есть пользователи, которые их просматривают. Рассмотрим общепринятую последовательностью действий при запросе статьи на просмотр:
    SELECT header, text FROM articles WHERE article_id = :requested_id;
    UPDATE articles SET read_count = read_count + 1 WHERE article_id = :requested_id;

    А теперь вспомните что случается под высокой нагрузкой. Верно, блокировки из-за апдейтов будут значительно снижать производительность. В CUBRID эта проблема решается так:
    SELECT header, text, INCR(read_count) FROM articles WHERE article_id = :requested_id;

    Блокировка при этом не создаётся. Ещё одно оригинальное расширение — директива DO, которая указывает БД не возвращать никаких результатов запроса, будь то вывод функции, выборка или сообщение об ошибке. В качестве подтверждения эффективности этих решений на сайте приведены результаты тестирования производительности. Не смотря на то, что имена конкурентов скрыты, можно легко догадаться кто есть кто.

    СУБД написана на C и C++, интерфейс администрирования — на Java, поддерживаются ОС Linux и Windows. Уже реализована поддержка SQL-92, JDBC, ODBC и OLEDB.

    CUBRID использует объектно-реляционный подход к хранению данных. Поэтому, в ней нет столбцов — есть атрибуты, нет таблиц — есть классы, нет строк — есть экземпляры классов, нет типов данных — есть домены, нет процедур — есть методы. Это позволяет вместо генерации DDL под имеющуюся структуру классов, просто взять скомпилированный jar-файл, загрузить его в БД:
    loadjava db_name MyClass.class
    и опубликовать функции
    csql> create function Sample() return string as language java name 'MyClass.Sample() return java.lang.String';
    csql> ;xrun
    Профит!
    А вот так, при использовании объектного подхода, изменяются атрибуты:
    CUBRIDResultSet rs = (CUBRIDResultSet) stmt.executeQuery("select object_name from object_name");
    rs.next();
    CUBRIDOID oid = rs.getOID(1);
    oid.addToSet("set_name", new Integer(10));
    oid.addToSequence("list_name", 1, new Integer(30));
    oid.putIntoSequence("list_name", 99, new Integer(99));
    oid.removeFromSet("set_name", new Integer(1));
    oid.removeFromSequence("list_name", 1);
    con.commit();
    rs.close();

    Для Java-разработчиков есть поддержка Eclipse через QuantumDB и драйвер для Hibernate, хотя, после примеров выше, он вряд ли пригодится.

    Кроме всех перечисленных отличий, CUBRID обладает неплохим инструментарием для администрирования, хорошей реализацией высокой доступности (failover, обновление СУБД и ОС без простоя), резервного копирования (горячие бэкапы, компрессия). Готовы и инструменты для миграции: Scriptella и Apache DdlUtils. В качестве хранилища CUBRID уже могут использовать MediaWiki, phpBB, Wordpress и несколько проектов поменьше.

    К минусам относятся: пока что, небольшое сообщество разработчиков и пользователей, отсутствие поддержки Solaris, Mac OS X и FreeBSD, а также некоторые особенности диалекта SQL, хотя документация и видео-уроки снимают почти все вопросы.

    Удивляет, что информация по этой теме в рунете практически отсутствует, кроме пары упоминаний в сообществе Ruby и перевода англоязычной статьи в википедии, где ошибочно (пруф) указано, что БД разрабатывается с 2006 года. Думаю, что этот обзор даст читателям пищу для размышлений.
    Поделиться публикацией

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

    • НЛО прилетело и опубликовало эту надпись здесь
        +5
        Заглянул на сайт этой БД, они издеваются! :-)
        Оформление сайта и логотип CUBRID как брат близнец Oracle (цвета, шрифт со срезами :)

        Месть за MySQL ;-)
          +4
          А может они просто готовятся хорошо продать ее Ораклу? :)
          –3
          А почему сравнение с mysql, а не с postgre?
            +3
            Нет смысла сравнивать узкоспециализированную СУБД, в которой жертвуют соответствием стандартам в обмен на рост производительности, применяют специальные решения и архитектуру с универсальной СУБД, которая может справиться с любой задачей.
              –1
              Тогда сравните с mongodb, я уже двух программистов знаю, которые её очень хвалят, да и в живую я вижу, что ест она мало.
            –1
            Спасибо, почитал про БД — выглядит достаточно интересно.
            Но ей пока еще расти и расти до уровня чего-либо существенного. Да, Wordpress на ней будет работать, но что-либо более существенное рано или поздно упрется в текущую ограниченность.
            Например, недостаточное для серьезных операций количество Aggregate Functions.
            Или более редкие, но критичные для моего конкретного юз-кейса, Spatial функции.

            Если же пытаться использовать CUBRID в качестве вспомогательной БД для хранения некоторой части данных, то я склоняюсь к использованию любой документ-ориентированной базы, которых развелось достаточно много
              +1
              А лицензия какая?
              • НЛО прилетело и опубликовало эту надпись здесь
                +1
                Ещё одно оригинальное расширение — директива DO, которая указывает БД не возвращать никаких результатов запроса, будь то вывод функции, выборка или сообщение об ошибке.
                А здесь так тоже умеют.
                  –1
                  ага, в настоящий момент масшабирование методом «втыкания еще одной ноды» не поддерживается? втопку! по моему вопрос масштабирования — это вопрос с которого надо начинать, при разработке нового-очередного-sql-сервера
                    0
                    У меня стойкое ощущение, что у системы с таким дурацким названием нет будущего. Если не переименуют, конечно. :)
                      +3
                      Акститесь. Вспомните nginx
                        +1
                        И точно, ведь!
                      +1
                      SELECT header, text, INCR(read_count) FROM articles WHERE article_id = :requested_id;

                      Имхо это не совсем красиво давать апдейты в селектах… Особенно наверное прелестно коммиты после селектов делать. И ведь rollback to savepoint не поможет для промежуточного отката.
                      Оракловый returning нравится гораздо больше:
                      update articles 
                      set
                        read_count=read_count+1
                      where
                        article_id = :requested_id
                      returning
                        header, test, read_count
                      into
                        v_header,v_text,v_read_count
                      

                      Или функции с автономными транзакциями.
                        0
                        Блокировка при этом не создаётся
                        И что происходит при параллельном изменении?
                        loadjava db_name MyClass.class
                        Тоже напоминает оракл :)
                          0
                          Соглашусь про нелогичность операции «чтения» которая меняет данные, это сродни геттеру, который меняет поле класса при каждом вызове. UPDATE RETURNING всё же не является эквивалентом именно из-за создания блокировки. Тем не менее, рост производительности пытается всё это оправдать :)

                          Насколько я понял коммиты для такой экзотики не нужны, равно как и роллбэки, которые просто не будут работать.

                          С параллельным изменением возможны 2 сценария — INCR и INCR в селектах, либо INCR и операция DML. В первом случае (который и предполагается использовать) всё просто — счётчик дважды увеличится, т.к. это не апдейты которые читают данные перед изменением и грязных чтений не будет. Со вторым сценарием я не экспериментировал… надеюсь лишь что селект при этом не ждёт снятия блокировки :)
                            0
                            В первом случае (который и предполагается использовать) всё просто — счётчик дважды увеличится
                            Да не так уж и просто… Параллельное изменение каким образом сделано? не приведут ли простые два селекта с incr к дедлоку или вообще к критической ошибке параллельного доступа? Лень пробовать этот Cubrid, но знать хочется :)
                              0
                              Для вознокновения дедлока необходимо как минимум наличие блокировок.

                              Попробую объяснить на примере, хотя и не претендую на полноту знаний о CUBRID. Рассмотрим выдачу номеров новым абонентам телефонной сети…

                              Первый вариант — апдейт. Предположим, что последний выданный номер написан на доске мелом и чтобы выдать новый, ответственный человек должен подойти к доске (начало блокировки), запомнить написанное число, стереть его и записать увеличенное на 1 (конец блокировки).

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

                              В обоих случаях есть блокировки на уровне алгоритма реализации, но это не то же самое что блокировки СУБД (которые значительно более ресурсоёмки): первый случай требует знания того что было на доске и вычислений, второй лишь бездумного сбрасывания карты. В первом случае несколько человек у доски устроят хаос, во втором будет лишь тяжело уследить какой номер был только что сверху (грязное чтение).

                              Думаю детали реализации можно подсмотреть — проект же открытый :)
                                0
                                Первая и большая часть совершенно излишняя да и аналогии какие-то совершенно неприменимые.
                                Допустим, что блокировок совсем нет: каким образом тогда данные будут одновременно обновляться? Для аналогии возьмите java(увидел в профиле) и синхронизацию. Не говоря уже о кешировании о котором у них заявляется.
                                А про стопку карточек это аналогия скорее сиквенсам и их параметру кэша.
                                  0
                                  Аналогии были про накладные расходы для обеспечения изменения поля в зависимости от его значения и без этой зависимости. Апдейтом можно изменить счётчик на 10%, а INCR — нет. За счёт такого ограничения удаётся избежать создания блокировок на уровне строк в БД. Как это реализовано на уровне ядра СУБД, думаю, можно узнать у хабраюзера kadishmal. Мне кажется, это вариация на тему атомиков.

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

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