Небольшой субъективный обзор СУБД, встреченных в ОС Linux

2000 г

Небольшой субъективный обзор СУБД, встреченных в ОС Linux

Спиричев Вадим.

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

Предисловие

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

В обзоре отсутствуют объяснения, почему в качестве платформы автоматизации была выбрана ОС Linux. Это тема другой статьи. Если коротко, то Linux это Unix-like операционная система с сетевой оконной графической системой X Window. Все компоненты системы, включая исходные тексты, распространяются свободно. Здесь же перечислю те требования, которые я предъявлял к СУБД, с позиций ее применения в упомянутой системе:

реальный многопользовательский режим;
транзакционная защита от сбоев;
возможность "плотного" хранения данных. (Имеется в виду возможность хранения множества типов, например языка С, и возможность их обработки. Требование связано с объемом и составом данных. Примерный объем 50000-100000 записей лицевых счетов и 300000-500000 записей о движении денег.);
желательно, чтобы СУБД работала в режиме клиент-сервер через TCP/IP;
возможность работать с базой из процедурного языка, лучше из С или С++. Желательно иметь доступ типа SQL;
и, наконец, СУБД должна обладать достаточной "скорострельностью" (Например, задача получения баланса, т.е. сложение массива чисел (см. объем базы) на процессоре 486DX при 8 Мб и средних по скорости IDE дисках не должна занимать более 5 мин.)

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

Замечу, что предыдущий вариант системы был сделан в SCO UNIX с использованием коммерческой СУБД Raima Data Manager (RDM), известной больше под названием dbVista 3.21. И, надо сказать, RDM показала себя с лучшей стороны. Она удовлетворяла практически всем перечисленным требованиям, если не считать отсутствия режима клиент-сервер.

Кстати, загрузочная прикладная программа, собранная под управлением SCO Unix с библиотекой RDM, с успехом работала в Linux (через систему совместимости iBCS) и гораздо быстрее, чем в родном ей SCO UNIX. По некоторым данным, в Linux можно изготовить объектный модуль (в формате COFF), который линкуется с библиотекой из SCO Unix. Я не проверял, если кто знаком с этой технологией, пусть поделится. Если это так, то получается, что Linux позволяет работать с SCO-версией RDM, и при этом SCO Unix не нужен вообще.

Тому, кто знаком с RDM, должны быть понятны мои пристрастия. Среди требований ничего не сказано об интерфейсе с пользователем. Этот интерфейс логичнее, проще и стандартнее сделать другими средствами, например, на Tcl/Tk для X Window. Поэтому не обсуждаем эти вопросы.

Рассмотренные СУБД, пункты обзора и условности.

В следующем разделе приведена информация по СУБД:

Ingres
Mbase
ONYX
mSQL
Typhoon
LINCKS
Exodus

Информация представлена в следующем виде:

version: версия, которая рассматривалась;

comment: несколько общих слов;

data model: модель данных, в том числе поддерживаемые типы;

data model: поддержка режима;

client-server: поддержка режима;

access methods: методы доступа;

transaction: поддержка режима;

query lang: языки запросов, языки доступа;

documentation: наличие, объем и качество документации;

disk space: как СУБД ест disk space;

in my mind: субъективное мнение;

где я взял: источник;

В пунктах применены следующие условности и сокращения:

(+) положительное свойство.

(-) недостаток.

(пробовал :) пробовал, понравилось.

