Блог

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

    CUBRID разрабатывается самой крупной IT компанией Южной Кореи NHN, которая является главным конкурентом Google, обладая 74% местного поискового рынка, в то время как Google — 4%.

    Впервые разработка СУБД CUBRID началась в 2006 году, первый стабильный релиз которого состоялся через два года в октбре 2008 г. А в ноябре того же года CUBRID был аннонсирован как первый СУБД с открытым кодом Южной Кореи.

Последние записи


Теги

Информация

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

добавлено: 01 июн 11
понравилось:0
просмотров: 3904
комментов: 2

теги:

Автор: CUBRID RDBMS

Картинка с другого сайта.
Приветствую Вас, дорогие читатели!

Я недавно открыл этот блог и решил посвятить его теме СУБД CUBRID, и это мой первый пост. Причиной создания этого блога является то, что я очень убежден в одном: чем больше алтернативных товаров, тем лучше для потребителей. В одно время пользователи спрашивали: "Зачем nginx?" Теперь он один самых популярных веб серверов, намного быстрее, чем самый популярный Apache Web Server. Затем спрашивали, зачем NoSQL. Теперь все TOP 100 IT компаний мира зачастую используют именно этот спосов хранения данных. После чего многие перестали спрашивать, зачем CouchDB, MongoDB и т.д. В связи с конкуренцией товары становятся доступнее, больше разнообразий в функциональности, больше прямых общений с потребителями (и здесь я имею ввиду качественные алтернативы).

В связи с этим я хочу представить Вам систему управления базами данных 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 года мы переносим исходный код проекта на <a href="sourceforge.net/projects/cubrid">новый ресурс</a> 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. В начале мая этого года мы выпустили новую версию CUBRID 8.4.0 со второй фазой, которая покрывает почти 90% SQL синтаксиса MySQL (иными словами на 90% совместим с MySQL). Параллельно обновляются интерфейсы программирования. Например, для PHP остались всего лишь несколько функций, которые еще не полностью совместимы с php_mysql. Завершающую третью фазу мы запланировали на конец лета. Таким образом, к началу осени, надеюсь, мы загладим все разногласия между CUBRID и MySQL.

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

Комментарии


  • Приветсвую.
    Похоже нас на этом форуме пока только двое :)
    Как программера, работающего в сингл режиме в
    средней по величине компании, меня интересуют
    довольно приземленные вопросы :
    1. практически к любому серверу
    я могу подключится через ODBC через
    MSACCESS97 (просто на нем написано за 10 лет
    удачная клиентская морда, несовсем удачно работающая
    в следующих версиях MSACCESS, а также сделана
    портабл-версия)
    2. в MSSQL есть удобная практика перемещения
    боевой базы на домашний сервер для разработки
    одним файлом...очень удобно
    - как с этим в С. ?
    3 в MSSQL 2008 появились функции, возвращающие
    табличные значения, из которых можно делать селект,
    и их соответсвенно можно вставлять во вьюхи и сохраненки - как с этим в С.
    4 если на кабриде есть опыт программирования
    складов (ну например) то как нужно изменить
    конфигурацию, чтобы не вышибало клиента из базы,
    и какую память выделить на сервер...ну и прочее
    типа как заставить слушать различные интерфейсы
    на различных портах
    5 CUBRID vs MYSQL меня не очень интересует
    а вот vs PG - я бы с удовольствием поизучал
    все таки слоник обладает большшим кол_вом "вкусностей"
    например списочный тип данных...но вот блин
    колейшн в виндах - это просто засада...


    WBR SANGYONG

  • Добрый день, Sangyong,

    1) ODBC у меня работает с Access 2007/2010 без никаких проблем. Не могу пока понять в чем дело с Access 97, так как не вижу ни данных, ни окружения, ничего. Может Вы скинете ссылку на портабл 97. Я попытаюсь решить, затем сообшу Вам.

    2) В CUBRID есть несколько способов перемещения данных.
    - Используя утилиту "cubrid unloaddb" (3 файла: схема, индексы и сами данные)
    - Сделать полный бэкап базы (1 файл)
    - Сделать инкрементальный бэкап (+1 файл к уже имеющимся бэкап файлам)
    - Просто экспортнуть все данные (1 файл)

    В принципе, количество файлов не имеет значения в разработке.

    3) Приведите пример.

    4) В Кюбриде можно создать неограниченное количество брокера для каждого порта, как я уже Вам писал тут https://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=832878&msg=10400974. По необходимости можно настроить и память, и максимальное время тайм-аута, чтобы не вышибало клиента из базы. Для этого есть дюжина параметров как и у брокера, так и у самого Кюбрида, которые можно менять как статично, так и динамично. Посмотрите http://www.cubrid.org/manual/840/en/Parameter%20by%20Broker.

    5) С Постгресом мы еще не сравнивали. Что касается "вкусностей", то у каждой базы есть что-то, чего нет в других. Никуда не денешься. Что касается списочных типов данных, то в Кюбриде есть и множества, и мултимножества, и последовательности, и списки. Посмотрите в http://www.cubrid.org/manual/840/en/Collection%20Types-Definition%20and%20Characteristics.



Необходимо войти на сайт, чтобы оставлять комментарии