Краткий обзор современных СУБД | World-X
Перед теми, кого интересует миграция баз данных, встает один вопрос: какую СУБД выбрать? Их существует множество, но наиболее популярных, используемых как в небольших, так и в очень масштабных проектах, только три:
MySQL – самая популярная СУБД в мире
MySQL является самой популярной СУБД. Она обладает широким функционалом, способна хранить гигантские объемы информации и сравнительно быстро записывает и извлекает данные из таблиц. Чаще всего ее применяют в веб-проектах. Подавляющее большинство сайтов, присутствующих в Интернете, используют именно MySQL для хранения данных.
C MySQL сравнительно легко работать, и взаимодействию с этой СУБД можно научиться за короткое время. В виду ее популярности, в Сети присутствует множество материалов на различных языках и книг, которые обучают работе с MySQL. Кроме того, в виду ее широкого распространения, для этой СУБД написано множество плагинов, расширяющих функционал.
Есть у этой системы и недостатки. Один из них – трудность использования в очень масштабных проектах, так как у нее есть проблемы с мультипоточностью.
SQLite – СУБД для приложений
SQLite – СУБД, которую многие разработчики используют в своих приложениях. В отличие от многих других систем, в этой данные хранятся в отдельных файлах, и обращение к ним происходит напрямую, а не посредством сокетов и портов. Из-за этого на чтение она работает очень быстро.
У SQLite отсутствует система пользователей, поэтому ее невозможно использовать в многопользовательских приложениях. Кроме того, она сравнительно медленно работает на запись. В виду этого ее практически невозможно нормально использовать в веб-проектах. Однако, например, для хранения данных однопользовательских игр она подходит очень хорошо. Эта СУБД сейчас активно применяется, например, в играх для Android.
PostgreSQL – профессиональное решение
СУБД PostgreSQL позиционируется в качестве профессионального решения. В отличие от многих других аналогичных современных систем, эта максимально полно поддерживает синтаксис SQL. Она имеет множество функций, которые необходимы приложениям, предъявляющим очень высокие требования к надежности и безопасности.
Эта СУБД сравнительно медленная, но надежная. Из-за этого ее используют, например, банки, которым нужно максимально сократить риски потери данных или их несанкционированного изменения.
Каждая СУБД имеет свои достоинства и недостатки. Поэтому нужно выбирать ту систему, которая лучше подходит под особенности разрабатываемого проекта. А если та изначально была выбрана неверно, то придется выполнять миграцию.
поделитесь с друзьями:
ВКонтакте
OK
wd-x.ru
Московский Энергетический Институт, Технический Университет
Обзор современных систем управления базами данных
Студент: Дудкина А.
Группа: А-13-07
Предмет: базы данных и экспертные системы
Преподаватель: Сидорова Н.П.
2010 г.
Оглавление.
Введение.
Обзор основных СУБД:
Oracle
Microsoft SQL Server
IBM DB2
PostgreSQL
Прочие СУБД
Заключение: тенденции развития СУБД.
Приложение.
Введение
В настоящее время в мире используется достаточно большое количество универсальных промышленных СУБД. Среди них можно выделить трех несомненных лидеров (как по уровню развития технологий, так и по объему рынка – они вместе занимают более 90% мирового рынка СУБД). Это СУБД первого эшелона – Oracle, Microsoft SQL Server, MySQL и IBM DB2, в последнее время быстро становится популярна система с открытым кодом PostgreSQL. Список СУБД второго эшелона довольно велик, сюда относят такие СУБД, как Sybase, Informix, Ingress, Adabas, Interbase, Progress, Cache, Linter, Firebird, Teradata и т д
Существуют также небольшие СУБД для нишевых (специализированных) решений и постоянно появляются прототипы новых специализированных СУБД (объектно-ориентированные СУБД, ХML СУБД, СУБД для обработки потоковых данных, СУБД для работы с текстами и т.д.).
Многие авторы классифицируют СУБД на две большие категории: так называемые «настольные» и «серверные».
Настольные СУБД используются для сравнительно небольших задач (небольшой объем обрабатываемых данных, малое количество пользователей). С учетом этого, указанные СУБД имеют относительно упрощенную архитектуру, в частности, функционируют в режиме файл-сервер, поддерживают не все возможные функции СУБД (например, не ведется журнал транзакций, отсутствует возможность автоматического восстановления базы данных после сбоев и т. п.). Тем не менее, такие системы имеют достаточно обширную область применения. Прежде всего, это государственные (муниципальные) учреждения, сфера образования, сфера обслуживания, малый и средний бизнес. Специфика возникающих там задач заключается в том, что объемы данных не являются катастрофически большими, частота обновлений не бывает слишком высокой, организация территориально обычно расположена в одном небольшом здании, количество пользователей колеблется от одного до 10–15 человек. В подобных условиях использование настольных СУБД для управления информационными системами является вполне оправданным, и они с успехом применяются.
Одними из первых СУБД были так называемые dBase-совместимые программные системы, разработанные разными фирмами. Первой широко распространенной системой такого рода была система dBase III – PLUS (фирма Achton-Tate). Развитый язык программирования, удобный интерфейс, доступный для массового пользователя, способствовали широкому распространению системы. В то же время работа системы в режиме интерпретации обусловливала низкую производительность на стадии выполнения. Это привело к появлению новых систем-компиляторов, близких к системе dBase III – PLUS: Clipper (фирма Nantucket Inc.), FoxPro (фирма Fox Software), FoxBase+ (фирма Fox Software), Visual FoxPro (фирма Microsoft). Одно время достаточно широко использовалась СУБД PARADOX (фирма Borland International).
В последние годы очень широкое распространение получила система управления базами данных Microsoft Access, которая входит в целый ряд версий пакета Microsoft Office(фирма Microsoft).
Для крупных организаций ситуация принципиально меняется. Там использование файл-серверных технологий является неудовлетворительным по описанным выше причинам. Поэтому на передний край борьбы за автоматизацию выходят так называемые серверные СУБД.
Основными производителями таких систем обработки и хранения данных являются 3 корпорации: Oracle, Microsoft и IBM. Диаграмма соотношения объемов продаж соответствующих систем (источник: IDC Report, Май 2006) приводится на рисунке.
Продажи ПО систем хранения данных в мире
Наиболее распространенными клиент-серверными системами здесь соответственно являются системы Oracle (разработчик компания Oracle), MS SQL Server (разработчик компания Microsoft), DB2, Informix Dynamic Server (компания IBM).
Дадим краткую характеристику основным системам.
Oracle
СУБД Oracle – ветеран рынка реляционных СУБД. Разработка этой системы была начата практически в то же время, что и IBM DB2 и по настоящее время эти системы остаются основными конкурентами (что видно из рисунка ).
Oracle занимает лидирующие позиции на рынке СУБД и, что особенно важно, лидирует на платформах Unix и Windows. В России также обозначилось лидерство Oracle, особенно в области крупномасштабных информационных систем. Фактически в нашей стране СУБД Oracle стала стандартом государственных информационных систем.
Причина широкой распространенности Oracle заключается прежде всего в высоких эксплуатационных характеристиках СУБД, большом количестве подготовленных отечественных специалистов по Oracle, наличию поддерживающей инфраструктуры – учебных центров, широкой сети партнеров Oracle, большому числу технических курсов по Oracle в высших учебных заведениях и т.д. Так, только в Москве имеется более десятка учебных центров, предоставляющих широкий спектр технических курсов практически по всем линиям программных продуктов Oracle. Партнерская сеть по всей стране насчитывает более 160 организаций, что гарантирует поддержку ПО Oracle практически в любой точке страны. На русском языке уже издано достаточно много качественных книг по СУБД Oracle.
Служба технической поддержки Oracle построена на профессиональной основе. Служба технической поддержки в России сертифицирована по стандарту ISO 9000.
Кроме того, ведущие компании – партнеры Oracle, такие как FORS, RDTex имеют собственные центры технической поддержки.
Важным является и то, что наряду с СУБД, компания Oracle поставляет центральный инфраструктурный продукт – Internet Application Server, сервер приложений, функционирующих в среде Internet/Intranet, а также CASE-средства, средства быстрой разработки приложений, средства построения хранилищ данных, оперативного анализа данных, выявления сложных зависимостей в данных (Data Mining), что позволяет поставлять не отдельные продукты, но комплексные технологические решения для заказчиков.
С технической точки зрения важно то, что Oracle функционирует практически на всех существующих компьютерных платформах, в том числе и на больших ЭВМ (OS/390) и на еще сохраняющих популярность системах Vax VMS, не говоря уже о Windows NT и различных разновидностях Unix, в том числе Solaris, HP-UX, AIX, Linux, SCO Unix и т.д.
Другой важной характеристикой является поддержка Oracle всех возможных вариантов архитектур, в том числе симметричных многопроцессорных систем, кластеров, систем с массовым параллелизмом и т.д. Очевидна значимость этих характеристик для современных масштабных организаций, где эксплуатируется множество компьютеров различных моделей и производителей. В таких условиях фактором успеха является максимально возможная типизация предлагаемых решений, ставящая своей целью существенное снижение стоимости владения программным обеспечением. Унификация систем управления базами данных – один из наиболее значимых шагов на пути достижения этой цели.
Ядром СУБД Oracle является сервер базы данных, который поставляется в одном из четырех вариантов в зависимости от масштаба информационной системы, в рамках которой предполагается его применение. Для систем масштаба крупной организации предлагается продукт OracleDatabase Enterprise Edition (корпоративная редакция) [6], для которого имеется целый набор опций, архитектурно и функционально расширяющих возможности сервера. Именно Oracle Database Enterprise Edition устанавливается на кластерах (с опцией Parallel Server, по версию 8i включительно или RAC– Real Application Cluster, начиная с версии 9i и старше), позволяя создавать системы высокой готовности. Продукт Oracle Database Standard Edition(стандартная редакция) [6] ориентирован на организации среднего масштаба или подразделения в составе крупной организации. Для персонального использования предназначен продукт Oracle Database Personal Edition (персональная редакция) [6].
Важнейшим преимуществом Oracle перед конкурентами (и, прежде всего, перед DB2) является идентичность кода различных версий сервера баз данных Oracle для всех платформ, гарантирующая идентичность и предсказуемость работы Oracle на всех типах компьютеров, какие бы не входили в ее состав. Все варианты сервера Oracle имеют в своей основе один и тот же исходный программный код и функционально идентичны, за исключением некоторых опций, которые, например, могут быть добавлены к Oracle Database Enterprise Edition и не могут — к Oracle Database Standard Edition.
Таким образом, для всех платформ существует единая СУБД в различных версиях, которая ведет себя одинаково и предоставляет одинаковую функциональность вне зависимости от платформы, на которой она установлена. Разработку серверных продуктов в составе СУБД выполняет единое подразделение корпорации Oracle, изменения вносятся централизовано, после этого подвергаются тщательному тестированию в базовом варианте, а затем переносятся на все платформы, где также детально проверяются. Возможность переноса Oracle обеспечивается специфической структурой исходного программного кода сервера. Приблизительно 80% программного кода Oracle – это программы на языке программирования C, который (с известными ограничениями) является платформо — независимым. Примерно 20% кода, представляющее собой ядро сервера, реализовано на машинно-зависимых языках и эта часть кода, разумеется, переписывается для различных платформ.
Жесткая технологическая схема разработки Oracle, опирающаяся на принципы идентичности исходного программного кода для различных версий и платформ, контрастирует со схемами других компаний. Так, СУБД DB/2 представляет собой семейство продуктов, но не единый продукт. Функционально версия DB2 для IBM S/390 столь существенно отличается от DB2 для платформ UNIX и NT, что позволяет говорить вообще о разных продуктах.
Итак, СУБД Oracle скрывает детали реализации механизмов управления данным на каждой из платформ, что дает основание говорить о практически полной унификации базового программного обеспечения. Дополнительно к этому, архитектура Oracle позволяет переносить прикладные системы, реализованные на одной платформе, на другие платформы без изменений как в структурах баз данных, так и кодов приложений. При этом основным критерием, определяющим возможность переноса тех или иных программных компонентов между платформами является полное исключение их них машинно-зависимого кода.
Microsoft SQL Server
Началом истории Microsoft SQL Server по праву можно считать 1986 год, когда Microsoft и Sybase выпустили совместную версию продукта — SQL Server 1.0 и адаптировали ее для операционной системы OS/2 при поддержке компании Ashton Tate, которая в то время была лидером на рынке СУБД для персональных компьютеров. Выпущенный в 1989 году продукт не получил должного признания из за проблем, связанных с продвижением OS/2. В 1990 году Sybase и Microsoft прервали соглашение с Ashton Tate и выпустили версию SQL Server 1.1 для новой операционной системы Windows 3.0. Microsoft отвечала за клиентские утилиты, программные интерфейсы и средства управления, а Sybase — за разработку ядра базы данных.
В 1992 году началась разработка новой версии продукта — SQL Server on Windows NT, который был выпущен в 1993 году одновременно с серверной операционной системой — Microsoft Windows NT. Тесная интеграция с Windows NT обеспечила продукту высокую производительность, управляемость и впервые у Microsoft появилась система управления базами данных, которая могла конкурировать с аналогичными продуктами на платформе UNIX. В 1994 году Microsoft и Sybase прервали совместное пятилетнее соглашение и бывшие партнеры занялись самостоятельным развитием своих, теперь уже конкурирующих продуктов.
В 1995 и 1996 годах увидели свет версии SQL Server 6.0 и 6.5, но некоторые проблемы с производительностью и управляемостью не позволили этим продуктам завоевать существенную долю рынка корпоративных СУБД. Было принято решение приостановить развитие текущей версии платформы и начать создание продукта «с нуля». Примерно в то же время компания DEC
продала свою систему управления базами данных компании Oracle и Microsoft удалось заполучить ведущих специалистов компании DEC — Джима Грея (Jim Gray), Дэйва Ломета (Dave Lomet) и Фила Бернштейна (Phil Bernstein). Команде разработчиков была поставлена задача — создать новое ядро базы данных с поддержкой масштабируемости, новый процессор обработки запросов, систему самонастройки, самоуправления, а также реализовать поддержку OLAP и ETL с привлечением специалистов из компании Panorama. Разработка новой СУБД заняла около трех лет и в 1998 году был выпущен продукт под названием SQL Server 7.0 — Microsoft начала завоевывать не только рынок реляционных СУБД, но и такие новые рынки, как business intelligence и data warehousing. Параллельно велась работа над SQL Server 2000, который включал в себя поддержку XML, индексированные представления, распределенные разделы на основе представлений, а также более чем 20% ное увеличение производительности для практически всех ключевых компонентов продукта. В 2000 году Microsoft стала полноправным лидером на рынке СУБД для платформы Windows.
Дальнейшее развитие продукта — в версиях SQL Server 2005 и SQL Server 2008 — добавило увеличение производительности, управляемости, расширенную поддержку различных типов данных, интегрированные системы создания отчетов, трансформации данных, расширенные функции анализа и т. п.
Microsoft SQL Server 2008 — это законченное предложение в области баз данных и анализа данных для быстрого создания масштабируемых решений электронной коммерции, бизнес-приложений и хранилищ данных. Оно позволяет значительно сократить время выхода этих решений на рынок, одновременно обеспечивая масштабируемость, отвечающую самым высоким требованиям. В SQL Server включена поддержка языка XML и протокола HTTP, средства повышения быстродействия и доступности, позволяющие распределить нагрузку и обеспечить бесперебойную работу, функции для улучшения управления и настройки, снижающие совокупную стоимость владения.
Платформа бизнес-анализа SQL Server 2008, тесно интегрированная с Microsoft Office, предоставляет развитую маштабируемую инфраструктуру для внедрения мощных возможностей бизнес-анализа в рабочий процесс всех бизнес-подразделений вашей компании, открывая доступ к нужной бизнес-информации через знакомый интерфейс MS Excel и MS Word.
MS SQL Server 2008 поддерживает создание и работу с корпоративным хранилищем данных, объединяющим информацию со всех систем и приложений, позволяющим получить единую комплексную картину бизнеса вашей компании.
MS SQL Server 2008 предоставляет масштабируемый и высокопроизводительный «процессор данных» — для самых ответственных и требовательных бизнес-приложений, тем, кому необходим высочайший уровень надежности и защиты, позволяя при этом снизить совокупную стоимость владения за счет расширенных возможностей по управлению серверной инфраструктурой.
MS SQL Server 2008 предлагает разработчикам развитую, удобную и функциональную среду программирования, включая средства работы с веб службами, инновационные технологии доступа к данным – все, что необходимо для эффективной работы с данными любых типов и форматов
DB2 Universal Database
Сначала немного информации с сервера (http://www-01.ibm.com/software/ru/data/?pgel=ibmhzn):
Универсальный сервер баз данных DB2 Universal Database — это масштабируемая, обьектно-реляционная система управления базами данных с интегрированной поддержкой мультимедиа и Web, работающая на системах от персональных компьютеров и серверов на процессорах Intel до Unix, от однопроцессорных систем до симметричных многопроцессорных систем (SMP) и систем с массовым параллелизмом (MPP), на хостах AS/400 и мейнфреймах. DB2 Universal Database объединяет в себе высокую производительность систем обработки транзакций в режиме on—line, объектно-реляционные расширения, усовершенствованные средства оптимизации с возможностями параллельной обработки и поддержкой очень больших баз данных. DB2 Universal Database также имеет новые встроенные средства для облегчения переноса на свою базу приложений, разработанных на других системах управления базами данных, таких как Oracle, Microsoft, Sybase и Informix. Помимо этого, DB2 Universal Database включает в себя дополнительные средства поддержки систем аналитической обработки в реальном времени (OLAP) и систем поддержки принятия решений, множество простых в использовании расширений (DB2 extenders). DB2 Universal Database доступна на абсолютном большинстве ключевых платформ, что дает заказчикам ту гибкость, которая им необходима.
Система СУБД DB2 – один из “долгожителей” в мире систем управления базами данных. Имея в своей основе классическую реляционную модель данных, система первоначально разрабатывалась для больших ЭВМ. Только впоследствии компания IBM реализовала DB2 для платформы AS/400 (СУБД получила название DB2/400), а несколько позже приступила к выпуску практически нового продукта под названием Universal Data Base (UDB), который, как предполагалось, будет соответствовать стандартам открытых систем и функционировать на широком спектре платформ, включая Unix и Windows.
В настоящий момент позиции СУБД DB2 исключительно сильны в первую очередь на больших ЭВМ. Если сравнить экспертные оценки по эксплуатационным характеристикам, приведенные в таблице 1, то видно, что СУБД DB2 обладает практически наивысшими оценками именно на платформе больших ЭВМ. Показательно и то, что СУБД UDB рассматривается в таблице отдельно. Это как раз показатель того, что под общим брэндомDB2 скрывается три практически различных продукта – DB2 для больших ЭВМ, DB2/400 и универсальная DB2 для других платформ. В контексте современной технической политики, которая требует безусловной и максимально возможной унификации базового программного обеспечения, наличие трех различных программных продуктов является негативным фактором.
Являясь главным конкурентом СУБД Oracle в Северной Америке, на российском рынке СУБД DB2, несмотря на высокое техническое качество продукта, представлена очень слабо. Возможно, это связано с общей стратегией компании IBM на российском рынке, когда основной акцент сделан на поставках компьютерных платформ. Фактом является то, что в России с DB2 работают лишь группы энтузиастов. Практически нет инфраструктуры, необходимой для широкого распространения продукта, нет достаточного числа обученных специалистов, нет широкой сети учебных центров, отсутствует литература на русском языке. Представительство IBM в России практически не имеет отделения по технической поддержке DB2, что существенно осложняет эксплуатацию СУБД. Инсталляционная база DB2 в России очень ограничена и затрагивает по большей части большие ЭВМ и AS/400. Партнерская сеть IBM по DB2 невелика по сравнению, скажем, с Microsoft или Oracle. DB2 пока не удалось стать стандартом баз данных для платформ UNIX (здесь эта ниша занята Oracle) и Windows NT (ниша занята Microsoft SQL Server и Oracle).
PostgreSQL
PostgreSQL — объектно-реляционная система управления базами данных (ОРСУБД), разработка которой в различных формах ведется с 1977 года. Работа началась с проекта Ingres в Калифорнийском университете (Беркли). Затем проект Ingres был переведен на коммерческую разработку в корпорации Relational Technologies/Ingres.
В 1986 году другая группа, которую возглавлял Майкл-Стоунбрейкер (Michael Stonebraker) из Беркли, продолжила работу над Ingres и создала объектно-реляционную СУБД Postgres. В 1996 году из-за усовершенствования пакета и перехода на распространение с открытыми исходными текстами было принято новое название — PostgreSQL (в течение непродолжительного времени использовалось название Postgres95). В настоящее время над проектом PostgreSQL активно работает группа разработчиков со всего мира.
PostgreSQL считается самой совершенной СУБД, распространяемой на условиях открытых исходных текстов. В PostgreSQL реализованы многие возможности, традиционно встречавшиеся только в масштабных коммерческих продуктах (за дополнительной информацией обращайтесь к разделу «Возможности PostgreSQL»).
В PostgreSQL реализованы многие возможности, обычно присутствующие только в коммерческих СУБД, таких как DB2 и Oracle. Ниже перечислены основные возможности PostgreSQL версии 7.1.x.
Объектно-реляционная модель. Работа с данными в PostgreSQL основана на объектно-реляционной модели, что позволяет задействовать сложные процедуры и системы правил. Примерами нетривиальных возможностей этой категории являются декларативные запросы SQL, контроль параллельного доступа, поддержка многопользовательского доступа, транзакции, оптимизация запросов, поддержка наследования и массивов.
Простота расширения. В PostgreSQL поддерживаются пользовательские операторы, функции, методы доступа и типы данных.
Полноценная поддержка SQL. PostgreSQL соответствует базовой спецификации SQL99 и поддерживает такие нетривиальные средства, как объединения стандарта SQL92.
Проверка целостности ссылок. PostgreSQL поддерживает проверку целостности ссылок, обеспечивающую правильность данных в базе.
Гибкость API. Гибкость API PostgreSQL позволяет легко создавать интерфейсы к РСУБД PostgreSQL. В настоящее время существуют программные интерфейсы для Object Pascal, Python, Perl, PHP, ODBC, Java/JDBC, Ruby, TCL, C/ C+ и Pike.
Процедурные языки. В PostgreSQL предусмотрена поддержка внутренних процедурных языков, в том числе специализированного языка PL/pgSQL, являющегося аналогом PL/SQL, процедурного языка Oracle. Одним из преимуществ PostgreSQL является возможность использования Perl, Python и TCL в качестве внутренних процедурных языков.
МУСС. Технология MVCC (Multi-Version Concurrency Control) используется в PostgreSQL для предотвращения лишних блокировок (locking). Каждый, кто хоть раз работал с другими СУБД на базе SQL (например, MySQL или Access), наверняка замечал, что обращение к базе данных для чтения иногда сопровождается задержками, связанными с попытками записи в базу данных. Проще говоря, операции чтения блокируются операциями, производящими обновление записей. Применение технологии MVCC в PostgreSQL полностью решает эту проблему. MVCC лучше низкоуровневой блокировки, поскольку операции чтения никогда не блокируются операциями записи. Вместо этого PostgreSQL отслеживает все транзакции, выполняемые пользователями базы данных, что позволяет работать с записями без ожидания их освобождения.
Клиент-сервер. В PostgreSQL используется архитектура «клиент-сервер» с распределением процессов между пользователями. В целом она напоминает методику работы с процессами в Apache 1.3.x. Главный (master) процесс создает дополнительные подключения для каждого клиента, пытающегося установить соединение с PostgreSQL.
Опережающая регистрация изменений. Опережающая регистрация изменений (Write Ahead Logging, WAL) повышает надежность данных. Все изменения данных протоколируются до их непосредственной актуализации в базе. Наличие протокола изменений гарантирует, что в случае сбоя базы данных (что весьма маловероятно) данные можно будет восстановить по запротоколированным транзакциям. После восстановления системы пользователь продолжает работу с состояния, непосредственно предшествовавшего сбою.
studfile.net
Обзор современных реляционных СУБД
Среди современных систем управления базами данных выделяют реляционные СУБД, к которым относятся:
- MS Access,
- Visual FoxPro,
- MySQL,
- PostgreSQL,
- Sybase,
- SQL Server,
- Oracle,
- DB2
- и др.
Рассмотрим наиболее распространенные из них.
СУБД MS Access
Программа Access функционирует под управлением операционной системы Windows и обладает стандартизованным интерфейсом приложений Windows.
Основным компонентом является база данных, которая может содержать таблицы, отчеты, запросы, формы, модули и макросы.
Обработка информации в процессе работы с БД осуществляется с помощью макросов или VBA программ.
Открытая БД может обмениваться данными с внешними БД. Внешней базой данных может быть любая БД, которая поддерживает протокол ODBC и расположена на удаленном сервере, или одна из БД СУБД Access, dBASE или Paradox.
Access позволяет создавать и выполнять запросы на выборку, добавление данных, удаление и обновление.
Запрос можно создать с помощью QBE или SQL. Программой Access поддерживается механизм OLE (связывание и встраивание объектов) и механизм DDE (динамический обмен данными).
СУБД Visual FoxPro
СУБД Visual FoxPro содержит развитые средствами создания баз данных, организации запросов к ним, создания приложений с при помощи визуального, объектно-ориентированного программирования. СУБД Visual FoxPro работает под управлением Windows.
База данных в Visual FoxPro является совокупностью связанных таблиц. В базе данных определены условия ее целостности через первичные и внешние ключи таблиц. Все изменения, которые происходят в БД, обнаруживаются и централизованно обрабатываются с помощью триггеров и встроенных процедур программы.
Visual FoxPro характеризует высокая скорость обслуживания БД.
С помощью стандарта ODBC и SQL-запросов для выборки данных Visual FoxPro может работать с базами данных dBase, Paradox, Access и т. д., с серверами баз данных – Oracle MS SQL Server и др.
Возможна одновременная работа приложения Visual FoxPro с собственными и сетевыми таблицами, которые расположены на других компьютерах в локальной сети.
Visual FoxPro поддерживает механизмы OLE и DDE работы с Windows приложениями.
Visual FoxPro позволяет создавать сетевые приложения, которые функционируют в сетях под управлением MS LAN Manager, MS Windows и др.
MS SQL Server
Microsoft SQL Server широко используется в области БД и для анализа данных, позволяет быстро создавать масштабируемые решения электронной коммерции, приложений для бизнеса и хранилищ данных. SQL Server поддерживает язык XML и протокол HTTP, средства повышения доступности и быстродействия, которые позволяют обеспечить бесперебойную работу и распределить нагрузку, функции улучшения настройки и управления.
Платформа анализа данных SQL Server, которая интегрирована с MS Office, позволяет открыть доступ к необходимой бизнес-информации с помощью интерфейса MS Word и MS Excel.
В SQL Server входит развитая, удобная и функциональная среда программирования, которая включает средства для работы с веб-службами, технологии доступа к данным.
Oracle
Oracle включает СУБД и средства разработки и анализа данных.
Oracle включает БД, интеграционную платформу, сервер приложений, инструменты управления неструктурированными данными и аналитики.
СУБД Oracle Database позволяет автоматизировать задачи администрирования, обеспечивает безопасность и соответствие нормативно-правовым актам защиты информации, содержит функции управления и самодиагностики. К характеристикам системы относится управление большими объемами данных с помощью использования компрессии и распределенных таблиц, эффективная защита данных, возможность интеграции геофизических данных и полного восстановления и т.д.
spravochnick.ru
Операционные СУБД NoSQL: сегодня и завтра | Открытые системы. СУБД
По мере роста применения средств работы с Большими Данными к СУБД предъявляются все более высокие требования с точки зрения производительности и масштабируемости. На протяжении последних четырех десятков лет реляционные СУБД играли ключевую роль во многих областях деятельности, однако современным приложениям нужна функциональность, не свойственная этим системам, в том числе возможность изменения схем, а также поддержка многообразия типов и моделей данных. Помимо этого, новым СУБД нужно уметь элегантно, экономично и автоматически масштабироваться. Элегантность — возможность добавления узлов по мере роста объемов данных для сохранения гарантированной скорости выполнения запросов. Автоматизм — способность сбалансированно распределять данные по мере добавления узлов. А благодаря экономичности затраты на развертывание должны снижаться по мере совершенствования аппаратного обеспечения. Иначе говоря, экономия, достигнутая за счет снижения затрат на вычисления и хранение, распространяется на общую стоимость внедрения и эксплуатации СУБД.
Все три названные характеристики присущи СУБД NoSQL, и хотя их название намекает на противопоставление базам SQL, к нереляционным могут относиться и системы, поддерживающие как SQL, так и другие способы опроса. Системы NoSQL были созданы, чтобы расширить, а не заменить функционал реляционных СУБД. По сути, многие свойства NoSQL-систем не новы и не уникальны. Главное отличие в том, что в системах NoSQL акцент делается на другом наборе функций.
Системы NoSQL бывают операционными и аналитическими (см. врезку). О первых говорят редко, и их особенности известны хуже [1], хотя системы NoSQL стремительно развиваются и функциональные границы между ними стираются. Начали появляться системы, поддерживающие многие модели данных, и эта тенденция сохранится, причем ожесточенная конкуренция на рынке СУБД позволяет предположить, что разработчики продуктов NoSQL будут расширять круг их применений, заполняя пустые ниши.
Классы систем NoSQL
Реляционные базы данных обычно используются либо для оперативной обработки транзакций (Online Transaction Processing, OLTP), либо в системах поддержки принятия решений (Decision Support System, DSS). Рабочие задачи OLTP обычно состоят из кратких запросов, требующих считывания или обновления небольшого количества кортежей или записей. Пример такой задачи — система ввода заказов, размещающая в базе записи о новых заказах и извлекающая существующие. Задачи DSS состоят из сложных запросов, требующих просмотра, соединения или агрегации данных из одной или более таблиц. Например, анализ тенденций продаж обычно выполняется с помощью движка DSS.
Системы NoSQL по аналогии тоже можно разделить на два основных класса: операционные, соответствующие СУБД для OLTP, и аналитические, соответствующие СУБД для DSS. Подобно реляционным системам OLTP, операционные системы NoSQL являются транзакционными. К ним относятся Aerospike, Cassandra, Couchbase, DynamoDB, HBase, MarkLogic, MongoDB, Oracle NoSQL, Redis и Riak. В отличие от них, аналитические системы NoSQL основаны на MapReduce, Hadoop и Spark. Так же как и реляционные СУБД, аналитические и операционные системы NoSQL имеют свои области применения и в значительной степени присутствуют на независимых рынках.
Определяющие особенности
Из рисунка можно понять, какие характеристики привлекают заказчиков в системах NoSQL.
Текущие характеристики и прогнозируемые направления развития систем NoSQL |
Главные общие черты
Среди общих для большинства систем NoSQL характеристик обычно отмечают изменяемые схемы данных, гибкость запросов, простоту эксплуатации, наличие сообщества и низкую стоимость.
Изменяемые схемы. Во многих современных приложениях схема данных часто меняется. К примеру, при сохранении информации из пользовательского профиля в платформе адресной рекламы число атрибутов пользователя с поступлением новых сведений о нем меняется. Другой пример — сбор данных о пользовательской активности на торговых онлайн-площадках вроде eBay или Craigslist. По мере изменения приложений, на которых базируются эти площадки, сохраняется все больше данных в расчете на каждого пользователя и каждое его действие. Согласно нормативным требованиям, могут также понадобиться запись дополнительной информации и хранение старой в течение определенного периода времени. Управление подобными данными с помощью традиционных реляционных СУБД, не предполагающих изменения однажды созданной схемы, невозможно: в достаточно сложной среде даже для простого изменения схемы, например для добавления одного столбца, может потребоваться неделя. В системах NoSQL этой проблемы нет: в них часто используется документная модель данных, когда база представляет собой коллекцию документов, или модель «ключ-значение», в которой данные представлены в виде соответствующих пар. В таких системах можно вначале загрузить данные, а уже потом определять и переопределять схемы. Гибкие модели данных позволяют, например, держать в одной и той же коллекции две записи с переменным числом описательных атрибутов. Процессы управления данными (например, контроль изменений и версий схем) протекают проще, а времени на внедрение новой функциональности требуется гораздо меньше.
Гибкость запросов. С использованием гибких схем тесно связана еще одна особенность — возможность применения гибких методов поиска по базе запросов, составленных в свободной форме на основе регулярных выражений, и поиска по ключевым словам. Гибкость запросов особенно полезна, когда система NoSQL служит одновременно и как репозиторий метаданных для описания гетерогенных срезов данных, и как средство обнаружения этих срезов. Такой сценарий применения преобладает в организациях, в которых данные хранятся разрозненно. Разобщенные источники данных в этом случае появляются вследствие роста объемов информации в различных отделах или поглощенных компаниях. На предприятиях нередко хранят данные в отделах (маркетинга, продаж, бухгалтерии, кадров и т. д.), чьи функции, как правило, не связаны друг с другом. Приложения работы с Большими Данными меняют ситуацию: они дают возможность руководителям исследовать весь объем данных организации и, таким образом, принимать более обоснованные решения.
Идеальным вариантом было бы существование единственной оптимальной схемы данных для всей информации предприятия, которую использовали бы все приложения. Но этой идиллии не суждено воплотиться в жизнь, по крайней мере пока не будет предложен простой способ обнаружения связей между разобщенными гетерогенными данными. Сегодня эти связи устанавливаются путем создания метаданных, описывающих основные данные и сохраняемых в системе NoSQL. Гибкие механизмы опроса позволяют выполнять поиск в метаданных по ключевым словам.
Гибкость опроса обеспечивается, в частности, когда система NoSQL хранит данные в формате типа JSON, позволяющем делать прямые запросы к JSON-документам. При этом можно запрашивать не только значения атрибутов (как в реляционных СУБД), но и элементы схемы. Гибкие механизмы опроса и схемы позволяют анализировать квазиструктурированные срезы данных и проводить предварительный анализ. К системам NoSQL, которым присуща такая гибкость, относятся документные хранилища MongoDB, CouchDB и MarkLogic.
Разработку гибких методов опроса можно уподобить работе по обеспечению возможности поиска по ключевым словам, проделанной для реляционных СУБД, однако системы NoSQL позволяют менять схемы данных и предоставляют больше гибкости при заполнении и использовании базы. Также активно идет исследование методов опроса XML-баз, а во многих системах NoSQL появились средства помощи в выполнении запросов — например, встроенные механизмы индексации текста.
Простота эксплуатации. Традиционные одноузловые либо функционирующие в пределах одного ЦОД системы обработки данных сложно администрировать в динамике, и особые трудности возникают при попытке оптимизации их быстродействия по мере роста размеров базы и изменения нагрузки по обработке запросов. Поэтому большинство современных систем обработки данных работают в кластерных средах, собранных из стандартных компонентов, что, однако, еще больше усложняет администрирование, поскольку нужны механизмы, позволяющие прозрачно для приложений справляться со сбоями многочисленных комплектующих.
В строгих соглашениях об уровне обслуживания (service-level objectives, SLO) нередко диктуется необходимость обеспечения высокой доступности и быстродействия в круглосуточно активных средах — эти требования выполняются путем автоматического сегментирования данных, балансировки нагрузки и аварийного переключения с использованием тиражирования. Поддержка соответствующих функций должна быть изначально встроена в платформу обработки данных, а не реализована после основной разработки. Кроме того, эти функции должны автоматически адаптироваться при увеличении или уменьшении кластера.
Выполнение требований доступности затрудняется в случае распределения среды по нескольким центрам обработки данных: чтобы приложения обеспечивали заданный уровень обслуживания географически распределенных пользователей, обработка этих приложений должна быть тоже распределена между несколькими ЦОД. Примеры таких приложений: рекламные платформы, которым приходится практически мгновенно принимать решения о выборе объявлений, или мобильные игры, предоставляющие в реальном времени доступ к единому постоянно меняющемуся срезу данных.
Подобно кластерным, среды из нескольких ЦОД нуждаются в механизмах тиражирования, управления сбоями и автоматической балансировки нагрузки. Но такими средами сложнее управлять, поскольку задержка передачи по сети между ЦОД гораздо больше, чем между узлами в одном и том же центре.
Сообщество. У систем NoSQL обычно имеется обширное сообщество, включающее разработчиков самой системы и разработчиков приложений. Такие сообщества формируются либо еще до создания системы NoSQL из людей, решающих схожие задачи, либо по мере ее развития, когда разработчики стараются заинтересовать системой потенциальных пользователей. Большинство систем NoSQL открыты, что дает дополнительные стимулы для совместного планирования дальнейшего развития продукта. Вокруг систем NoSQL также нередко образуется активное сообщество пользователей.
Росту сообщества способствует простота развертывания и тестирования многих систем NoSQL, которые разрабатываются без расчета на обязательное наличие в организации администратора базы данных. Простота использования — большой плюс по сравнению с тяготами освоения некоторых традиционных реляционных СУБД.
Усилия по повышению продуктивности труда разработчиков приложений, вкладываемые создателями NoSQL-систем, сполна окупаются — небольшие проекты нередко разрастаются в крупные, занимая постоянное место в экосистеме предприятия. В подобных случаях разработчики приложений, некогда впервые попробовавшие поработать с той или иной системой NoSQL, становятся ее проводниками в своей организации. Именно поэтому создатели систем NoSQL стараются обеспечить максимальную простоту начала использования.
Низкая стоимость. Традиционные СУБД продавались на условиях лицензирования, но позволить себе платить за лицензии могли далеко не все, что стало одним из факторов, побудивших к разработке систем NoSQL. На предприятиях, внедряющих технологии Больших Данных, объемы информации обычно растут быстрее, чем доходы, а многие системы NoSQL имеют открытый код и доступны бесплатно. Крупные предприятия нередко покупают сервис, связанный с СУБД NoSQL, но все равно совокупная стоимость продукта и услуг поддержки оказывается гораздо ниже, чем у традиционных реляционных СУБД.
Дополнительные особенности
Некоторые операционные системы NoSQL характеризуются прогнозируемым быстродействием и поддержкой сложных структур данных.
Прогнозируемая производительность. Для многих современных приложений работы с данными прогнозируемое быстродействие важнее, чем фиксированный уровень производительности, особенно когда речь идет о масштабировании для работы со все более обширными срезами данных. Таким образом, если у СУБД ниже абсолютное быстродействие при выполнении стандартного запроса, но этот уровень производительности неизменно сохраняется, то это станет преимуществом. Пример — приложение для обмена сообщениями. Допустим, система должна извлечь сообщение из базы, когда пользователь открывает приложение, и, чтобы создавалось впечатление отзывчивости сервиса, у системы есть лишь ограниченное время на отклик. При разработке подобного приложения программисту будет гораздо удобнее зарезервировать заданный период времени на обслуживание запросов к базе, чтобы можно было рассчитывать, что движок СУБД с большой вероятностью уложится в это время. Гораздо важнее, чтобы эта вероятность составляла 95–99%, чем чтобы показатели среднего или наилучшего времени отклика были на определенном уровне. Некоторые традиционные системы обработки данных можно сконфигурировать так, чтобы их быстродействие было более предсказуемым, но это обычно достигается за счет избыточности ресурсов и приводит к непозволительно высоким затратам на внедрение.
Сложные структуры данных. При работе с традиционными СУБД возникали трудности из-за несоответствия между типами данных, поддерживаемыми моделью и средами разработки приложений. Проблему пытались решить, в частности, путем реализации поддержки объектов в реляционных СУБД и создания объектно-ориентированных баз, что способствовало росту популярности объектно-ориентированных языков программирования. Однако в большинстве современных реляционных СУБД поддержка сложных коллекционных структур данных ограничена.
Системы NoSQL нередко используются приложениями, сохраняющими информацию о состоянии в таких структурах, как списки и упорядоченные множества. К примеру, в игре нужно вести учет показаний доски рекордов. Если модель данных NoSQL поддерживает упорядоченные множества в качестве объекта первого класса, то историю показаний доски рекордов можно будет без проблем сохранять в базе. Многие системы NoSQL поддерживают такие структуры данных, как счетчики, списки, стеки, карты, кэши и упорядоченные множества [2, 3]. Благодаря этому приложения могут сохранять информацию о состоянии для каждого пользователя в базе и легко обращаться к ней.
Направления дальнейшей работы
Направления дальнейшей работы над системами NoSQL можно предположить исходя из их основных особенностей, не забывая о повышении производительности и универсальности, которые необходимы как СУБД в целом, так и NoSQL-системам в частности.
Контролируемая согласованность
Ранние системы NoSQL обычно не отвечали стандартным требованиям к транзакционным системам — ACID (atomicity, consistency, isolation, durability — атомарность, согласованность, изолированность, долговечность), применяя вместо этого модель BASE (basic availability, soft state, eventual consistency — базовая доступность, негарантированное сохранение состояния и возможная согласованность). Эта модель предъявляет менее строгие требования к согласованности, допуская временное расхождение копий одних и тех же данных, вследствие чего в определенных ситуациях увеличивается доступность распределенной системы. Но нередки случаи, когда системы NoSQL обеспечивают ограниченное соответствие ACID, а СУБД Google Spanner довольно близко подходит к полному выполнению требований к транзакционным системам. Сегодня наблюдается тенденция к обеспечению поддержки нескольких моделей согласованности, что предоставляет приложению возможность выбирать различные компромиссы. В каком-то смысле такой отход от BASE-согласованности — это заимствование у традиционных СУБД, в которых издавна существует возможность варьирования уровней согласованности.
Одно из интересных направлений дальнейших исследований состоит в том, чтобы помочь разработчикам приложений разобраться с последствиями выбора различных уровней согласованности для разных сценариев. Стоит также изучить влияние различных вариантов согласованности на быстродействие в условиях многоцентровых сред с разными нагрузками — например, с большим количеством операций записи либо чтения.
Бесконфликтное тиражирование структур данных
В средах, допускающих конкурентный доступ к сложным структурам данных, нужны механизмы управления такими структурами, особенно когда для отказоустойчивости применяется тиражирование, в том числе в системах, распределенных между несколькими ЦОД с большой задержкой передачи между центрами.
Ускорение за счет возможностей оборудования
Современная экосистема серверного оборудования сильно отличается от того, что было еще несколько лет назад. В нынешних системах стало нормой использование большого числа многоядерных процессоров, обширной основной памяти и систем хранения данных на твердотельных накопителях. Задействование возможностей современного оборудования — важное направление работ, особенно для поиска экономически эффективных способов сохранения прогнозируемого быстродействия и хорошей масштабируемости в многоцентровых средах. В некоторых операционных системах NoSQL, например Aeorspike, были сделаны большие шаги к достижению этих целей, однако постоянно меняющаяся аппаратная экосистема и вечная потребность в расширении функциональности (например, при разработке интегрированных средств поиска по документам предприятия) создают массу сложностей при проектировании схем, оптимизации запросов и обработке транзакций.
Связанная с этим проблема — выбор способа развертывания сервисов на основе СУБД NoSQL, что традиционно осуществлялось локально и требовало инсталляции и администрирования. С переходом на облачную обработку данных соответствующие задачи передаются оператору облака, при этом обычно заключаются соглашения об уровне обслуживания, в которых могут быть указаны заданные значения быстродействия или доступности. В интересах провайдера облака предложить максимально привлекательные цели обслуживания, минимизируя при этом общую стоимость развертывания и поддержки конфигурации заказчика. Внедрение СУБД, рассчитанных на локальную установку, в облачных средах сопряжено с многочисленными трудностями, обусловленными совместным доступом многих пользователей облака к оборудованию: контроль приватности и безопасности приходится сочетать с одновременным выполнением условий соглашений об уровне обслуживания для всех заказчиков.
Еще одна область, представляющая интерес, — реализация системы управления данными в виде гибридного сервиса. Некоторые системы NoSQL работают только в облаке, но нередко предприятиям нужна гибридная модель, при которой часть сервиса действует локально. Реализация системы NoSQL в такой форме — задача сложная, поскольку нужно достичь баланса между общей стоимостью развертывания и обоспечением требуемого быстродействия, приватности и безопасности. Необходимо, чтобы общая стоимость владения системой NoSQL при фиксированном объеме данных уменьшалась пропорционально совершенствованию оборудования.
Универсальность
Некоторые специалисты по СУБД считают, что универсальность недостижима и для каждого класса приложений необходимо разрабатывать свои движки по обработке данных. Но внедрять слишком много платформ данных в пределах одного предприятия непрактично: наличие отдельной платформы для различных документных хранилищ, приложений, работающих с ключами и значениями, поточными данными, а также для поддержки разных видов аналитической обработки (графы, реляционная модель и т. д.) усложнит администрирование, при этом вырастет общая стоимость развертывания, снизятся темпы внедрения новых приложений и сервисов, работающих с данными. При наличии N платформ данных накладные расходы на синхронизацию всех систем и обеспечение единства обзора данных предприятия растут со скоростью N2 . Одно из решений — объединение нескольких функционалов в одной системе NoSQL, например интеграция Apache Solr и Cassandra. Распространена также интеграция Hadoop с аналитическими системами: многие операционные базы NoSQL как минимум поддерживают возможность обмена данными с файловой системой HDFS.
Представляет также интерес исследование целесообразности еще более плотной конвергенции, и этот процесс уже идет, если судить по изменению позиционирования некоторых продуктов. В частности, MarkLogic изначально была системой управления XML-данными, а теперь у нее есть функции NoSQL; СУБД Couchbase начиналась как хранилище данных, а затем приобрела черты документного хранилища.
Еще одна проблема, достойная изучения, — компромиссы между быстродействием и функциональностью, на которые приходится идти по мере роста масштаба платформы NoSQL и приобретения ею дополнительных функций, уже предлагаемых другими системами.
Эталонные тесты и стандартизация
Появление в 1980-х годах э талонных тестов оценки реляционных СУБД заставило разработчиков этих систем сфокусироваться на производительности, что со временем принесло свои плоды. Аналогичные инициативы могут помочь и NoSQL, однако здесь имеются сложности с разработкой теста, точно воспроизводящего характеристики среды, в которой работает NoSQL-система, а также с получением поддержки тестов со стороны широкого круга поставщиков NoSQL-систем. Стоит отметить, что такие системы нередко классифицируют по следующим перекрывающимся подкатегориям: документные хранилища (MongoDB и MarkLogic), поколоночные хранилища (Cassandra и HBase) и хранилища пар «ключ-значение» (Aerospike, Couchbase, Oracle NoSQL, Redis и Riak). Для каждой подкатегории существуют свои сферы применения, однако не исключена возможность создания единого эталонного теста, который охватывал бы все сценарии, особенно с учетом прогнозируемой консолидации функционала СУБД NoSQL.
Для интерфейсов программирования и языков, применяемых для взаимодействия с операционными системами NoSQL, нужны стандарты — это еще одно направление исследований. Наличие стандартных интерфейсов сделает разработку приложений более или менее независимой от платформы данных, что позволит платформам управления данными развиваться быстрее. Стандарты языков можно было бы начать развивать с заимствованиями из SQL — многие соответствующие функции уже сегодня есть в новых языках запросов. Есть даже инициативы по созданию языков, целиком основанных на SQL; один из них — язык запросов СУБД Cassandra.
***
Понимание уникальных характеристик систем NoSQL, особенностей их эволюции и направлений дальнейшего развития позволяет выявить нерешенные проблемы и подтолкнуть сообщество к их решению. Исследователи в области СУБД сегодня активно занимаются задачами, связанными с проектированием, разработкой и развертыванием нереляционных систем, способствуя развитию коммерчески доступных решений.
Литература
- D. Feinberg, M. Adrian. The OLTP DBMS Market Becomes the Operational DBMS Market. Gartner, May 2013. URL: http://www.gartner.com/doc/2498715/oltp-dbms-market-operational-dbms (дата обращения: 18.09.2016).
- Aerospike. Large Data Types Guide. 2015. URL: http://www.aerospike.com/docs/guide/ldt_guide.html (дата обращения: 18.09.2016).
- DataStax. CQL for Cassandra: Using Collections. 2015. URL: http://www.datastax.com/documentation/cql/3.1/cql/cql_using/use_collections_c.html (дата обращения: 18.09.2016).
Джигнеш Пател ([email protected]) — профессор, Университет штата Висконсин.
Jigne?sh M. Patel, Operational NoSQL Systems: What’s New and What’s Next? IEEE Computer, April 2016, IEEE Computer Society. All rights reserved. Reprinted with permission.
NoSQL,Архитектуры для обработки транзакций,Системы поддержки принятия решений,Architecture for transaction processing, decision support systems
Поделитесь материалом с коллегами и друзьями
www.osp.ru
Использование современных СУБД в информационных системах АЭС
В различных сферах человеческой деятельности широкое распространение получили технологии, использующие базы данных для систематизации и хранения производственной информации. Структурированная информация легко анализируется и обрабатывается, а при условии хранения в базе, постоянно обновляется и дополняется, что позволяет говорить о её неизменной актуальности. Широкое распространение информационных систем, использующих базы данных, обусловлено также тем, что настоящий раздел информационных технологий имеет значительную степень внедряемости и на практике довольно гибко интегрируется под каждый конкретный случай, даже в условиях атомной индустрии. К тому же, в настоящее время существует немало всевозможных вариантов реализации баз данных (БД) и систем управления базами данных (СУБД). Термин «база данных» употребляется при обозначении информационной модель, целью создания которой является упорядоченное хранение информации, обладающей одинаковым набором свойств. Система управления базами данных, в свою очередь, является инструментальным средством для работы с базами данных.
СУБД работает с базами данных, построенными по определенным принципам. Наиболее приоритетные из них: целостность и отсутствие избыточности. Первому принципу отвечает необходимость обеспечения непротиворечивости данных, то есть физическую сохранность информации, предотвращение работы с недопустимыми значениями, контроль операций по работе с данными, защиту от несанкционированного доступа. Второй принцип продиктован необходимостью поддержания минимального количества повторяющейся информации, то есть любой элемент базы данных должен храниться в единственном числе.
Системы управления базами данных отличаются друг от друга функциональностью, производительностью, стоимостью и рядом других признаков, что порождает следующие виды классификаций.
Системы управления базами данных по типу управляемой БД:
Иерархические;
Сетевые;
Реляционные;
Объектно-реляционные;
Объектно-ориентированные.
Иерархические модели базы данных реализуются средствами древовидных структур с корневыми сегментами, имеющими физический указатель на другие сегменты. Преимущество заключается в уменьшении избыточности данных. Основной недостаток: сложность представления реального мира в виде древовидной структуры. Модель считается устаревшей, используется крайне редко.
Сетевая модель базы данных использует формальные языки определения (DataDefinitionLanguage, DDL) и манипулирования (DataManipulationLanguage, DML) данными, предназначенные для работы с содержимым БД. Разграничение функций между DDL и DML привело к выделению языка управления транзакциями. В сетевой модели нет необходимости в корневой записи, однако ассоциации поддерживаются средствами физических указателей.
Реляционная модель базы данных обеспечивает ряд возможностей, облегчающих работу с базой данных. Описание данных ведется в соответствии с естественной структурой; обеспечивается математическая основа для интерпретации избыточности и непротиворечивости отношений, а также независимости данных от их физического представления. Главным элементом реляционной модели выступает отношение. Реляционная модель некоторой предметной области представляет собой набор отношений, изменяющихся во времени. Классическая модель предполагает наличие неделимости данных, хранящихся в полях записей таблиц. Развитие технологии обработки данных привело к появлению объектно-реляционных и объектно-ориентированных моделей.
Объектно-реляционная модель базы данных объединяет в себе черты реляционной и объектной моделей. Возникновение данной модели продиктовано тем, что реляционные базы плохо взаимодействуют с пользовательскими, нестандартными типами данных. Объектно-реляционная модель сохраняет табличную структуру, однако способ обработки некоторых полей таблиц может определяться программистом.
Объектно-ориентированная модель базы данных строится из объектов, хранящихся физически как строки или столбцы таблицы. В объектно-ориентированной модели важнейшая роль отводится объектам, на основе которых могут определяться другие объекты, по аналогии с принципом наследования в объектно-ориентированном подходе. Любой экземпляр реального мира представляется в виде объекта, который при создании получает уникальный идентификатор, не изменяемый на протяжении всего существования объекта. Объекты также имеют состояния и поведение. Состояние объекта — это набор значений его атрибутов. Поведение объекта — это набор методов, реализуемых над состоянием объекта. Множество объектов могут быть объединены в класс объектов. Преимуществом объектно-ориентированной модели является упрощенный код. Недостатком — тесная связь с применяемым языком программирования.
Системы управления базами данных по архитектуре и организации хранения данных:
Локальные;
Распределенные.
Локальные СУБД размещают компоненты системы на одном компьютере.
Распределенные СУБД соответственно размещают на двух и более компьютерах.
Системы управления базами данных по способу доступа к базе данных:
Файл-серверные;
Клиент-серверные;
Встраиваемые.
В файл-серверных системах файлы располагаются централизованно на файл-сервере СУБД. Ядро располагается на каждой клиентской установке. Доступ к данным осуществляется через локальную сеть. Синхронизация осуществляется посредством файловых блокировок. Преимуществом является низкая нагрузка на центральный процессор сервера. Недостатком — высокая загрузка локальной сети; затруднённость централизованного управления, а также обеспечения таких характеристик как надёжность, доступность и безопасность. Чаще всего файл-серверные СУБД применяются в локальных приложениях, системах с низкой интенсивностью обработки данных и низкими пиковыми нагрузками на БД. В настоящий момент файл-серверная технология считается устаревшей и используется для решения тривиальных задач.Примерами такой СУБД могут послужить MicrosoftAccess иParadox.
Клиент-серверные системы состоят из клиентской части (прикладная программа) и сервера СУБД. Клиент-серверные СУБД обеспечивают разграничение доступа между пользователями и мало загружают сеть и клиентские машины. Сервер является внешней программой, и по мере надобности его можно заменить другим. Недостатком клиент-серверных СУБД заключается в необходимости больших вычислительных ресурсов, потребляемых сервером. Примерами клиент-серверной СУБД являются Oracle, MSSQLServer, PostgreSQL, MySQL, ЛИНТЕР.
Встраиваемая система — это своего рода библиотека, которая позволяет хранить большие объёмы данных на локальной машине. Доступ к данным может происходить посредством языка SQL либо через особые функции системы управления. Встраиваемые СУБД быстрее обычных клиент-серверных и не требуют установки сервера, поэтому востребованы в локальном программном обеспечении, которое имеет дело с большими объёмами данных. Примерами встраиваемых систем может послужить SQLite, MicrosoftSQLServerCompact, ЛИНТЕР.
Основная задача информационной системы — повышение эффективности и качества бизнес-процессов, в том числе происходящих на атомных электростанциях. ИС также обеспечивают выполнение ряда задач:
эффективный мониторинг на всех этапах и процессах жизненного цикла;
оптимизация процессов при сооружении и эксплуатации атомных электростанций;
преемственности информации между этапами, процессами и проектами.
В настоящее время имеется достаточно много разработок информационных систем, ядром которых является база данных. Вопросам разработки и использования баз данных в информационных системах посвящены работы российских ученых [1,2,4].
Одним из ярких примеров внедрения ИС на АЭС является информационная система «База Данных Вывода из Эксплуатации ядерных и радиационно-опасных объектов», которая реализует технологию информационной поддержки вывода из эксплуатации ядерных и радиационно-опасных объектов [5].
В основе ИС лежит идея формирования на основе информационной модели радиационно-опасных объектов централизованного хранилища данных, что особенно важно для безопасного и эффективного вывода объекта из эксплуатации.
Система введена в эксплуатацию на Курской АЭС в ноябре 2013 года, за время работы получила множество одобрительных отзывов мировых экспертов.
Другим примером активного использования ИС в атомной индустрии может послужить ИС для проведения квалификации на сейсмостойкость электрооборудования системы управления защитой АЭС.
Основной задачей электрооборудования СУЗ АЭС является обеспечение безопасности функционирования АЭС при возникновении аварийных ситуаций, в частности, при сейсмических воздействиях. Структура базы данных для информационной системы была разработана в среде MS Access 2007.
Разработанная ИС позволила значительно снизить временные затраты на поиск информации, сократить объем бумажной документации, а также дала возможность проводить предварительную оценку стойкости оборудования к предъявленным требованиям.
ИС разработана для реакторов типа ВВЭР и в настоящее время эксплуатируется более чем на пятидесяти энергоблоках АЭС России и за рубежом.
Неоспоримая важность задач повышения уровня экономической эффективности при абсолютном соблюдении требований безопасности эксплуатации энергетических блоков определяет необходимость интеграции информационных систем с поддержкой баз данных на существующие и строящиеся атомные станции по всему миру.
Литература:
- Виштак Н. М. Тестирование как один из важнейших этапов создания информационных систем // Н. М. Виштак, А. Д. Шведченко // Технические науки — от теории к практике. — 2014. — № 36. — С. 17–22.
- Виштак О. В. Объектная модель хранилища данных информационно-аналитической системы вузовского центра дополнительного образования / О. В. Виштак, И. А. Штырова // Объектные системы. — 2011. — № 5 (5). — С. 49–52.
- Грибко В. М. Информационная система поддержки жизненного цикла оборудования при сооружении и эксплуатации АЭС/ В. М. Грибко // АТОМЭКС. — М., 2010. — № 1. — С. 59–63.
- Фролов Д. А. Анализ видов компьютерных обучающих систем для подготовки персонала промышленного предприятия и современных технологий их построения / Д. А. Фролов // Инновационные информационные технологии. — 2013. — Т. 1. № 2. — С. 431–434.
- Черников О. Г. Разработка базы данных для вывода из эксплуатации блоков ЛАЭС / О. Г. Черников, В. А. Шапошников, В. Л. Тихоновский [и др.] // Рациональное управление предприятием. — М., 2008. — № 1– С. 36–38
moluch.ru
Критерии выбора СУБД при создании информационных систем
Выбор системы управления баз данных (СУБД) представляет собой сложную
многопараметрическую задачу и является одним из важных этапов при разработке
приложений баз данных. Выбранный программный продукт должен удовлетворять как
текущим, так и будущим потребностям предприятия, при этом следует учитывать
финансовые затраты на приобретение необходимого оборудования, самой системы,
разработку необходимого программного обеспечения на ее основе, а также обучение
персонала. Кроме того, необходимо убедиться, что новая СУБД способна принести
предприятию реальные выгоды.
В данной статье по результатам анализа доступных источников, например [1-5],
делается попытка сформулировать требования или, иными словами, критерии при
выборе СУБД, приводится классификация требований/критериев. Очевидно, наиболее
простой подход при выборе СУБД основан на оценке того, в какой мере существующие
системы удовлетворяют основным требованиям создаваемого проекта информационной
системы. Более сложным и дорогостоящим вариантом является создание
испытательного проекта на основе нескольких СУБД и последующий выбор наиболее
подходящего из кандидатов. Но и в этом случае необходимо ограничивать круг
возможных систем, опираясь на некие критерии отбора. Вообще говоря, перечень
требований к СУБД, используемых при анализе той или иной информационной системы,
может изменяться в зависимости от поставленных целей. Тем не менее можно
выделить несколько групп критериев:
* Моделирование данных
* Особенности архитектуры и функциональные возможности
* Контроль работы системы
* Особенности разработки приложений
* Производительность
* Надежность
* Требования к рабочей среде
* Смешанные критерии
Рассмотрим каждую из этих групп в отдельности.
Моделирование данных.
* Используемая модель данных. Существует множество моделей данных;
самые распространенные — иерархическая, сетевая, реляционная,
объектно-реляционная и объектная. Вопрос об использовании той или иной модели
должен решаться на начальном этапе проектирования информационной системы.
* Триггеры и хранимые процедуры. Триггер — программа базы данных,
вызываемая всякий раз при вставке, изменении или удалении строки таблицы.
Триггеры обеспечивают проверку любых изменений на корректность, прежде чем эти
изменения будут приняты. Хранимая процедура – программа, которая хранится на
сервере и может вызываться клиентом. Поскольку хранимые процедуры выполняются
непосредственно на сервере базы данных, обеспечивается более высокое
быстродействие, нежели при выполнении тех же операций средствами клиента БД. В
различных программных продуктах для реализации триггеров и хранимых процедур
используются различные инструменты.
* Средства поиска. Некоторые современные системы имеют встроенные
дополнительные средства контекстного поиска.
* Предусмотренные типы данных. Здесь следует учесть два фактически
независимых критерия: базовые или основные типы данных, заложенные в систему,
и наличие возможности расширения типов. В то время как отклонения базовых
наборов типов данных у современных систем от некоего стандартного, обычно,
невелики, механизмы расширения типов данных в системах того или иного
производителя существенно различаются.
* Реализация языка запросов. Все современные системы совместимы со
стандартным языком доступа к данным sql-92, однако многие из них реализуют те
или иные расширения данного стандарта.
Особенности архитектуры и функциональные возможности.
* Мобильность. Мобильность – это независимость системы от среды, в
которой она работает. Средой в данном случае является как аппаратура, так и
программное обеспечение (операционная система).
* Масштабируемость. При выборе СУБД необходимо учитывать, сможет ли
данная система соответствовать росту информационной системы, причем рост может
проявляться в увеличении числа пользователей, объема хранимых данных и объеме
обрабатываемой информации.
* Распределенность. Основной причиной применения информационных
систем на основе баз данных является стремление объединить взгляды на всю
информацию организации. Самый простой и надежный подход — централизация
хранения и обработки данных на одном сервере. К сожалению, это не всегда
возможно и приходится применять распределенные базы данных. Различные системы
имеют разные возможности управления распределенными базами данных.
* Сетевые возможности. Многие системы позволяют использовать широкий
диапазон сетевых протоколов и служб для работы и администрирования.
Контроль работы системы
* Контроль использования памяти компьютера. Система может иметь
возможность управления использованием как оперативной памяти, так и дискового
пространства. Во втором случае это может выражаться, например, в сжатии баз
данных, или удалении избыточных файлов.
* Автонастройка. Многие современные системы включают в себя
возможности самоконфигурирования, которые, как правило, опираются на
результаты работы сервисов самодиагностики производительности. Данная
возможность позволяет выявить слабые места конфигурации системы и
автоматически настроить ее на максимальную производительность.
Особенности разработки приложений.
* Многие производители СУБД выпускают также средства разработки приложений
для своих систем. Как правило, эти средства позволяют наилучшим образом
реализовать все возможности сервера, поэтому при анализе СУБД стоит
рассмотреть также и возможности средств разработки приложений.
* Средства проектирования. Некоторые системы имеют средства
автоматического проектирования, как баз данных, так и прикладных программ.
Средства проектирования различных производителей могут существенно
различаться.
* Многоязыковая поддержка. Поддержка большого количества национальных
языков расширяет область применения системы и приложений, построенных на ее
основе.
* Возможности разработки web-приложений. При разработкеразличных
приложений зачастую возникает необходимость использовать возможности среды
internet. Средства разработки некоторых производителей имеют большой набор
инструментов для построения приложений под web.
* Поддерживаемые языки программирования. Широкий спектр используемых
языков программирования повышает доступность системы для разработчиков, а
также может существенно повлиять на быстродействие и функциональность
создаваемых приложений.
Производительность.
* Рейтинг tpc (transactions per cent). Для тестирования
производительности применяются различные средства, и существует множество
тестовых рейтингов. Одним из самых популярных и объективных является
tpc-анализ производительности систем. Фактически tpc анализ рассматривает
композицию СУБД и аппаратуры, на которой эта СУБД работает. Показатель tpc –
это отношение количества запросов обрабатываемых за некий промежуток времени к
стоимости всей системы.
* Возможности параллельной архитектуры. Для обеспечения параллельной
обработки данных существует, как минимум, два подхода: распараллеливание
обработки последовательности запросов на несколько процессоров, либо
использование нескольких компьютеров-клиентов, работающих с одной БД, которые
объединяют в так называемый параллельный сервер.
* Возможности оптимизирования запросов. При использовании
непроцедурных языков запросов их выполнение может быть неоптимальным. Поэтому
необходимо произвести процесс оптимизации запросов, т.е. выбрать такой способ
выполнения, когда по начальному представлению запроса путем его синтаксических
и семантических преобразований вырабатывается процедурный план выполнения
запроса, наиболее оптимальный при существующих в базе данных управляющих
структурах.
Надежность.
Понятие надежности системы имеет много смыслов – это и сохранность информации
независящая от любых сбоев, и безотказность работы системы в любых условиях, и
обеспечение защиты данных от несанкционированного доступа.
* Восстановление после сбоев. При возникновении программных или
аппаратных сбоев целостность, да и работоспособность всей системы может быть
нарушена. От того, как эффективно спланирован механизм восстановления после
сбоев, зависит жизнеспособность системы.
* Резервное копирование. В результате аппаратного сбоя может быть
частично поврежден или выведен из строя носитель информации и тогда
восстановление данных невозможно, если не было предусмотрено резервное
копирование базы данных, или ее части. Резервное копирование спасает и в
ситуациях, когда происходит логический сбой системы, например при ошибочном
удалении таблиц. Существует множество механизмов резервирования данных
(хранение одной или более копий всей базы данных, хранение копии ее части,
копирование логической структуры и т.д.). Зачастую в систему закладывается
возможность использования нескольких таких механизмов.
* Откат изменений. При выполнении транзакции применяется простое
правило – либо транзакция выполняется полностью, либо не выполняется вообще.
Это означает, что в случае сбоев, все результаты недоведенных до конца
транзакций должны быть аннулированы. Механизм отката может иметь различное
быстродействие и эффективность.
* Многоуровневая система защиты. Информационная система организации
почти всегда включает в себя секретную информацию, поэтому для предотвращения
несанкционированного доступа используется служба идентификации пользователей.
Уровень защиты может быть различным. Кроме непосредственной идентификации
пользователей при входе в систему может использоваться также механизм
шифрования данных при передаче по линиям связи
Требования к рабочей среде.
* Поддерживаемые аппаратные платформы.
* Минимальные требования к оборудованию.
* Максимальный размер адресуемой памяти. Поскольку почти все
современные системы используют свою файловую систему, немаловажным фактором
является то, какой максимальный объем физической памяти они могут
использовать.
* Операционные системы, под управлением которых способна работать
СУБД.
Смешанные критерии.
* Качество и полнота документации. К сожалению, не все системы имеют
полную и подробную документацию.
* Локализованность. Возможность использования национальных языков не
во всех системах реализована полностью.
* Модель формирования стоимости. Как правило, производители СУБД
используют определенные модели формирования стоимости. Например, стоимость
одного и того же продукта может существенно изменяться в зависимости от того,
сколько пользователей будет с ним работать.
* Стабильность производителя.
* Распространенность СУБД.
Даже если просто отмечать насколько хороши или плохи выделенные параметры в
случае каждой конкретной СУБД, то сравнение уже двух различных систем является
трудоемкой задачей. Тем не менее, четкий и глубокий сравнительный анализ на
основании вышеперечисленных критериев в любом случае поможет рационально выбрать
подходящую систему для конкретного проекта, и затраченные усилия не будут
напрасными. Перечень критериев поможет осознать масштабность задачи и выполнить
ее адекватную постановку.
Следует отметить, что по существующей практике решение об использовании той
или иной СУБД принимает один человек – обычно, руководитель предприятия, а он
может опираться отнюдь не на технические критерии. Здесь свою роль могут сыграть
такие, с технической точки зрения, незначительные факторы как рекламная
раскрутка компании-производителя СУБД, использование конкретных систем на других
предприятиях, стоимость. При этом последний фактор может трактоваться в двух
противоположных смыслах в зависимости от финансового состояния и политики
предприятия. С одной стороны, это может быть принцип, – чем дороже, тем лучше. С другой стороны – культивирование почти бесплатного использования продукта,
вплоть до “взлома” его лицензионной защиты. Очевидно, последний подход чреват
коллизиями и не может привести к успеху в долгосрочной работе.
www.internet-technologies.ru
1.5. Современные тенденции развития субд
1.5.1. Введение
В настоящее время в мире используется достаточно большое количество универсальных промышленных СУБД. Среди них можно выделить трёх несомненных лидеров (как по уровню развития технологий, так и по объему рынка — они вместе занимают более 90% мирового рынка СУБД). Это СУБД первого эшелона — Oracle, Microsoft SQL Server и IBM DB2.
Список СУБД второго эшелона довольно велик, сюда относят такие СУБД, как Sybase, Informix, Ingress, Adabas, Interbase, Progress, Postgres, Cache, Linter, Firebird, Teradata и т.д.
Существуют также небольшие СУБД для нишевых (специализированных) решений и постоянно появляются прототипы новых специализированных СУБД (объектно-ориентированные СУБД, ХML СУБД, СУБД для обработки потоковых данных, СУБД для работы с текстами и т.д.). Можно ли предсказать тенденции развития этих СУБД на ближайшие годы?
Да можно, особенно для СУБД первого и второго эшелона. Предсказывать эти тенденции можно двумя путями: исходя из теоретических исследований и отчетов аналитиков и крупных специалистов в области СУБД или анализируя текущее состояние и планы развития лидеров рынка СУБД.
1.5.2. Как предсказать тенденции развития субд
Раз в несколько лет собираются группы ведущих специалистов в области СУБД и устраивают обсуждение состояния отрасли, последних исследований в области СУБД.
После мозгового штурма создается отчет, в котором перечисляется множество интересных потенциальных направлений развития СУБД. Последним таким отчетом был так называемый Клермонтский отчет (май 2008).
До этого были Лоуэльский отчет 2003, Ассиломарский отчет 1996, отчет собрания в Лагуна-Бич 1989.
К сожалению, большая часть этих предсказаний так и остается нереализованной, т.к. производители СУБД имеют ограниченные ресурсы, работают в условиях жесткой конкуренции и определяют список новых возможностей своей СУБД исходя из собственных соображений.
Другой (прагматичный) подход к предсказанию тенденций основывается на анализе текущего состояния и планов развития лидеров рынка СУБД (Oracle, DB2, SQL Server). Дело в том, что жесткая конкуренция на рынке СУБД заставляет производителей СУБД тщательно отслеживать новые версии конкурентов и, по возможности, быстро реализовывать их в следующих версиях своих продуктов, иначе на рынке не выжить. Поэтому анализ состояния и перспектив развития таких СУБД, как IBM DB2 9.5 и следующая версия Cobra, MS SQL Server 2008 и Oracle 11.1 и 11.2 позволяет делать более реалистичные предсказания тенденций развития универсальных коммерческих СУБД.
1.5.3. Эволюционный подход
Однако, прежде чем говорить о тенденциях развития этих СУБД, надо понять, будут ли они существовать в дальнейшем и не умрут ли в ближайшем будущем. Дело в том, что в последние несколько лет появилась целая серия статей Майкла Стоунбрейкера и Ко, в которых провозглашается грядущая революция в области СУБД и предсказывается скорая кончина универсальных коммерческих СУБД.
Стоунбрейкер обосновывает это тем, что современные универсальные коммерческие СУБД постоянно увеличивают свой функционал без переписывания ядра, в результате чего становятся очень сложными (никто сегодня не знает и не использует весь имеющийся функционал), громоздкими, медленными и дорогими. Он предсказывает, что грядет эпоха специализированных СУБД (потоковых, XML, научных, для обработки текстов и т д), которые вытеснят существующие универсальные СУБД, в первую очередь, за счет своей быстроты и компактности.
Иллюстрируется это на примере нескольких стартапов (StreamBase, Vertica, ASAP, H-Store), которые показывают для специализированных решений (потоковая обработка, хранилища данных, научные исследования) производительность на 1-2 порядка выше, чем в современных промышленных дисковых СУБД.
Однако при ближайшем рассмотрении оказывается, что многие из этих поразительных результатов не совсем корректны. Так, при тестировании СУБД Vertica с поколоночным хранением данных используется огромная таблица (с более чем 200 колонками) из которой выбирают всего несколько колонок. Понятно, что при таком подходе традиционная СУБД работает намного медленнее, но любая операция выборки записей с разумным числом полей из этой таблицы на Vertica будет очень долгой. Автор этой статьи сам в свое время участвовал в разработке СУБД с векторным (по столбцам) хранением данных (проект АРИУС) и знает, сколько вычислительных ресурсов необходимо чтобы разбить таблицу на векторы, а потом из них по ссылкам собрать записи, и сколько длится обновление группы полей в такой записи.
Такие же некорректности есть и в других примерах. Так, Стоунбрейкер предлагает пожертвовать журналами транзакций, отказаться от одновременной работы пользователей, отказаться от случайных (Ad Hock) запросов, работать с базами, умещающимися целиком в оперативной памяти, всю логику приложения реализовывать внутри СУБД (в виде хранимых процедур) и т.д. Все это ради достижения высокой производительности за счет надежности, масштабируемости, безопасности и т.д. Конечно, такой подход вполне допустим для специализированных приложений, и эти прототипы могут иметь свои ниши и использоваться в специализированных проектах, но универсальных коммерческих СУБД, предназначенных для создания серьезных бизнес приложений они не вытеснят, так что в ближайшее время революции не будет.
Дело в том, что хотя производительность СУБД и важна, но пользователи выбирают СУБД, ориентируясь на совокупность характеристик. Обычно учитываются такие характеристики, как обеспечение высокой надежности и непрерывности работы, масштабируемость, безопасность, простота управления, простота разработки, возможность работы с большими БД, поддержка специальных схем, алгоритмов и типов данных (DW, OLTP, XML, GIS, тексты и т.д.), поддержка стандартов, поддержка национального языка. Кроме того, очень важна распространенность данной СУБД в стране, наличие и возможность обучения специалистов (администраторов, разработчиков), наличие большого числа удачных внедрений СУБД для приложений похожего типа (references) и т.д.
Здесь специализированные СУБД конкурировать с лидерами рынка не могут. Еще одним важным аспектом является то, что заранее очень трудно сказать, какой функционал СУБД понадобится заказчику в будущем. Сегодня он работает только с алфавитно-цифровой информацией, а завтра ему понадобится обработка в том же приложении документов, видео- или гео-информации. Часто мы видим, что системы, надежность работы которых вначале казалась не очень важной, вдруг становятся определяющими (конвейер остановился, т.к. система учета и контроля въезда/выезда транспорта дала сбой).
Поэтому в большинстве случаев навряд ли при выборе СУБД можно себе позволить заранее отказаться от какого-то функционала. Более того, уходит в прошлое время, когда приложение работало только с одним типом данных. Например, уже мало осталось чисто ГИС-систем. Система должна хранить не только карты и координаты объектов (ГИС-информацию), но и алфавитно-цифровые данные, описания состояния объектов, изображения объектов, документацию по объектам и т.д. Т.е. нужны универсальные СУБД, использовать несколько специализированных СУБД в этих случаях очень сложно и дорого.
При выборе СУБД заказчик, в первую очередь, ориентируется на опыт и рекомендации коллег по бизнесу. Неспециалисту сегодня сложно провести детальный анализ и выбор СУБД. А коллеги используют универсальные коммерческие СУБД. Учет опыта и рекомендаций коллег по бизнесу в своей стране или в родственных областях бизнеса за рубежом часто определяет выбор. И здесь также малоизвестные специализированные СУБД проигрывают лидерам рынка. Ну и конечно, важна надежность и известность фирмы-производителя СУБД. Сколько раз мы были свидетелями ухода с рынка производителей ПО, после чего приходилось переписывать все приложения, теряя время и деньги.
Исходя из всех этих соображений, заказчики и разработчики приложений, как правило, выбирают не просто СУБД, а платформу для разработки большого числа разнородных приложений. Что касается сложности и избыточного функционала универсальных СУБД — это, по-моему, не проблема. В каждый момент времени разработчик и администратор изучают и используют только тот функционал, который им нужен. Незнание объектно-ориентрованного подхода, работы с XML и текстом или средств администрирования кластера не мешают развернуть и использовать систему. Когда этот функционал понадобится, его можно легко освоить и начать использовать. Знать все и сразу не нужно.
Да, по мере появления нового функционала требования к оборудованию (память, процессоры, место на диске) растут, но они не так важны. Оборудование сегодня развивается настолько быстро, что намного опережает скорость роста требований СУБД. Я бы заметил, что новые версии ОС (особенно Windows) гораздо быстрее ужесточают требования к оборудованию, чем СУБД.
По мере развития ПО СУБД мы можем видеть, что требуется довольно много времени, чтобы важные новые возможности начали работать эффективно, быстро, надежно, без ошибок. Технологии становятся все сложнее и сложнее. Например, компания Oracle уже около 10 лет совершенствует реализацию средств работы в кластере (архитектура shared anything), IBM много лет «вылизывает» свой прекрасный оптимизатор запросов и т.д. Т.е. требуется время, ресурсы, которых у мелких стартапов нет, чтобы довести до ума сложные новые технологии. Только лидеры рынка могут позволить себе вкладывать в это огромные деньги, тем самым увеличивая разрыв. С нуля нельзя сделать хороший универсальный коммерческий продукт, а вот новые идеи и технологии, порожденные в стартапах, лидеры рынка умеют быстро воспринимать и реализовывать в своих продуктах, оставив стартап позади (или купив его вместе с технологией).
История развития СУБД показала, что часто выживают не те производители, которые первыми реализовали новые идеи, а те, кто имеет более мощный и агрессивный маркетинг. Побеждают не лучшие технологии, а деньги, маркетинг, правильная стратегия развития. И здесь лидеры рынка тоже сильнее. Они просто не допустят революции в области СУБД. Имея большие финансовые ресурсы и большое число разработчиков, лидеры быстро добавят новый функционал в свои СУБД, если надо, перепишут даже часть ядра. Поэтому конкурировать с ними сложно.
Единственное, что может повлиять на судьбу универсальных СУБД — это революционные изменения в оборудовании, которые могут привести к кардинальному изменению внутренней архитектуры СУБД (например, отказ от дисков и появление быстрой дешевой оперативной флеш-памяти или драматическое увеличение скорости передачи данных по сетям, превращающее множество разбросанных по всему миру компьютеров в один суперкомпьютер (сеть как компьютер)). Но это нам в ближайшие 5-7 лет не грозит. Так что кризиса пока нет, и можно смело предсказывать тенденции развития универсальных коммерческих СУБД Как уже упоминалось выше, появление важных новых возможностей у одного из конкурентов заставляет остальных немедленно их реализовать. Однако ситуация с разработкой новых возможностей у разных производителей выглядит по-разному.
При анализе новых возможностей последних версий СУБД DB2 и особенно MS SQL Server видно, что большинство из них были реализованы у Oracle недавно или несколько лет назад. (Раньше эту пальму первенства держала IBM.) Автору довелось поговорить с разработчиками из лабораторий IBM в Торонто, и на вопрос, почему они планируют реализовать в новой версии СУБД (тогда это был Viper) эти функции, а не иные, они ответили, что действуют по запросам пользователей. Понятно, что пользователи СУБД в своих запросах опираются на личный опыт (эксплуатация ограниченного круга своих приложений) или на то, что увидели у конкурентов. Поэтому такой подход к разработке (а он очевидно актуален и для Microsoft) заставляет их все время догонять лидера. Microsoft приходится еще сложнее, т.к. приходится параллельно реализовывать отсутствующий функционал в области безопасности и работы с большими БД.
В свою очередь, компания Oracle, имея СУБД с достаточно развитым функционалом, может себе позволить исследования по новым направлениям и реализацию принципиально новых подходов, таких как Enterprise GRID, машина баз данных, измерение времени в БД, Real Application Testing и т.д. Поэтому при определении тенденций развития мы будем ориентироваться на достижения лидеров рынка и, в первую очередь, Oracle 11g. Понятно, что каждая новая версия СУБД реализует несколько сотен крупных и мелких новых возможностей. Поэтому выбор будет достаточно субъективен, возможно, другие аналитики и специалисты расставили бы акценты по-другому. Я постарался из всего множества направлений отобрать дюжину, на мой взгляд, наиболее важных тенденций. Конечно же, список не полон, и тенденции не равнозначны по важности и сложности, но я постарался выделить основные тенденции. Прогноз не может быть на неограниченный срок. Я думаю, что эти тенденции будут актуальны на ближайшие годы (на 2-3 версии СУБД) — это приблизительно 5-7 лет.
studfile.net