(пробовал :( пробовал, не понравилось (или не работало).

(читал :) читал, порадовался.

(читал :( читал и пробовать не стал.

Обзор СУБД

version: Postgres 4.01

comment:	Это одна из самых старых баз, адаптированных в Linux (+). Курирует разработку известный проф. Стоунбрейкер из Беркли. Одна из целей проекта - что можно выжать из реляционно-объектной модели.
data model:	Реляционная модель с возможностью наследования свойств объектов (кортежей). Данная версия поддерживает типы char[], int, long, double. Строки могут быть переменной длины. Кроме этого, поле может содержать функцию на языке QUEL. Значение поля - результат выполнения функции. Создание собственных объектов-полей и функций их обработки (читал :) (-) Версия не поддерживает unsigned полей ! :(((
multiuser:	Система многопользовательская. (+)
client-server:	Клиент-сервер через TCP/IP. (+)
access method:	Btree, Rtree Btree-доступ так и не заработал (пробовал :((( (-) это не недостаток, а просто конец всему !!! Rtree (для составных объектов) не пробовал.
transaction:	Есть транзакционная защита. (+)
query lang:	Интерпретатор языка postQUEL. Это диалект INGRES QUEL c расширениями и кое-где с усечениями, а именно, нельзя использовать агрегирующие функции в условиях поиска (читал и пробовал :(. Например, нельзя найти кортеж с мах значением из группы за один запрос. Т.е. написать retrieve (emp.all) from e in emp where e.sal = max (e.sal) and ... нельзя (-)! А по теории и в INGRES QUEL можно. К тому же функцию мах придется самому определять :(( А для double я вообще не смог этого сделать (+) Есть интерфейс из С с использованием того-же postQUEL.
documentation:	Отличная документация в формате Postscript. Объем достаточный. (+)
disk space:	На мой взгляд непомерно ест DS. Каждый кортеж снабжается здоровенным заголовком (уникальный идентификатор, дата, время и прочее :( ). От заголовка не избавиться, а порой он больше, чем данные в кортеже (-).
in my mind:	Для нашего случая Postgres явно не "тянет". Неработающий поиск по ключу, отсутствие unsigned полей и заморочки с агрегатами - это сильные недостатки. А жалко ! Возможно, для приложений попроще это хороший вариант. По всей видимости, сильная ориентация на postQUEL, приводит к обычному для клиент-сервера перекосу по скорости обработки - отдельные записи поочереди медленно, большие группы быстро.
где я взял:	На на CD-ROM Trans-Ameritech Linux Release 3 April 94.

version: INGRES v.8.9

comment:	Еще более старая СУБД, чем Postgres. Разработка начиналасьв середине 70-х тем же Майклом Стоунбрейкером. Адаптированаво многих версиях UNIX. Я не эксперементировал с данной вер-сией, ограничившись чтением документации, но работал с подобным INGRES в 80-х годах на СМ-1420 (ОС ДЕМОС - СУБД РУБИН).
data model:	Реляционная в чистом виде. Поддерживаются типы данных int, long, float, double и строки фиксированной длины. Не поддерживаются unsigned поля.
multiuser:	Система многопользовательская, но есть оговорки авторов по проблемам с этими делами, связанные с адаптацией в Linux. Мало описания по данному режиму (-).
client-server:	Похоже этого режима нет. Я не нашел упоминания о нем. INGRES это штука для работы с терминала UNIX (файл-сервер).(-)
access method:	В документации упоминаются следующие heap, hash, isam, ordered. Я не пробовал.
transaction:	Механизм транзакций есть, но похоже допотопный. (?)
query lang:	Интерпретатор QUEL. Это классический QUEL. Он не позволяет расширять его, как PostQUEL, но зато он соответствует описаниям в книгах по реляционным базам. В частности, там все ОК с агрегирующими операциями. (+) (читал :) Можно работать с базой из С. Для этого в программе пишутся обращения на QUEL, выделенные специальным образом. Затем все пропускается через препроцессор. А затем компилируется.(+) (пробовал на СМ-1420 :)
documentation:	Документации много. Хорошо описаны многие вопросы. Документация в текстовых файлах. (+)
disk space:	Ничего сказать не могу, т.к. в Linux не пробовал.
in my mind:	Если бы был механизм клиент-сервер, я бы попробовал INGRES для своей задачи. Это классическая, хорошая реляционная СУБД, хотя и несколько устаревшая. Еще бы мне не хватало unsigned полей. Данная версия существует в исходниках и ее надо собирать самому.
где я взял:	На CD The InfoMagic Linux Developer's Resource, Oct 1994. и sunsite.unc.edu:/pub/Linux/apps/databases/ Напишу еще следующее, но я там не брал: ingres-mail@idiom.com ftp pub/ingres/* from s2k-ftp.CS.Berkeley.EDU

version: MetalBase 5.0

commenet:	Это молодой развивающийся проект. Автор устал работать с коммерческими СУБД и решил сделать свою free. MBase нельзя отнести к большим СУБД. Требует установки пакета CURSES, т.к. можно делать формы с использованием этого пакета.
data model:	Модель данных реляционная. Структура базы определяется прямо из программы. По всей видимости поддерживаются все сишные типы данных. (Но я не уверен).
multiuser:	Есть многопользовательский режим, но, похоже, основанный на блокировке файлов, т.е. простенький.
client-server:	Не поддерживается (-).
access methods:	Есть поиск по ключу.
transaction:	Никаких толковых упоминаний я не нашел. Может просто искал плохо. (-)
query lang:	Доступ из программ на языке Си. Можно быстро клепать формы для редактирования и просмотра данных с использованием CURSES.
documentation:	Документация среднего объема. В текстовых файлах. Я ограничился беглым просмотром и о полноте документации судить не могу.
disk space:	Много есть не должен, судя по принципам построения.
in my mind:	Наверное есть много задач, где можно применить эту СУБД. Но отсутствие клиент-сервер механизма не поз- воляет применить ее в упомянутом проекте.
где я взял:	На CD The InfoMagic Linux Developer's Resource, Oct 1994. и sunsite.unc.edu:/pub/Linux/apps/databases/

version: ONYX 2.30

comment:	Это абсолютно не похожий ни на что инструмент. ONYX это даже не СУБД. Это 4GL-язык для работы через TCP/IP c приложениями на других реляционных СУБД. "На полную катушку" используется awk. Основное свойство это независимость от используемой СУБД и платформы (в определенных пределах, естественно...)
data model:	Данные рассматриваются как набор таблиц. Конкретика зависит от приложения и СУБД, в том числе и форматы поддерживаемых данных.
multiuser:	Зависит от СУБД.
tarnsaction:	Поддерживается механизм транзакций.
client-server:	Работа клиента с сервером происходит через TCP/IP.
access methods:	Надо разбираться :-(
query lang:	Onyx 4gl - мягко говоря, необычный язык.
documentation:	Документации мало (-) Есть FAQ на немецком :((( языке.
disk space:	Зависит от СУБД.
in my mind:	Скорее всего ONYX это очень интересный инструмент и его можно прикрутить к чему-нибудь. Я пока не знаю к чему. Я ищу СУБД.
где я взял:	На CD The InfoMagic Linux Developer's Resource, Oct 1994. и sunsite.unc.edu:/pub/Linux/apps/databases/

version: mSQL 1.0

comment:	Это, по словам авторов (буквально), "легковесная база данных для быстрого доступа к данным, не требующая много памяти". Это библиотека вызовов, реализующая поднабор SQL языка. mSQL сделали для поддержки другого проекта, в котором раньше Postgres пользовали. Но от Postgres'a отказались, не устроила скорость работы (!). Если верить документации, mSQL быстрее Postgres в 20 (!) раз. (+)
data model:	Классическая реляционная модель. Поддерживаются типы данных char[n], int, real и все... :-( Нет даже long, не говоря уже об unsigned. Это вилы !!! Если int - 32 бита, тогда где short (16) ?
multiuser:	Нигде не описано (-) :( Скорее всего не поддерживается.
client-server:	Режим поддерживается через TCP/IP. (+).
access methods:	Ключевой поиск есть. Но нельзя делать сложный ключ.
transaction:	Толково не описано. Документации катастрофически мало !
query lang:	Основные методы работы это через монитор, как в Postgres, и из языка Си. Можно работать из следующих языков ESL, Perl, Python, Tcl.
documentation:	Документация сделано красиво (PostScript), но ее мало - всего 20 страниц :-(((. Она еще более "легковесная", чем сама СУБД. (-)
disk space:	Тяжело судить... Не пробовал (т.к. много недостатков).
in my mind:	mSQL, наверняка, хорош для обучения шорошим манерам в области проектирования приложений на основе СУБД. И похож, в этом смысле, на язык Pascal. Но применить на деле практически нельзя. Много недостатков.
где я взял:	Есть на mserv@mplik.ru:

DirName: unix/database
File Name      Kbytes Description
----------------------------------------
msql-1.0.2.tgz    166 Mini-SQL database engine
msqltcl-1.0.tgz
                   33 TCL interface to MSQL database
DirName: windows/database
File Name      Kbytes Description
----------------------------------------
winmsql.README      2
winmsql.zip        80 mSQL client library.
			Winsock API available.

version: Typhoon 1.04

comment:	Typhoon - это система "срисована" с СУБД dbVista фирмы Raima. Делает ее человек по имени Thomas B. Pedersen, который живет в Дании. Крупное отличие Typhoon от dbVista в том, что модель данных не сетевая, а реляционная. Проект Typhoon находится в начале своего пути и по словам автора будет активно развиваться. В Typhoon данной версии нет многих возможностей dbVista, но есть свойства, которые выгодно отличают Typhoon.
data model:	Как я отметил выше, модель данных у Typhoon реляционная. Вместо наборов dbVista здесь используются primary и foreign ключи. На мой взгляд, это минус. Особая прелесть dbVista в ее сетевой модели данных. Поддерживаются все типы данных языка Си и кроме того, вложенные структуры, объединения и строки переменной длины.
multiuser:	Пока система однопользовательская. (-) Но автор работает над многопользовательской версией.
client-server:	Нет поддержки и неизвестно, будет ли ? (-)
access methods:	B-tree деревья, как и в dbVista.
transaction:	Пока нет (-), но работы ведутся.
query lang:	Библиотека функций для Си.
documentation:	Есть краткое описание и man на все функции библиотеки.Если этого мало, ищите документацию на dbVista, системы очень похожи...
disk space:	Думаю, что этот показатель не хуже, чем у dbVista, тем более, что не тратится место на указатели для сетевой модели. (+) (Не пробовал :-( )
in my mind:	Если в следующей версии появится многопользовательский режим, транзакционная защита и страничная подкачка (все это обещано автором), то должна получиться непло- хая система. А если еще и клиент-сервер появится, то совсем хорошо будет. А пока ждем-с...
где я взял:	На мэйл-сервере в Ижевске mailserv@mark-itt.ru каталог unix/database/: typhoon-1.04.tar.gz

version: LINCKS v.2.2

comment:	LINCKS (Linkoping Intelligent Communication of Knowledge System) - многопользовательская система для хранения и обработки сложных объектов. Система скорее предназначена для хранения сравнительно небольшого числа больших объектов, чем наоборот. Кроме того старые версии объектов сами не удаляются, а будут занимать пространство на диске пока последнее не кончится ;).
data model:	Система хранит объекты, которые могут быть различной природы. Каждый объект состоит из структурированной части, неструкту- рированной части и связей. Связи служат для передвижения по объектам и объединения в группы. Структурированная часть это традиционные данные, а несруктурированная это, например, графика, книжки, музыка и прочая мультимедия. Можно книжку "12 стульев" написать, если вы Ильф и Петров, а живете далеко друг от друга и с компьютерами.
multiuser:	режим поддерживается. (+)
client-server:	Да ! Через TCP/IP (+).
access method:	Не нашел толкового объяснения, но можно "гулять" по связям это точно !
transaction:	Похоже нет. (-)
query lang:	Можно работать из языка Си, есть библиотека. Можно через специальный базолаз для X Window со своим языком мани- пулирования. Второе неплохо описано в документации.
documentation:	Неплохая документация в Postscript. (+) Объемом ~90 страниц. Не нашел документации на Си-интерфейс.
disk space:	Ест много и жадно. В документации авторы честно признались, что не ставили задачи экономить место на диске. Система ведет версии объектов.
in my mind:	По всей видимости, есть области, где LINCKS может быть как нельзя кстати. Но для описаной задачи не годится.
где я взял:	На CD The InfoMagic Linux Developer's Resource, Oct 1994. и sunsite.unc.edu:/pub/Linux/apps/databases/

version: EXODUS Storage Manager 3.0

comment:	Это пожалуй самая интересная СУБД, которая встретилась в Linux. Предоставляет средства манипулирования объектами, которые рассматриваются как неинтерпретируемые наборы байт. Программист сам должен знать, где-что лежит. А как будет лежать, это забота программы сервера, обслуживающего дисковое пространство. Обекты могут быть практически любых размеров (не больше тома на диске, том - файл или раздел) и менять свой размер. Отличительной особенностью ESM является то, что это СУБД с распределенной обработкой. Можно задать запрос к базам, которые живут на разных машинах TCP/IP сети в одной транзакции. (+). При работе с распределенными данными используется механизм двухфазной фиксации транзакций. Мощная и гибкая система буферизации данных, как со стороны клиента, так и со стороны сервера. (+) На первой странице документации есть следующая сноска: The Exodus software was developed primary with funds pro- vided by Defense Advanced Research Projects Agency under contracts N00014-85-K-0788, N00014-88-K-0303, and DAABO7-92-C-Q508 and monitored by US Army Research Labora- tory. ~~~~~~~ Additional support was provided by Texas Instruments, Digital Equipment Corporation, and Apple Computer. Ну раз US Army руку приложила, будем ждать "Бурю в пустыне" от ESM ;-)
data model:	Ориентирована на хранения объектов. Объекты группируются в файлы-наборы. Файлы хранятся в томах. Объекты доступны через физические адреса (ObjectID). Можно связывать объекты через OID. Программа сервер обслуживает один или несколько томов на одной машине. Данные в объекте могут быть любыми.(+)
multiuser:	Система многопользовательская. (+)
client-server:	Поддерживается через TCP/IP (пробовал :)
access method:	Можно строить B-деревянные индексы над частями объектов и быстро доступаться до последних. Кроме B-деревьев есть еще кеширование. Индексы хранятся в своих файлах. Можно сканировать объекты в файле, т.е. пробежаться по объектам, как они лежат в файле, и почитать или позаписывать в объекты если надо. Это очень быстро (пробовал :) 10000 объектов обработал за 6 сек. (+)
transaction:	Не вложенные транзакции с откатом и восстановлением после сбоя. (+)
query lang:	Есть два способа работы с ESM. Первый из языка Си или С++, есть библиотека. Это очень низкий уровень, но и очень гибкий (+). Второй способ это работа на языке e++. Этот язык является примочкой к g++ и позволяет строить ОО-приложения с использованием предопределенных классов ориентированных на ESM. Если Вы знаток С++, то это для Вас.
documentation:	Неплохая документация на PostScript. Объем ~80 страниц. Многие вопросы хорошо освещены. (+)
disk space:	Пока тяжело судить об этом. ESM своеобразно хранит данные. Похоже, он оптимизирует расположение объектов на физическом уровне. Например, объекты, связанные с одним файлом, распо- ложены близко друг к другу. Кроме этого, ESM ведет список свободных слотов.
in my mind:	Если взглянуть чуть выше, то не трудно заметить, что в каждом пункте ESM одни (+)-ки. Лично я остановился на этом инструменте. Пока я не "наехал" ни на что, что противоречило бы требованиям описанным в начале обзора. Кроме того, стиль программирования на Си близок к уже освоенному на dbVista. Субъективные оценки скорости выполнения тоже многообещающие.
где я взял:	На CD The InfoMagic Linux Developer's Resource, Oct 1994. и sunsite.unc.edu:/pub/Linux/apps/databases/ и mserv@mplik.ru:

		DirName: unix/Linux/databases
		File Name      Kbytes        Description
		----------------------------------------
		eg++.tgz        3594        Persistent object-oriented
						programming language
		esm-eg++.lsm       2
		esm.INSTALL        3
		esm.tgz         1343        The Exodus distributed object
							storage manager