NexusDB: просто еще одна база данных?

Систем управления базами данных (СУБД) в наше время стало столько, что буквально глаза разбегаются. Многие даже задают вопросы вроде "Зачем столько всяких СУБД, если раньше всем хватало на всё про всё одной Paradox?". Ответ прост: сейчас СУБД используются в ИТ-индустрии очень, очень активно, поэтому разным пользователям нужны СУБД с принципиально разными свойствами. Скажите, разве имеет смысл использовать лёгкую Firebird при разработке банковской системы, где размеры базы данных исчисляются гигабайтами, а количество подключений - тысячами? Аналогично, вряд ли есть резон запихивать Oracle в небольшую настольную программу, хранящую адреса и телефоны поставщиков продукции небольшого интернет-магазина. Поэтому, как говорится, базы всякие нужны, базы всякие важны.

NexusDB - одна из СУБД, о которых в прессе пишут не слишком часто. Тем не менее, она вовсе не аутсайдер рынка: это мощная встраиваемая в приложения клиент-серверная СУБД, активно используемая разработчиками. Тем не менее, русскоязычной информации в Интернете по ней не слишком много, поэтому я и решил рассказать о ней читателям "Компьютерных вестей".

Начну, как водится, со ссылки на официальный сайт этого программного продукта: www.nexusdb.com. На сайте масса всякой полезной информации, есть дистрибутивы различных продуктов, которые сопутствуют NexusDB. Есть там, естественно, и разные дистрибутивы самой Nexus.

Изначально NexusDB разрабатывалась для тех, кто пишет софт с помощью Delphi или C++ Builder. Но теперь, когда гегемония Borland (CodeGear) на рынке средств разработки приложений для Windows, судя по всему, накрылась медным тазом даже в СНГ, где позиции этой компании всегда были сильны, NexusDB стала доступной и для платформы .NET. Поставляется СУБД в виде исходных текстов и может компилироваться непосредственно в итоговое приложение.

Существует два варианта поставки NexusDB, отличающихся по своей функциональности: NexusDB Embedded и NexusDB Developer Edition (ранее он назывался Client/Server, или просто C/S). Различаются они тем, что Embedded Edition позволяет создавать только настольные приложения, работающие с базами данных. Это хорошее решение, например, для уже упоминавшегося справочника поставщиков магазина, если магазин небольшой. Developer Edition предназначена для разработки клиент-серверных приложений. В принципе, теоретически ничто не мешает создать подобное приложение и с помощью настольной версии NexusDB, но тогда все сетевые возможности придётся реализовывать самостоятельно - сомнительное удовольствие и вряд ли рациональное вложение времени.

Однако каковы же вообще возможности NexusDB? На этот очень важный вопрос я постараюсь дать максимально подробный и развёрнутый ответ.

Во-первых, NexusDB - это, конечно же, СУБД, которая позволяет работать с данными с помощью языка структурированных запросов - SQL. В качестве поддерживаемого стандарта языка разработчиками заявлен SQL 2003; полностью поддерживаются триггеры, а также хранимые процедуры и функции (для их программирования используется SQL/PSM). Имеется поддержка управления транзакциями, полнотекстовая индексация ("for fast data lookups", как справедливо говорят сами разработчики NexusDB). Для работы со сторонними приложениями имеется поддержка ODBC и dbExpress. В NexusDB имеется широкая поддержка работы с транзакциями, включая и вложенные транзакции. Есть ещё так называемые snapshot transactions - по словам разработчиков, они уникальны для NexusDB, и гарантируют то, что запись не будет блокировать чтение данных. Двухфазовая реализация транзакций в этой СУБД даёт основания считать механизм транзакций достаточно надёжным в плане защиты от сбоев.

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

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

Весьма интересным является для разработчиков вопрос о возможности системы, созданной с использованием NexusDB, в последующем расширяться. Разработчики говорят о поддержке сотен конкурентных подключений - для системы, работающей через локальную сеть, это в большинстве случаев вполне достаточно. Ну а если у вас такой крупный проект, что в нём необходимы тысячи или десятки тысяч подключений, что ж, в таком случае лучше не скаредничать и купить что-нибудь типа Oracle: NexusBD всё же рассчитана на иные масштабы. Размер файла, в котором хранится база данных, лимитируется файловой системой - так что не стоит для больших баз использовать FAT32. О максимально возможном количестве записей авторы СУБД ничего конкретного не говорят ("store millions and millions of records"). Это не то чтобы выглядит подозрительным - ведь большая часть современных СУБД поддерживает астрономические цифры максимального количества записей в таблице. Но, тем не менее, было бы более уважительно по отношению к потенциальным клиентам, если бы разработчики NexusDB указали конкретное значение - ведь программисты любят конкретику.

Ещё одно полезное свойство NexusDB - её возможность расти не только вширь, но и вглубь. То есть, расти может не только объём базы данных, но и возможности СУБД. Возможно это благодаря специальному API для расширения возможностей ядра СУБД с помощью плагинов. С помощью плагинов можно организовать такие вещи, как администрирование сервера или инструмент его диагностики. Но плагины - не единственная возможность дополнить NexusBD новыми возможностями. Ещё одна часть NexusDB - это под-движки (в оригинале это звучит как sub-engines). Это, фактически, отдельные составляющие движка базы данных, отвечающие за различные важные операции. Вот какие есть под-движки в NexusDB:

  • Record engine. Отвечает за логическое и физическое представление записей в базе данных;
  • Blob Engine. Отвечает за логическое и физическое представление в базе данных BLOB-полей;
  • AutoInc engine. Отвечает за автоинкрементные поля;
  • Encryption Engine. Отвечает за шифрование данных в базе данных, определяет алгоритмы, с помощью которых данные шифруются;
  • Indices Engine. Отвечает за индексацию данных в таблицах.
  • Index Engine. Отвечает за физическое представление индексов, позволяет реализовывать индексацию данных пользовательских типов;
  • Key engine. Отвечает за генерацию и сравнение ключей.

С помощью модификаций какого-то одного под-движка можно добавить необходимые для какого-то конкретного проекта возможности СУБД, оставляя все остальные части движка неизменными. Этим система под-движков кардинально отличается от системы плагинов, которая требует реализации фактически аналогов серверной части движка NexusDB.

Имеется также система для изменения стандартной реакции СУБД на те или иные события, называемая мониторами/расширителями (Monitors/Extenders). В принципе, это похоже на триггеры, но, благодаря интеграции в ядро, мониторы/расширители имеют гораздо больше возможностей.

Теперь, как мне кажется, пришло время сказать пару слов и о безопасности данных, которую готов обеспечить движок NexusDB. Три области безопасности, о которых стоит сказать: безопасность данных в файле, безопасность данных при их передаче по сети и безопасность при пользовательском доступе. Я тут уже упоминал о под-движке Encryption Engine, отвечающем за шифрование. Так вот, именно он позволяет шифровать данные в базе. Так что безопасность базы данных в руках самого разработчика приложения, работающего с нею. По умолчанию используется алгоритм Blowfish. Безопасность данных при их передаче по сети обеспечивается аналогичным образом, то есть, данные тоже шифруются. Здесь тоже можно самостоятельно шифроваться, но авторы СУБД говорят, что таким образом достигается только слабое шифрование. Для реально сильного шифрования они сейчас работают над внедрением в СУБД алгоритма StrSecII. Безопасность при доступе пользователя обеспечивается стандартной раздачей прав тем или иным пользователям базы данных. Раздавать можно права трёх видов: на администрирование, на запись и на чтение.

Помимо самой СУБД NexusDB, её разработчики предлагают ряд дополнительных инструментов, предназначение которых состоит в упрощении жизни разработчика приложений, работающих с NexusDB. Enterprise Manager - это комплексное средство для создания баз данных NexusDB. С помощью этого средства можно создавать, редактировать и удалять базы данных, таблицы в них, а также аналогичным образом можно манипулировать и с данными, содержащимися в таблицах. Помогает эта утилита и в конструировании SQL-запросов к базе, и во многом другом - в общем, очень нужная и полезная для разработчиков программа. Другая полезная вещь - вернее, даже набор полезных вещей - это Database Importers. Что это такое, думаю, вполне понятно из названия: эти утилиты помогут импортировать в базу данных формата NexusDB данные из других баз. Source Converter Assistant поможет быстрее перевести исходный текст программы с использования FlashFiler на NexusDB. FlashFiler - это другая аналогичная СУБД, разработчики которой, правда, закрылись, и потому перспектив у неё особо не видно. Есть ещё одна полезная утилита - Server User Interface. Это GUI-приложение для конечных пользователей, предоставляющее удобные средства настройки сервера.

