Критерии выбора субд кратко
Обновлено: 04.07.2024
Очевидно, что создание информационных систем (ИС) корпоративного уровня является одной из основных задач в области информационных технологий.
При проектировании используются два основных подхода, различие между которыми определяется принципами декомпозиции сложной системы: структурный и объектно-ориентированный [1]. Сравнение этих двух подходов выходит за рамки настоящей статьи. Отметим лишь, что такие преимущества объектного подхода как возможность разбить систему на совокупность независимых сущностей – объектов и провести их строгую независимую спецификацию, простота эволюции системы за счет использования таких элементов объектного подхода как наследование и полиморфизм, возможность объектного моделирования системы, позволяющее проследить поведение реальных сущностей предметной области уже на ранних стадиях разработки, делают его все более популярным для разработчиков.
Бурное развитие технологии объектного проектирования привело к необходимости разработки стандартов и спецификаций в этой области [2]. Создание таких стандартов также безусловно положительно сказалось на привлекательности объектного подхода для разработчиков ИС.
С этой точки зрения легко сделать вывод о том, что объектная модель представления данных будет наиболее привлекательной для ИС корпоративного уровня, разработка которой ведется методами объектного проектирования. Это предопределяет выбор объектной СУБД как основного элемента системы. Сделав такой выбор разработчики получают возможность пользоваться стандартизованными средствами доступа к базам данных, основанными на стандарте ODMG93, который расширяет стандарт объектного проектирования.
Итак, первый критерий выбора СУБД продиктован выбором самого подхода к проектированию ИС в целом – если выбран объектный подход, то оправдан выбор объектной СУБД.
Такую ситуацию прекрасно осознают и основные производители реляционных СУБД. Практически каждая уважающая себя фирма обратилась лицом к объектным технологиям и продуктивно сотрудничает с разработчиками объектно-ориентированных СУБД. IBM и Oracle доработали свои СУБД (соответственно, DB2 и ORACLE) добавив объектную надстройку над реляционным ядром системы. Другой путь выбрал Informix, который приобрел серьезную объектно-реляционную СУБД Illustra и встроил ее в свою СУБД. В результате получился продукт, именующийся универсальным сервером. Другой лидер рынка СУБД – Computer Associates, поступил иначе. Он сделал ставку на чисто объектную базу Jasmine, активно пропагандируя ее достоинства. Об особенностях этой СУБД и привлекательности ее для разработчиков приложений мы уже писали [3].
По-видимому, рынок корпоративных систем в самое ближайшее время останется за гибридными объектно-реляционными СУБД, что продиктовано прежде чисто прагматическими соображениями. Однако очевидно, что системы, которые должны поддерживать сложные структуры данных, все же потребуют использовать адекватную модель базы данных, а следовательно давление со стороны чисто объектных СУБД будет нарастать.
Эта тенденция заметна по динамике роста продаж различных СУБД. Безусловно, абсолютные объемы продаж чисто объектных систем ниже, но динамика роста объемов продаж очень высока и по разным оценкам составляет от 45 до 50% в год, в то время как лучшие по этому показателю производители реляционных и объектно-реляционных СУБД достигали в разные годы уровня роста не более 35%. При этом некоторые исследователи прогнозируют темпы роста объектных систем более 50% в год. При сохранении таких темпов роста общий объем продаж объектных СУБД к 2000 году должен по разным оценкам составлять от 1,2 до 1,6 миллиарда долларов.
На ранних стадиях проектирования ИС, основанном на объектном подходе, выбор объектной СУБД позволит в полной мере реализовать упомянутые выше преимущества – возможность объектного моделирования предметной области и анализа отображения ее сущностей в проектируемые объекты и классы.
На последующих стадиях проектирования основная нагрузка ложится на программную реализацию основных элементов системы. Выбор объектного языка программирования в качестве инструмента разработки очевиден для объектного подхода к проектированию. С точки зрения программиста создание программ для объектных баз существенно отличается от написания приложений, взаимодействующих с реляционными СУБД. Объектная СУБД, как правило, поддерживает один или несколько объектно-ориентированных языков – C++, Java, Smalltalk, Object Lisp и т.п. В своих программах разработчики используют объекты и структуры, которые помещаются в базу данных. Это принципиальный момент. Подчеркнем, что программа не требует специальных блоков для общения с базой данных. Чтобы сохранить их в базе не требуется особых усилий. Создатели объектных СУБД стараются максимально облегчить жизнь разработчика программ, поэтому сохранение объектов обеспечивается прозрачным образом. Программист использует единый язык программирования для создания логики приложения, разработки интерфейса и общения с базой данных. В сочетании с визуальными средствами разработки создание прикладных программ может быть проведено с минимальными затратами средств и времени.
Таким образом, если выбран объектный язык программирования как инструмент разработки, то оправдан и выбор объектной СУБД.
Мы рассмотрели очень коротко, те преимущества, которые дают объектные СУБД по сравнению с другими классами СУБД при использовании объектного подхода к проектированию ИС. Более полный сопоставительный анализ различных классов современных СУБД приведен в статье [5]. Здесь мы приведем мифы, которые связаны с объектными СУБД: слева собраны крайние отрицательные точки зрения их противников, а справа слишком оптимистические отзывы (Таблица 1), причем те и другие основываются на недостатке информации или не правильном понимании особенностей этих систем [6]. Мы коротко поясним, в чем заключалась ошибочность этих выводов и надеемся, что дальнейший анализ объектных СУБД позволит читателю составить достаточно полное представление об их особенностях и объективно судить о возможности или целесообразности их использования в различных областях.
Далее встает вопрос о критериях сравнения и выбора конкретной объектной СУБД. Это достаточно сложный вопрос, так как существует много критериев оценки, много продуктов представлено на рынке, технология объектных СУБД отличается новизной. Если для реляционных СУБД критерии и методики проведения сопоставительных оценок известны, то для объектных они находятся на стадии активного обсуждения и многие авторы на западе подчеркивают актуальность подобных исследований. Авторам не известно ни одной достаточно полной работы по данной проблеме на русском языке. На сегодняшний момент не сложилась до конца терминология, поэтому мы сохранили в тексте некоторые английские выражения и аббревиатуры, чтобы читателю знакомому с работами на английском языке по данной проблеме легче было понять о чем идет речь.
Свое рассмотрение мы начнем с подхода к классификации объектных СУБД.
Классификация объектных СУБД
На сегодняшний день нет общепризнанной классификация объектных СУБД. Можно согласиться с теми авторами, которые в основывают свою классификацию на особенностях моделей данных, которые имеют те или иные БД. С этой точки зрения можно выделить две основные группы: чисто объектные СУБД (pure ODBMS) и СУБД, основанные на модели сохраняемых объектов (persistent storage managers).
Чисто объектные СУБД в наиболее полной мере отражают все характерные черты объектной модели данных. Все создаваемые в них классы объектов по умолчанию сохраняются в базе данных.
Как правило, такие системы поддерживают механизмы распределенных баз данных (transparent distributed database capabilities), многопользовательского доступа к БД, имеют встроенные средства разработки и администрирования.
СУБД основанные на модели сохраняемых объектов позволяют сохранять небольших объекты (менее 20 байт) и в них сохраняются не сами объекты, а их идентификаторы. Такие системы, обычно, имеют существенные ограничения на создание многопользовательских приложений и распределенных систем.
Очень часто в классификацию объектных СУБД добавляют объектно-реляционные, которые также классифицируют по различным критериям.
Однако, в данной статье мы исключим их из рассмотрения и будем рассматривать далее только два указанных класса объектных систем.
Распределение указанных классов СУБД по занимаемым сегментам рынка иллюстрируется Рис. 2.
Для выработки критериев выбора СУБД рассмотрим те области в которых производятся их оценки, а затем рассмотрим основные критерии этих оценок.
Критерии оценки объектных СУБД
Существующие критерии, по которым можно оценивать СУБД условно делятся на три большие области:
- функциональность;
- особенности разработки приложений;
- смешанные критерии.
Условность такого деления определяется тем обстоятельством, что некоторые особенности конкретной СУБД (в первую очередь те из них, которые связаны со спецификой модели данных) проявляются не только в одной области, в которой производится оценка, но и влияют на другие.
Существуют еще две области оценок СУБД:
- поддерживаемые платформы;
- производительность.
Производить оценку в этих областях возможно на этапе разработки приложений, поэтому мы их рассмотрим в следующем параграфе, а сейчас выявим критерии связанные с особенностями самих СУБД.
Критерии оценки объектных СУБД с точки зрения разработки высокоэффективных приложений
Критерии влияющие на функциональность СУБД
Проведенное исследование позволяет разбить эту область на пять групп, в которых можно с большой степени независимости анализировать характеристики СУБД и оценивать их влияние на возможные свойства разрабатываемых приложений:
- Особенности объектной модели;
- Архитектура СУБД;
- Механизмы СУБД;
- Программирование интерфейса приложений;
- Запросы к объектам.
Рассмотрим подробно каждую из указанных групп.
Результаты анализа критериев, основанных на особенностях объектной модели представлены в Таблице 2. Основные оцениваемые параметры в таблице проиллюстрированы примерами реализации в различных СУБД. При этом мы постарались раскрыть наиболее яркие особенности их реализации в коммерческих объектных СУБД, которые авторы смогли оценить на практике. При этом авторы ни здесь, ни далее не ставили перед собой целью выявить и рекомендовать читателям наиболее лучшее решение из всех существующих на сегодняшний день.
Можно отметить, что такой сопоставительный анализ принесет значительный практический результат, если при его проведении учитывать специфику разрабатываемого приложения. Вы убедитесь в этом, когда мы перейдем к рассмотрению особенностей некоторых приложений, основанных на использовании объектной СУБД VERSANT компании Versant Object Technology Corporation.
Смешанные критерии оценки
Кроме чисто технических характеристик той или иной объектной СУБД можно выделить группу параметров, характеризующих в первую очередь ее поставщика.
Учет этих параметров в перву очередь необходим, чтобы обеспечить эффективное вложение средств в новый продукт и гарантировать сделанные инвестиции.
Очевидно, также, что хорошая система поддержки продукта, развитая система обучения, полнота технической документации и некоторые другие параметры из этой области существенно повлияют на сроки разработки и надежность создаваемых приложений, упростят процесс их модернизации и т.п. Проведенный анализ позволил выявить целый ряд дополнительных критериев оценок объектных СУБД, изложение которых, однако, выходит за рамки данной статьи.
Оценка производительности приложений объектных СУБД
Выделим те параметры по которым стоит в первую очередь оценивать производительность:
- Время доступа к распределенным данным и скорость выполнения гетерогенных операций (именно эти показатели часто имеют в виду пользователи, когда говорят о хорошей масштабируемости ИС);
- Время чтения объектов;
- Время перехода по ссылке от одного объекта к другому;
- Время обновления объектов;
- Время выполнения методов;
- Время выполнения запросов.
Как уже отмечалось выше, подавляющее большинство из рассмотренных ранее характеристик объектных СУБД в той или иной степени влияют на показатели производительности приложений.
При проведении пользовательского тестирования мы рекомендуем обратить внимание на следующее:
- Схема БД должна быть правильно спроектирована и полностью отражать особенности проектируемого приложения;
- Выбрана адекватная схема управления транзакциями;
- Учтено реальное количество одновременно работающих пользователей ИС;
- Выбрана адекватная топологогия компьютерной сети;
- Проверено функционирование БД на реальных объемах информации;
- Проведен аналих производительности во времени: она не должна заметно ухудшаться при достаточно долгой эксплуатации.
Для того, чтобы читатель составил наиболее полное представление о коммерческих СУБД мы приведем ниже данных об основных представленных на рынке продуктах и их поставщиках, дадим их адреса в ИНТЕРНЕТе, а также те сферы деятельности, в которых они добились наибольшего успеха (Таблица 4).
Здесь же Вы найдете информацию о поддерживаемых платформах.
Примеры выбора объектной СУБД на практике
Результаты проведенных независимых тестирований различных СУБД и накопленный опыт разработки приложений в различных областях не позволяют сделать выводы о том, что какая-то одна объектная СУБД является явным лидером, т.е. в полной мере удовлетворяет всем из указанных выше критериев. У каждой из них есть свои особенности, которые могут оказаться решающими с точки зрения возможности создания высокоэффективного приложения в данной конкретной области. Так на примере СУБД VERSANT можно проследить какие критерии оказались решающими для выбора этой СУБД (результаты анализа приведены в Таблице 10). Необходимо также отметить, что при выборе СУБД (в частности VERSANT) практически все разработчики приложений заявляли о том, что они использовали те, критерии, которые мы отнесли к группе смешанных критериев, т.е. вопросы зрелости и финансовой стабильности поставщика СУБД безусловно учитывались при отборе кандидатов.
Приведенные в Таблице 5 сведения наглядно показывают, что рассмортенные в настоящей статье критерии действительно оказываются решающими при выборе СУБД для создания высокоэффективных приложений в различных областях. При этом, задействованы критерии различных уровней рассмотрения: от наиболее общих, связанных с выбором объектного подхода для проектирования и моделирования КИС до частных, связанных с особенностями реализации тех или иных механизмов СУБД (уровень блокировок, особенности обработки транзакций и т.д.).
Выбор наиболее значимых критериев в первую очередь определяется спецификой решаемой задачи, однако при этом во многом оказываются важными и некоторые субъективные факторы, как например, поддерживает ли СУБД именно тот алгоритмический язык на котором привыкла работать данная команда разработчиков или нет, сложно ли перенести уже наработанное ПО в новую среду и т.д.
Производители объектных СУБД стараются максимально учесть эти субъективные факторы для чего предусматривается поддержка сразу нескольких объектных языков и языка SQL, а также таких технологий как ActiveX и WebLink, встраиваются конверторы форматов основных реляционных БД, предлагается различная технология шлюзования и т.д. И все же, на наш взгляд, ключевыми аспектами, по которым следует оценивать преимущества той или иной СУБД являются производительность, масштабируемость, переносимость и время разработки приложений.
Методика выбора объектной СУБД
В заключении хотелось бы предложить методику выбора объектной СУБД, основанную на рассмотренных выше критериях.
Мы предполагаем, что для российского рынка, как в прочем и для западного, будет более важно уделить большее внимание все же техническим аспектам проблемы, а экономические и иные критерии рассматривать как ограничения при выборе той или иной СУБД.
Основные шаги направленные на выбор объектной СУБД нам представляются следующими:
Выбор системы управления баз данных (СУБД) представляет собой сложную
многопараметрическую задачу и является одним из важных этапов при разработке
приложений баз данных. Выбранный программный продукт должен удовлетворять как
текущим, так и будущим потребностям предприятия, при этом следует учитывать
финансовые затраты на приобретение необходимого оборудования, самой системы,
разработку необходимого программного обеспечения на ее основе, а также обучение
персонала. Кроме того, необходимо убедиться, что новая СУБД способна принести
предприятию реальные выгоды.
В данной статье по результатам анализа доступных источников, например 5,
делается попытка сформулировать требования или, иными словами, критерии при
выборе СУБД, приводится классификация требований/критериев. Очевидно, наиболее
простой подход при выборе СУБД основан на оценке того, в какой мере существующие
системы удовлетворяют основным требованиям создаваемого проекта информационной
системы. Более сложным и дорогостоящим вариантом является создание
испытательного проекта на основе нескольких СУБД и последующий выбор наиболее
подходящего из кандидатов. Но и в этом случае необходимо ограничивать круг
возможных систем, опираясь на некие критерии отбора. Вообще говоря, перечень
требований к СУБД, используемых при анализе той или иной информационной системы,
может изменяться в зависимости от поставленных целей. Тем не менее можно
выделить несколько групп критериев:
* Моделирование данных
* Особенности архитектуры и функциональные возможности
* Контроль работы системы
* Особенности разработки приложений
* Производительность
* Надежность
* Требования к рабочей среде
* Смешанные критерии
Рассмотрим каждую из этих групп в отдельности.
* Используемая модель данных. Существует множество моделей данных;
самые распространенные — иерархическая, сетевая, реляционная,
объектно-реляционная и объектная. Вопрос об использовании той или иной модели
должен решаться на начальном этапе проектирования информационной системы.
* Триггеры и хранимые процедуры. Триггер — программа базы данных,
вызываемая всякий раз при вставке, изменении или удалении строки таблицы.
Триггеры обеспечивают проверку любых изменений на корректность, прежде чем эти
изменения будут приняты. Хранимая процедура – программа, которая хранится на
сервере и может вызываться клиентом. Поскольку хранимые процедуры выполняются
непосредственно на сервере базы данных, обеспечивается более высокое
быстродействие, нежели при выполнении тех же операций средствами клиента БД. В
различных программных продуктах для реализации триггеров и хранимых процедур
используются различные инструменты.
* Средства поиска. Некоторые современные системы имеют встроенные
дополнительные средства контекстного поиска.
* Предусмотренные типы данных. Здесь следует учесть два фактически
независимых критерия: базовые или основные типы данных, заложенные в систему,
и наличие возможности расширения типов. В то время как отклонения базовых
наборов типов данных у современных систем от некоего стандартного, обычно,
невелики, механизмы расширения типов данных в системах того или иного
производителя существенно различаются.
* Реализация языка запросов. Все современные системы совместимы со
стандартным языком доступа к данным sql-92, однако многие из них реализуют те
или иные расширения данного стандарта.
Особенности архитектуры и функциональные возможности.
* Мобильность. Мобильность – это независимость системы от среды, в
которой она работает. Средой в данном случае является как аппаратура, так и
программное обеспечение (операционная система).
* Масштабируемость. При выборе СУБД необходимо учитывать, сможет ли
данная система соответствовать росту информационной системы, причем рост может
проявляться в увеличении числа пользователей, объема хранимых данных и объеме
обрабатываемой информации.
* Распределенность. Основной причиной применения информационных
систем на основе баз данных является стремление объединить взгляды на всю
информацию организации. Самый простой и надежный подход — централизация
хранения и обработки данных на одном сервере. К сожалению, это не всегда
возможно и приходится применять распределенные базы данных. Различные системы
имеют разные возможности управления распределенными базами данных.
* Сетевые возможности. Многие системы позволяют использовать широкий
диапазон сетевых протоколов и служб для работы и администрирования.
Контроль работы системы
* Контроль использования памяти компьютера. Система может иметь
возможность управления использованием как оперативной памяти, так и дискового
пространства. Во втором случае это может выражаться, например, в сжатии баз
данных, или удалении избыточных файлов.
* Автонастройка. Многие современные системы включают в себя
возможности самоконфигурирования, которые, как правило, опираются на
результаты работы сервисов самодиагностики производительности. Данная
возможность позволяет выявить слабые места конфигурации системы и
автоматически настроить ее на максимальную производительность.
Особенности разработки приложений.
* Многие производители СУБД выпускают также средства разработки приложений
для своих систем. Как правило, эти средства позволяют наилучшим образом
реализовать все возможности сервера, поэтому при анализе СУБД стоит
рассмотреть также и возможности средств разработки приложений.
* Средства проектирования. Некоторые системы имеют средства
автоматического проектирования, как баз данных, так и прикладных программ.
Средства проектирования различных производителей могут существенно
различаться.
* Многоязыковая поддержка. Поддержка большого количества национальных
языков расширяет область применения системы и приложений, построенных на ее
основе.
* Возможности разработки web-приложений. При разработкеразличных
приложений зачастую возникает необходимость использовать возможности среды
internet. Средства разработки некоторых производителей имеют большой набор
инструментов для построения приложений под web.
* Поддерживаемые языки программирования. Широкий спектр используемых
языков программирования повышает доступность системы для разработчиков, а
также может существенно повлиять на быстродействие и функциональность
создаваемых приложений.
* Рейтинг tpc (transactions per cent). Для тестирования
производительности применяются различные средства, и существует множество
тестовых рейтингов. Одним из самых популярных и объективных является
tpc-анализ производительности систем. Фактически tpc анализ рассматривает
композицию СУБД и аппаратуры, на которой эта СУБД работает. Показатель tpc –
это отношение количества запросов обрабатываемых за некий промежуток времени к
стоимости всей системы.
* Возможности параллельной архитектуры. Для обеспечения параллельной
обработки данных существует, как минимум, два подхода: распараллеливание
обработки последовательности запросов на несколько процессоров, либо
использование нескольких компьютеров-клиентов, работающих с одной БД, которые
объединяют в так называемый параллельный сервер.
* Возможности оптимизирования запросов. При использовании
непроцедурных языков запросов их выполнение может быть неоптимальным. Поэтому
необходимо произвести процесс оптимизации запросов, т.е. выбрать такой способ
выполнения, когда по начальному представлению запроса путем его синтаксических
и семантических преобразований вырабатывается процедурный план выполнения
запроса, наиболее оптимальный при существующих в базе данных управляющих
структурах.
Понятие надежности системы имеет много смыслов – это и сохранность информации
независящая от любых сбоев, и безотказность работы системы в любых условиях, и
обеспечение защиты данных от несанкционированного доступа.
* Восстановление после сбоев. При возникновении программных или
аппаратных сбоев целостность, да и работоспособность всей системы может быть
нарушена. От того, как эффективно спланирован механизм восстановления после
сбоев, зависит жизнеспособность системы.
* Резервное копирование. В результате аппаратного сбоя может быть
частично поврежден или выведен из строя носитель информации и тогда
восстановление данных невозможно, если не было предусмотрено резервное
копирование базы данных, или ее части. Резервное копирование спасает и в
ситуациях, когда происходит логический сбой системы, например при ошибочном
удалении таблиц. Существует множество механизмов резервирования данных
(хранение одной или более копий всей базы данных, хранение копии ее части,
копирование логической структуры и т.д.). Зачастую в систему закладывается
возможность использования нескольких таких механизмов.
* Откат изменений. При выполнении транзакции применяется простое
правило – либо транзакция выполняется полностью, либо не выполняется вообще.
Это означает, что в случае сбоев, все результаты недоведенных до конца
транзакций должны быть аннулированы. Механизм отката может иметь различное
быстродействие и эффективность.
* Многоуровневая система защиты. Информационная система организации
почти всегда включает в себя секретную информацию, поэтому для предотвращения
несанкционированного доступа используется служба идентификации пользователей.
Уровень защиты может быть различным. Кроме непосредственной идентификации
пользователей при входе в систему может использоваться также механизм
шифрования данных при передаче по линиям связи
Требования к рабочей среде.
* Поддерживаемые аппаратные платформы.
* Минимальные требования к оборудованию.
* Максимальный размер адресуемой памяти. Поскольку почти все
современные системы используют свою файловую систему, немаловажным фактором
является то, какой максимальный объем физической памяти они могут
использовать.
* Операционные системы, под управлением которых способна работать
СУБД.
* Качество и полнота документации. К сожалению, не все системы имеют
полную и подробную документацию.
* Локализованность. Возможность использования национальных языков не
во всех системах реализована полностью.
* Модель формирования стоимости. Как правило, производители СУБД
используют определенные модели формирования стоимости. Например, стоимость
одного и того же продукта может существенно изменяться в зависимости от того,
сколько пользователей будет с ним работать.
* Стабильность производителя.
* Распространенность СУБД.
Даже если просто отмечать насколько хороши или плохи выделенные параметры в
случае каждой конкретной СУБД, то сравнение уже двух различных систем является
трудоемкой задачей. Тем не менее, четкий и глубокий сравнительный анализ на
основании вышеперечисленных критериев в любом случае поможет рационально выбрать
подходящую систему для конкретного проекта, и затраченные усилия не будут
напрасными. Перечень критериев поможет осознать масштабность задачи и выполнить
ее адекватную постановку.
Следует отметить, что по существующей практике решение об использовании той
или иной СУБД принимает один человек – обычно, руководитель предприятия, а он
может опираться отнюдь не на технические критерии. Здесь свою роль могут сыграть
такие, с технической точки зрения, незначительные факторы как рекламная
раскрутка компании-производителя СУБД, использование конкретных систем на других
предприятиях, стоимость. При этом последний фактор может трактоваться в двух
противоположных смыслах в зависимости от финансового состояния и политики
предприятия. С одной стороны, это может быть принцип, – чем дороже, тем лучше. С другой стороны – культивирование почти бесплатного использования продукта,
вплоть до “взлома” его лицензионной защиты. Очевидно, последний подход чреват
коллизиями и не может привести к успеху в долгосрочной работе.
Заметил, что когда спрашиваешь кого-нибудь, особенно на собеседовании, какие типы СУБД существуют, то первое что вспоминают многие – это реляционные базы данных, и NoSQL, а вот про разновидности часто забывают или не могут сформулировать их отличие. Поэтому начнем с простого перечисления наиболее используемых.
Тем, кому не хочется долго читать, может сразу перейти на итоговую таблицу .
Нужно обязательно сделать ремарку, что некоторые крупные производители, имеют в своем арсенале несколько типов СУБД, как в виде отдельных продуктов, так и в виде внутренней реализации. Например, у Oracle на самом деле чего только нет, начиная с классической реляционной СУБД, продолжая с отдельным продуктом Oracle NoSQL Database, который может использоваться и как документная, и как колоночная, и как ключ-значение. Отдельное решение от того же Oracle, Autonomous Data Warehouse – это уже специализированное решение для хранилищ данных. Еще один отдельный продукт от Oracle – Oracle Graph Server для работы с графами, и еще много другого. Этому можно посвятить отдельную серию статей.
Реляционные СУБД
Начнем по порядку, классические, реляционные СУБД чаще всего используются для построения решений OLTP (Online Transaction Processing). В таких решениях СУБД работает с небольшими по размерам транзакциями, но идущими большим потоком, и при этом от системы требуется минимальное время отклика, а так же возможность, при определенных условиях, отменить любые изменения выполняемых в рамках транзакции. Если вы строите систему, в рамках которой требуется хранить значительное количество сущностей (таблиц), с различными типами связей между ними (один-к-одному, один-к-многим, многие-ко-многим), то это скорее всего про реляционные СУБД.
Наиболее известные СУБД такого типа - Oracle, Microsoft SQL, PostgreSQL, MySQL.
Когда выбирать реляционную СУБД
Один из основных признаков, который говорит о том что нужно выбирать реляционную СУБД – это высокая нормализация данных. Дополнительными признаками будет необходимость обработки большого кол-ва коротких транзакций, с большей долей операций на вставку
Когда не выбирать реляционную СУБД
Если предполагается хранить не структурируемые данные, или наоборот очень простые структуры типа ключ-значение, то лучше посмотреть в сторону документных СУБД и специализированных СУБД типа ключ-значение соответственно.
Так же один из признаков, что имеет смысл подумать не о реляционных СУБД, это такой факт как необходимость часто обновлять значения в одних и тех же строках. Обычно это обходится "дорого" в реляционных СУБД, и нужно применять "продвинутую магию" что бы делать это корректно.
СУБД типа ключ-значение
Наверное один из самых простых типов СУБД. В упрощенном виде, это некая таблица с уникальным ключом и собственно связанным с ним значением, в котором может быть что угодно. Чаще всего такие СУБД используют для кэширования, т.к. они очень быстро работают, а это и не сложно, когда есть уникальный ключ, и запрос возвращает только одно значение. У некоторых представителей данных СУБД есть возможность работать полностью в памяти, а так же есть возможность задавать срок жизни записи, после истечения которого, записи будут автоматически удаляться.
Наиболее известные СУБД такого типа - Redis и Memcached.
Когда выбирать СУБД ключ-значение
Когда не выбирать СУБД ключ-значение
Если вы предполагаете хранить в базе данных много сущностей (таблиц), а у сущностей будут сложные структуры с разными типами данных. Так же, если вы предполагаете делать из этой таблицы сложные запросы которые возвращают множества строк.
Документные СУБД
Документные или документно-ориентированные СУБД - это одна из наиболее популярных разновидностей NoSQL СУБД, где основной единицей логической модели данных является документ - структурированный текст, с определенным синтаксисом.
Иногда встречаются мнения что модель данных в документных БД похожа на модель данных в объектно-ориентированных базах данных. В этом есть доля правды, единственная реальная разница между ними заключается в том, что базы данных документов только сохраняют состояние, но не поведение.
Так же, само название "документо-ориентированная" подчас вводит в заблуждение, и мне встречались коллеги, которые считали, что это база для систем документооборота. Нет, это не так.
Интересно, что документные СУБД развиваются достаточно активно, и сейчас некоторые из них, в том числе, поддерживают проверку схемы.
Известными представителями таких СУБД являются CouchDB, MongoDB, Amazon DocumentDB.
Когда выбирать документную СУБД
Если нужно хранить объекты в одной сущности, но с разной структурой. Если нужно хранит структуры, включая объекты, списки и словари, особенно в формате близкому к JSON.
На самом деле область применения документных СУБД очень широкая. Их можно использовать как компактную базу данных для отдельно взятого микро-сервиса, так и для вполне масштабных решений, в качестве хранилища состояний чего-либо.
Когда не выбирать документную СУБД
Не самое лучшее решение для реализации транзакционная модели, и точно не лучший вариант для формирования отчетности.
Графовые СУБД
Графовые СУБД - специфичный тип, предназначены для работы с графами, с их узлами, свойствами, и произвольными отношениями между узлами.
Очень простой пример, это организация связей в различного типа социальных сетях, где нужно хранить связи между пользователями (узлами) по разным критериям (родственные связи, коллеги, общие интересы).
Известные представители этого типа субд - Neo4j, Amazon Neptune, InfiniteGraph, InfoGrid.
Когда выбирать графовые СУБД
Точно стоит обратить внимание на графовые СУБД, если строите какое-то подобие социальной сети, или реализуете систему оценок и рекомендаций. Ну и во всех случаях когда вы хорошо понимаете что такое графы, и для чего это нужно.
Когда не выбирать графовые СУБД
Практически во всех остальных случаях, кроме указанных выше, лучше воздержаться от использования графовых СУБД.
Колоночные СУБД
Колоночные СУБД очень похожи на реляционные. Они так же состоят из строк, которые имеют атрибуты, а строки группируются в таблицах. Различия в логических моделях несущественные, а вот на уровне физического хранения данных различия значительные.
В реляционных СУБД данные хранятся "построчно", это означает что для считывания значения определенной колонки, придется прочитать практически всю строку, как минимум от первой до нужной колонки. В колоночной СУБД данные хранятся "поколоночно", т.е. колонка - это как отдельная таблица. Соответственно чтение будет происходить из конкретного столбца сразу. На практике это реально работает очень быстро (проверено мной на нескольких реализованных хранилищах данных).
Основные преимущества колоночных СУБД – эффективное выполнения сложных аналитических запросов на больших объемах, и легкое, практически мгновенное, изменение структуры таблиц с данными, плюс существенная компрессия и сжатие, которое позволяет значительно экономить место.
Яркие представители колоночных СУБД - Sybase IQ (ныне SAP IQ), Vertica, ClickHouse, Google BigTable, InfoBright, Cassandra.
Когда выбирать колоночные СУБД
Один из весомых аргументов за использование именно колоночной СУБД - это если вы хотите построить хранилище данных, и планируете делать выборки со сложными аналитическими вычислениями. Косвенный признак, который так же может сигнализировать о том, что имеет смысл, хотя бы посмотреть в сторону колоночных СУБД - это если количество строк, из которых делаются выборки, превышает сотни миллионов.
Когда не выбирать колоночные СУБД
Учитывая специфику колоночных СУБД, будет не эффективно ее использовать, если выборки достаточно простые, параметры выборки статичны, и если преобладают выборки по ключевым значениям. Так же, если количество строк в таблице, из которой делается выборка, меньше сотен миллионов строк, то скорее всего не будет большого преимущества, по сравнению с реляционной СУБД.
Нужно так же иметь ввиду, что в колоночных СУБД могут быть и другие ограничения. Например, может отсутствовать поддержка транзакций, а язык запросов может отличаться от классического SQL, и прочее.
Итоги
Важное замечание – не пытайтесь сразу все задачи решить в рамках одной СУБД. Это более чем нормально иметь несколько разных типов СУБД. Так же, не пытайтесь сразу определиться с производителем СУБД, или связать свою жизнь с одним конкретным брендом.
При выборе типа СУБД следует, прежде всего, исходить из типа решаемых задач, типов обрабатываемых данных, перспектив роста и масштабирования.
Обращайте так же внимание на популярность и наличие широкого круга разработчиков и средств разработки – это даст вам возможность, при необходимости, найти ответ на возникший вопрос быстро.
В данной статье я намеренно не делаю акцент на выбор между облачными и on-premise решениями - эта тема одной из следующих статей.
Итак, в таблице представленной ниже, кратко собрано то, что описано выше в статье.
Тип СУБД
Когда выбирать
Примеры популярных СУБД
Нужна транзакционность; высокая нормализация; большая доля операций на вставку
Oracle, MySQL, Microsoft SQL Server, PostgreSQL
Для хранения объектов в одной сущности, но с разной структурой; хранение структур на основе JSON
CouchDB, MongoDB, Amazon DocumentDB
Задачи подобные социальным сетям; системы оценок и рекомендаций
Neo4j, Amazon Neptune, InfiniteGraph, InfoGrid
Хранилища данных; выборки со сложными аналитическими вычислениями; количество строк в таблице превышает сотни миллионов
Vertica, ClickHouse, Google BigTable, Sybase \ SAP IQ, InfoBright, Cassandra
Надеюсь данная статья оказалась полезной.
В следующих статьях посмотрим на выбор между облачными и on-premise СУБД, платными и бесплатными, и многое другое.
Значительная часть программного обеспечения — будь то ПО для банков, страховых организаций, фондов, денежного рынка, платежных сервисов — разрабатывается на основе базы данных.
Но многие разработчики испытывают трудности при выборе подходящей БД: иногда лучший выбор действительно не очевиден. Если реляционные и нереляционные базы данных сразу приходят на ум, то о системах управления базами данных (СУБД) часто забывают или не знают разницу между ними.
Восполним этот пробел и простыми словами расскажем, какие решения существуют на рынке СУБД, из каких продуктов стоит выбирать и как сделать правильный выбор в соответствии с решаемыми задачами.
Вот список наиболее часто используемых СУБД:
В конце статьи приведена резюмирующая таблица с кратким описанием того, в каких случаях подходит конкретный тип СУБД и какие популярные решения существуют. Так что самые нетерпеливые могут перейти прямо к таблице.
Отметим, что у ряда крупных поставщиков имеется по нескольку типов СУБД — в виде отдельных продуктов или внутренних реализаций.
Типы СУБД. Как выбрать правильный?
Реляционная СУБД
Это классическая система, которая чаще используется для создания OLTP-решений (обработка транзакций в реальном времени), когда СУБД работает с большим количеством маленьких транзакций. Системе требуется короткое время отклика и возможность отменять любые изменения, сделанные во время транзакции при определенных условиях.
Реляционная СУБД подойдет для создания системы, предназначенной для хранения значительного числа сущностей — таблиц — с различными типами отношений между ними (один к одному, один ко многим, многие ко многим).
Самые известные реляционные СУБД:
- Oracle;
- Microsoft SQL;
- PostgreSQL;
- MySQL;
- IBM DB2.
Когда следует выбирать реляционную базу данных?
Во-первых (1), при высокой нормализации данных. А во-вторых (2), при обработке большого количества коротких транзакций, среди которых немалый процент транзакций с вставкой.
Когда не следует выбирать реляционную СУБД?
Графовая СУБД
Это особый тип СУБД для работы с графами, их узлами и свойствами, а также произвольными отношениями между узлами.
Простой пример — создание приложений типа соцсетей, где нужно хранить соединения между пользователями (узлами) в соответствии с критериями: общие интересы, коллеги, родственники.
Самые известные графовые СУБД:
- Neo4j;
- Amazon Neptune;
- InfiniteGraph;
- InfoGrid.
Когда следует выбирать графовую базу данных?
1) При создании соцсети или реализации рейтинговой и рекомендательной системы и 2) при глубоком понимании графов и их назначения.
Когда не следует выбирать графовую базу данных?
Почти во всех остальных случаях.
Документная СУБД
Документная или документоориентированная СУБД — это одна из самых популярных разновидностей нереляционных СУБД. В качестве базовой единицы логической модели данных у нее структурированный текст со специфическим синтаксисом (документ).
Считается, что модели данных документных и объектно-ориентированных БД аналогичны. Это так, хотя разница все же есть: документные БД не хранят поведение объектов, а только их состояние. Документные СУБД активно развиваются — некоторые даже поддерживают проверку схемы.
Самые известные документные СУБД:
- CouchDB;
- MongoDB;
- Amazon DocumentDB.
Когда следует выбирать документную БД?
У документной СУБД широкий диапазон применения: от 1) компактной БД для одного микросервиса до 2) крупномасштабных решений в качестве хранилища состояния.
Лучше хранить объекты в одной сущности, но с разными структурами. Кстати, очень полезны они и 3) для хранения структур (включая объекты, списки и словари), особенно в JSON-подобном формате.
Когда не следует выбирать документную СУБД?
Документная система не подходит для реализации модели транзакций и, конечно, это не лучшее решение для формирования отчетов.
Столбцовая СУБД
Столбцовая СУБД очень непохожа на реляционную: хотя так же состоит из сгруппированных в таблицы строк с атрибутами и по логической модели мало чем от нее отличается — на уровне физического хранилища имеет существенные различия.
Реляционная СУБД хранит данные построчно. То есть для считывания значения конкретного столбца приходится считывать почти всю строку — от первого до этого столбца.
Столбцовая СУБД хранит данные по столбцам. То есть столбец предстает в виде отдельной таблицы. А считывание выполняется прямо из конкретного столбца. На самом деле работает очень быстро — протестировано на нескольких реализованных хранилищах данных.
Преимущества столбцовой СУБД:
- эффективно выполняет сложные аналитические запросы для большого объема данных;
- простое и почти мгновенное реструктурирование таблиц с данными;
- существенное сжатие, которое экономит много места.
Самые известные столбцовые СУБД:
- Sybase IQ (SAP IQ);
- Vertica;
- ClickHouse;
- Google BigQuery;
- InfoBright;
- Apache Druid.
Когда следует выбирать столбцовую БД?
1) При создании хранилища данных и осуществлении выборки со сложными аналитическими вычислениями. 2) Когда количество запрашиваемых строк превышает сотни миллионов.
Когда не следует выбирать столбцовую СУБД?
1) Когда количество строк в таблице, из которой делаются запросы, меньше сотен миллионов. Здесь у столбцовой СУБД перед реляционной преимуществ будет немного.
2) Когда запросы достаточно простые и со статичными параметрами. В этом случае — учитывая специфику системы — столбцовая СУБД будет неэффективна.
К тому же у столбцовой СУБД есть и другие ограничения. Например, язык запросов может отличаться от классического SQL или отсутствует поддержка транзакций.
Это одна из простейших СУБД, что-то вроде таблицы с уникальным ключом и связанным значением, в котором может быть что угодно. Такие СУБД чаще всего используются для кеширования, потому что они быстры — ведь есть уникальный ключ и запрос возвращает только одно значение.
Когда 1) в БД хранится много сущностей (таблиц), имеющих сложные структуры с разными типами данных. Когда 2) надо выполнять сложные запросы, возвращающие много строк.
СУБД временных рядов
Эта СУБД оптимизирована для хранения данных с метками времени или данных временных рядов. Данные временных рядов содержат измерения или события, которые отслеживаются, собираются или объединяются за определенный период времени.
Это данные с датчиков отслеживания движения, метрики JVM из приложений на Java, данные о рыночной торговле, сетевые данные, ответы от API, время безотказной работы процесса и т. д.
Данные хранятся с метками времени — это ключевая особенность — и индексируются и записываются так, чтобы данные этого временного ряда запрашивались намного быстрее, чем при использовании в классической реляционной БД.
Самые известные СУБД временных рядов:
Когда следует выбирать СУБД временных рядов?
Основная область применения таких СУБД — мониторинг, обработка телеметрии и финансовые системы.
Когда не следует выбирать СУБД временных рядов?
Воздержитесь от использования такой СУБД в задачах, не связанных с временными рядами и метками времени.
Объектно-ориентированная СУБД
Эта СУБД предназначена для хранения и обработки объектов. Как и в ООП (объектно-ориентированном программировании), у этих объектов в СУБД есть свойства и методы. И они тоже реализуют инкапсуляцию и полиморфизм.
Главная цель применения объектно-ориентированной СУБД — облегчить жизнь разработчикам, использующим модель объектного программирования. Им не придется преобразовывать объекты в таблицы и строки со связями и обратно.
Самые известные объектно-ориентированные СУБД:
Когда следует выбирать объектно-ориентированную СУБД?
Вообще-то не доводилось видеть много успешных реализаций с такими СУБД. Объектно-ориентированные базы данных обычно рекомендуется использовать при 1) высокопроизводительных манипуляциях с объектами, имеющими сложную структуру.
В то же время разработка 2) предполагает применение объектно-ориентированных языков программирования. Объектно-ориентированные БД распространены в системах реального времени, архитектуре и инженерии для 3D-моделирования, телекоммуникациях и научных продуктах, молекулярной науке и астрономии.
Когда не следует выбирать объектно-ориентированную СУБД?
1) При использовании классического языка SQL, 2) когда не применяется ООП или 3) при переходе на другую БД. И 4) при отсутствии глубокого понимания ООП. Тогда стоит выбрать документную СУБД.
Поисковая СУБД
Этот тип СУБД используется для осуществления полнотекстового поиска. А также поиска по различным данным, например из других БД, электронной почты, RSS-канала, текста, JSON, XML, CSV и даже PDF и документам MS Office.
Поисковая СУБД имеет собственные оптимизированные подходы к индексированию данных, в том числе использование так называемых инвертированных и фасетных индексов для поиска почти в реальном времени.
Различные СУБД этого типа применяют разные языки запросов.
Самые известные поисковые СУБД:
Когда следует выбирать поисковую СУБД?
Идеальные примеры — подходящие для быстрого полнотекстового поиска в различных источниках данных системы сбора и поиска по журналам структурированных, полуструктурированных и неструктурированных данных.
Когда не следует выбирать поисковую СУБД?
При поиске по ограниченному числу полей структурированных данных.
СУПБД (система управления пространственными базами данных)
Этот тип СУБД оптимизирован для работы с объектами, определенными в геометрическом пространстве — как простыми (точки, кривые, многоугольники), так и сложными (3D-объекты, топологическое покрытие, линейные сети).
СУПБД имеет набор специальных функций для обработки создания, преобразования, измерения (расстояние, площадь, объем), вычисления (пересечение/контакт) и выбора на основе определенных критериев. И содержит специальные индексы, оптимизирующие обработку объектов, и особый стандартизированный язык SQL/MM.
Самые известные СУПБД:
Когда следует выбирать СУПБД?
При создании ГИС-решений — не только для хранения, но и для работы с геометрическими объектами на уровне СУПБД.
Когда не следует выбирать СУПБД?
Для хранения геометрических объектов в качестве координат.
Заключение
Определиться с выбором СУБД бывает нелегко, ведь их так много! Надеемся, вы немного прояснили для себя этот вопрос и теперь легко выберите подходящую.
Хотите создать сложное решение? Тогда понадобится несколько типов СУБД. И не торопитесь с выбором поставщиков СУБД: обычно это тема второстепенная.
Выбирайте тип СУБД на основе следующих трех факторов:
- тип решаемых задач;
- типы обрабатываемых данных;
- перспективы роста и масштабирование.
Обратите внимание на популярные СУБД — такой выбор гарантирует наличие большого разнообразия инструментов разработки и единомышленников, которые помогут быстро найти решение возникающих вопросов.
Oracle RDBMS (она же Oracle Database) на первом месте среди СУБД. Система популярна у разработчиков, проста в использовании, у нее понятная документация, поддержка длинных наименований, JSON, улучшенный тег списка и Oracle Cloud.
Особенности
- Обрабатывает большие данные.
- Поддерживает SQL, к нему можно получить доступ из реляционных БД Oracle.
- Oracle NoSQL Database с Java/C API для чтения и записи данных.
2. MySQL
MySQL работает на Linux, Windows, OSX, FreeBSD и Solaris. Можно начать работать с бесплатным сервером, а затем перейти на коммерческую версию. Лицензия GPL с открытым исходным кодом позволяет модифицировать ПО MySQL.
Эта система управления базами данных использует стандартную форму SQL. Утилиты для проектирования таблиц имеют интуитивно понятный интерфейс. MySQL поддерживает до 50 миллионов строк в таблице. Предельный размер файла для таблицы по умолчанию 4 ГБ, но его можно увеличить. Поддерживает секционирование и репликацию, а также Xpath и хранимые процедуры, триггеры и представления.
Особенности
- Масштабируемость.
- Лёгкость использования.
- Безопасность.
- Поддержка Novell Cluster.
- Скорость.
- Поддержка многих операционных систем.
3. Microsoft SQL Server
Самая популярная коммерческая СУБД. Она привязана к Windows, но это плюс, если вы пользуетесь продуктами Microsoft. Зависит от платформы. И графический интерфейс, и программное обеспечение основаны на командах. Поддерживает SQL, непроцедурные, нечувствительные к регистру и общие языки баз данных.
Особенности
- Высокая производительность.
- Зависимость от платформы.
- Возможность установить разные версии на одном компьютере.
- Генерация скриптов для перемещения данных.
4. PosgreSQL
Масштабируемая объектно-реляционная база данных, работающая на Linux, Windows, OSX и некоторых других системах. В PostgreSQL 10 есть такие функции, как логическая репликация, декларативное разбиение таблиц, улучшенные параллельные запросы, более безопасная аутентификация по паролю на основе SCRAM-SHA-256.
Особенности
- Поддержка табличных пространств, а также хранимых процедур, объединений, представлений и триггеров.
- Восстановление на момент времени (PITR).
- Асинхронная репликация.
NoSQL-базы данных
5. MongoDB
Самая популярная NoSQL система управления базами данных. Лучше всего подходит для динамических запросов и определения индексов. Гибкая структура, которую можно модифицировать и расширять. Поддерживает Linux, OSX и Windows, но размер БД ограничен 2,5 ГБ в 32-битных системах. Использует платформы хранения MMAPv1 и WiredTiger.
Особенности
- Высокая производительность.
- Автоматическая фрагментация.
- Работа на нескольких серверах.
- Поддержка репликации Master-Slave.
- Данные хранятся в форме документов JSON.
- Возможность индексировать все поля в документе.
- Поддержка поиска по регулярным выражениям.
6. DB2
Работает на Linux, UNIX, Windows и мейнфреймах. Эта СУБД идеально подходит для хост-сред IBM. Версию DB2 Express-C нельзя использовать в средах высокой доступности (при репликации, кластеризации типа active-passive и при работе с синхронизируемым доступом к разделяемым данным).
Особенности DB2 11.1
- Улучшенное встроенное шифрование.
- Упрощённая установка и развёртывание.
7. Microsoft Access
Система управления базами данных от Microsoft, которая сочетает в себе реляционное ядро БД Microsoft Jet с графическим интерфейсом пользователя и инструментами разработки ПО.
Особенности
- Можно использовать VBA для создания многофункциональных решений с расширенными возможностями управления данными и пользовательским контролем.
- Импорт и экспорт в форматы Excel, Outlook, ASCII, dBase, Paradox, FoxPro, SQL Server и Oracle.
- Формат базы данных Jet.
8. Cassandra
СУБД активно используется в банковском деле, финансах, а также в Facebook и Twitter. Поддерживает Windows, Linux и OSX. Для запросов к БД Cassandra используется SQL-подобный язык — Cassandra Query Language (CQL).
Особенности
- Линейная масштабируемость.
- Быстрое время отклика.
- Поддержка MapReduce и Apache Hadoop.
- Максимальная гибкость.
- P2P архитектура.
9. Redis
Особенности
- Автоматическая обработка отказа.
- Транзакции.
- Сценарии LUA.
- Вытеснение LRU-ключей.
- Поддержка Publish/Subscribe.
10. Elasticsearch
Легко масштабируемая поисковая система корпоративного уровня с открытым исходным кодом. Благодаря обширному и продуманному API обеспечивает чрезвычайно быстрый поиск, работает в том числе с приложениями для обнаружения данных. Используется такими компаниями, как Википедия, The Guardian, StackOverflow, GitHub. ElasticSearch позволяет создавать копии индексов и сегментов.
Читайте также: