Pull to refresh
0

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

Reading time 7 min
Views 8.4K
Приветствую всех, дорогие Хабравчане!

Лично мы не представляли нашу разработку пользователям Хабры, но скорее всего Вы уже читали о СУБД 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, поработайте в нем, и расскажите в коментариях свои впечатления, замечания, и пожелания.
Tags:
Hubs:
+14
Comments 19
Comments Comments 19

Articles

Information

Website
www.cubrid.org
Registered
Founded
2006
Employees
1,001–5,000 employees
Location
Южная Корея