Что ж, можно было бы ещё долго рассказывать о NexusDB, но тогда статья рискует превратиться в целую книгу. Поэтому давайте подведём итоги. В целом, NexusDB - весьма неплохая СУБД. Фактически, её характеристики среди встраиваемых движков для Delphi/C++ Builder являются едва ли не выдающимися. На сайте компании-производителя этой СУБД можно найти интересную таблицу, в которой сравниваются NexusDB и некоторые другие СУБД, такие, как DBIsam или Advantage DBS, а также даже Oracle, Microsoft SQL Server и MySQL. Естественно, результаты сравнения все сплошь в пользу NexusDB, но, тем не менее, они довольно интересны. Правда, в той бочке мёда, которой может показаться NexusDB, есть и ложка дёгтя. А именно - цена, которая составляет около 1000 долларов на одного разработчика. Наверное, именно в цене заключается секрет того, что NexusDB не так популярна, как многие другие СУБД, используемые там, где можно было бы использовать и её. Но в этом мире за всё хорошее надо платить. Так что присмотритесь к этой СУБД, подумайте - может, она и стоит того, чтобы использовать её в своих проектах?

Вадим СТАНКЕВИЧ,
dreamdrusch@tut.by

Версия для печатиВерсия для печати

Номер: 

52 за 2007 год

Рубрика: 

Software
Заметили ошибку? Выделите ее мышкой и нажмите Ctrl+Enter!

Комментарии

Страницы

Аватар пользователя PEAKTOP
Очень понравилось утверждение автора о том, что "имеет смысл использовать FireBird в банковской системе, исчисляющейся сотней гигабайт данных". Должен разочаровать автора статьи - но вот как раз использовать Firebird имеет смысл.

Когда у автора появиться опыт разработки и внедрения крупных систем (например машиностроительный завод или перерабатывающая промышленность), думаю, подобных голословных утверждений в статьях станет меньше.

Аватар пользователя Енкохнета
>>Должен разочаровать автора статьи - но вот как раз использовать Firebird имеет смысл.

Top Manager, обоснуй.

Аватар пользователя Настоящий Полковник
>>Очень понравилось утверждение автора о том, что "имеет смысл использовать FireBird в банковской системе, исчисляющейся сотней гигабайт данных". Должен разочаровать автора статьи - но вот как раз использовать Firebird имеет смысл.

Непонятно, где утверждение, а где отрицание? Так стоит использовать или нет?

Аватар пользователя Настоящий Полковник
Все ясно: товарищ IT Top Manager считает, что FB можно и нужно использовать в купных системах. Ну-ну.

Заказчики еще взашей не погнали с таким предложением? Ну, если заказчики адекватные и знающие, конечно.

Аватар пользователя Вадим Станкевич
PEAKTOP, сожалею, но Вы не совсем правы. У меня есть опыт работы с Firebird. На не очень крупной системе. На его основании я вполне могу представить работу Firebird в системе крупной.
Аватар пользователя Настоящий Полковник
>>Вадим Станкевич

Минск, 29 декабря 2007 года, 22:17

>>PEAKTOP, сожалею, но Вы не совсем правы. У меня есть опыт работы с Firebird. На не очень крупной системе. На его основании я вполне могу представить работу Firebird в системе крупной.

+5.

Аватар пользователя PEAKTOP
Факты (место действия страна Хохляндия):

Машиностроительный завод:

База: 8 ГБ, 80-90 постоянных коннектов, пик 220 коннектов, 20000 транзакций/день.

Сервер 4x2 AMD Opteron, 16 ГБ ОЗУ, SATA RAID 10 на 8 зеркал, ОС Fedora Core 4.

Проект успешно сдан заказчику 2 года назад, полет нормальный.

Начата процедура "массового внедрения" в данном сегменте предприятий. Отличие от "образцового" только в том, что пока не накопили 8 ГБ.

Об опыте других можно почитать тут: http://www.ibase.ru/devinfo/ibfbfeature.htm

Насчет "личного опыта" - я бы не стал хвастаться кривыми руками, тем более приводить это в качетсве аргумента.

Аватар пользователя Настоящий Полковник
Если в системе пару табличек, то и FB справится.

Если что-то более сложное, где используются select с несколькими join по нескольким таблицам и куча отсечек в where, да еще order by - умирает FB без разговоров. Чтобы кто ни говорил. Все везде красиво и быстро на двух табличках. ;)

Аватар пользователя Настоящий Полковник
да и в некоторых случаях заказчик не знает, что такое быстрая система. И доволен тем, что есть. Может быть его это устраивает? Кто знает? Только разработчик. ;) Который заказчику сказки рассказывает о супер-пупер системе, работающей с космической скоростью. ;););)
Аватар пользователя Вадим Станкевич
PEAKTOP, что ж, спорить не буду, говорил же, на крупных системах Firebird не наблюдал. Но, говоря откровенно, я уверен, что есть СУБД, с которыми бы Ваша система смотрелась бы ещё лучше.

Страницы