Коммерческие базы данных кратко

Обновлено: 07.07.2024

Существуют сотни баз данных SQL и NoSQL. Одни популярны, другие игнорируются. Некоторые просты и хорошо документированы, а некоторые сложны в использовании. Одни имеют открытый код, а другие проприетарные. Что, возможно, наиболее важно, некоторые масштабируемы, оптимизированы, высокодоступны, а некоторые сложно масштабировать или поддерживать.

Возникает естественный вопрос: какую базу данных выбрать? Чтобы ответить на него, мы должны решить, чего мы хотим достичь с помощью базы данных. Чтобы составить представление, необходимо ответить на следующие вопросы:

Нужен ли нам аналитический доступ к базе данных?
Нужно ли нам писать или читать в реальном времени?
Сколько таблиц / записей мы хотим сохранить?
Какая доступность нам нужна?
Нужны ли нам столбцы?
Сможем ли мы получить доступ к таблицам, отфильтрованным по столбцам или по строкам?

Принимая решение, нужно помнить, что может предложить та или иная база данных. Специфика каждой БД может отличаться, но в целом существует только несколько типов, в рамках которых мы можем достичь в основном одинаковых целей. Рассмотрим их подробнее.

Реляционные базы данных SQL

Если вы когда-либо работали с базами данных, скорее всего, вы начали с этого типа, потому что он самый популярный и распространенный. Такие БД позволяют хранить данные в реляционных таблицах с определенными столбцами определенного типа. Реляционные таблицы хороши для нормализации и объединения.

Достоинства:

Поддержка SQL
ACID-транзакции (атомарность, согласованность, изоляция и долговечность)
Поддержка индексации и разделения

Недостатки:

Плохая поддержка неструктурированных данных / сложных типов
Плохая оптимизация обработки событий
Сложное / дорогое масштабирование

Примеры: Oracle DB, MySQL, PostgreSQL.

Документно-ориентированные базы данных

Если мы не хотим объединять несколько таблиц для получения нужных данных, мы можем взглянуть на документно-ориентированные базы данных. Они позволяют хранить записи в формате JSON. В этом формате мы можем создать сложное значение для любого ключа и сразу включить всю структуру данных в одну запись.

Достоинства:

Нет привязки к схеме
Нет необходимости всегда писать все поля в каждой записи
Хорошая поддержка сложных типов
Подходит для OLTP

Недостатки:

Плохая поддержка транзакций
Слабая аналитическая поддержка
Сложное / дорогое масштабирование

Примеры: MongoDB.

Базы данных в оперативной памяти

Достоинства:

Недостатки:

Труднодостижимая надёжность
Дорогое масштабирование

Примеры: Redis, Tarantool, Apache Ignite.

Базы данных с широкими столбцами

Эти базы данных хранят данные в виде записей ключ / значение на жестком диске или твердотельном накопителе. Эти решения предназначены для достаточно хорошего масштабирования, чтобы управлять петабайтами данных на тысячах общих серверов в распределенной системе. Они представляют архитектуру SSTable. Эта архитектура была разработана для двух случаев использования: быстрый доступ к ключу и быстрая запись с высокой доступностью.

Достоинства:

Быстрая запись построчно
Быстрое чтение по ключу
Хорошая масштабируемость
Высокая доступность

Недостатки:

Примеры: Cassandra, HBase.

Столбчатые базы данных

Иногда нам нужно быстро получить доступ к данным не с помощью определенных ключей, а с помощью определенных столбцов. В этом случае лучше отказаться от построчной вставки и перейти к пакетной записи. Пакетная вставка позволяет столбчатым базам данных готовить данные для быстрого чтения по столбцам.

Достоинства:

Быстрое чтение столбец за столбцом
Хорошая аналитическая поддержка
Хорошая масштабируемость

Недостатки:

Примеры: Vertica, Clickhouse.

Поисковая система

Если мы хотим получить доступ к данным с помощью фильтра по любому значению и даже по любому слову в столбце, мы должны вспомнить про поисковые системы. Эти базы данных выполняют индексацию каждого слова в столбцах и позволяют выполнять полнотекстовый поиск. Они идеально подходят для хранения и анализа журналов или больших текстовых значений.

Достоинства:

Быстрый доступ по любому слову
Хорошая масштабируемость

Недостатки:

Подходит только для пакетных вставок
Плохая аналитическая поддержка

Примеры: Elastic.

Графовые базы данных

Для некоторых случаев подходят графовые структуры данных. Если ваши задачи требуют работы с графами, существуют специальные базы данных, которые удовлетворят ваши потребности.

Достоинства:

Структура данных графа
Управляемые отношения между сущностями
Гибкие конструкции

Недостатки:

Специальный язык запросов
Трудно масштабировать

Выводы

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

Если вы готовитесь к собеседованию, посмотрите также статью, в которой собраны 27 распространённых вопросов по SQL и ответы на них.

Виртуальная среда, обеспечивающая быстрый и надежный доступ к ресурсам из любой точки планеты, явилась катализатором развития различных форм электронного бизнеса. Одними из первых оценили преимущества Интернет компании, специализирующиеся на производстве и продаже различного рода баз данных. Созданием подобных баз с начала 80-х годов занималось множество зарубежных корпораций, главным продуктом которых была информация. Существовали фактографические базы данных, содержащие фактические сведения (прежде всего статистику), библиографическую информацию (сведения о документах) и полнотекстовые (полные тексты книг и статей из газет, журналов и сборников). С распространением Интернет информационный бизнес приобрел невиданные до того времени масштабы. К уже существовавшим гигантам информационной индустрии добавились молодые компании, среди которых наиболее заметны netLibrary и ScienceDirect. Для поставщиков информационных продуктов Сеть явилась идеальной средой ведения бизнеса: информационные корпорации обрели возможность вести круглосуточное обслуживание клиентов вне зависимости от их местонахождения. Потенциальный рынок одномоментно расширился до пределов всего земного шара. При этом появилась возможность оказывать информационные услуги клиентам напрямую, обходясь в большинстве случаев без привлечения посредников, в лице которых ранее выступали библиотеки.

Как и большинство бизнес-проектов, полнотекстовые базы данных обеспечивают для клиентов высокий уровень сервиса. Поисковый механизм позволяет осуществлять многоаспектный поиск с возможностью сочетания данных из разных полей. Разыскание может осуществляться по отдельным словам, словосочетаниям и точным фразам. Результаты поиска выдаются в виде списка библиографических записей с указанием всех необходимых элементов. Существует возможность формирования из общего перечня списка релевантных документов.

Пользование коммерческими базами осуществляется по предварительной подписке, которая оформляется, как правило, на один год. Технически доступ осуществляется по предварительно выданным имени пользователя и паролю или по IP-адресу. Последний способ наиболее выгоден для организаций, в частности, библиотек, поскольку позволяет предоставлять пользование такими базами данных с любых компьютеров, расположенных в учреждении (находящихся за одним IP-адресом).

В настоящее время стоимость доступа к полнотекстовым базам данных весьма высока. Серьезные затраты на сканирование и распознавание текста, описание и индексирование документов, приобретение лицензий от владельцев авторских прав делают себестоимость конечного продукта весьма высокой. Сравнительно малое число подписчиков заставляет владельцев электронных собраний держать высокие цены, дабы окупить собственные затраты и получить прибыль. При существенном повышении числа подписчиков стоимость доступа для каждого отдельного пользователя может быть значительно снижена (прямая аналогия с сотовой телефонией). Однако уже сегодня возможность получения огромного массива данных в любой точке земного шара, где есть доступ к Интернет, привлекает все более значительное число пользователей, среди которых безусловное лидерство держат крупные корпорации, деятельность которых основывается на анализе информации. Высокая стоимость доступа для остальных категорий пользователей несколько смягчается позицией традиционных библиотек (прежде всего университетских), которые в ряде случаев предпочитают подписку на полнотекстовые базы данных непосредственному приобретению книг и журналов в собственный фонд.

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

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

Среди множества современных универсальных промышленных СУБД сегодня можно выделить трех лидеров, занимающих более 90% мирового рынка СУБД. Это СУБД первого эшелона – IBM DB2, Microsoft SQL Server и Oracle. В список СУБД второго эшелона входят Adabas, Cache, Firebird, Informix, Ingress, Interbase, Progress, Postgres, Sybase, Teradata, ЛИНТЕР и ряд других. Существуют СУБД для нишевых решений, и постоянно появляются прототипы новых специализированных СУБД: объектно-ориентированные СУБД, ХML СУБД, СУБД для обработки потоковых данных, СУБД для работы с текстами и т.д.

Для формирования прогнозов развития отрасли, раз в несколько лет собираются группы ведущих специалистов в области СУБД и выпускают отчеты: Клермонтский отчет (май 2008) [1], Лоуэльский отчет 2003 [2], Ассиломарский отчет 1996 [3], отчет собрания в Лагуна-Бич 1989 [4]. Правда, большая часть этих предсказаний так и не сбывается – производители СУБД обычно руководствуются своими собственными соображениями. Более прагматичен подход к предсказанию тенденций на основе анализа текущего состояния и планов развития тройки продуктов, лидирующих на рынке СУБД, – анализ состояния и перспектив развития IBM DB2 9.5 и Cobra, MS SQL Server 2008 и Oracle 11.1 и 11.2 позволяет делать вполне реалистичные предсказания тенденций развития универсальных коммерческих СУБД.

Революции не будет

За последние несколько лет появилась серия статей Майкла Стоунбрейкера, в которых провозглашается грядущая революция в области СУБД и предсказывается скорая кончина универсальных коммерческих СУБД 8. Стоунбрейкер обосновывает свою позицию тем, что современные универсальные коммерческие СУБД постоянно увеличивают свой функционал без переписывания ядра, в результате чего становятся сложными (никто сегодня не знает и не использует весь имеющийся функционал), громоздкими, медленными и дорогими. Грядет, по мнению Стоунбрейкера, эпоха специализированных СУБД, которые вытеснят универсальные. Данное утверждение иллюстрируется на примере продукции нескольких стартапов (StreamBase, Vertica, ASAP, H-Store), демонстрирующих на специализированных применениях производительность на один-два порядка выше, чем современные промышленные дисковые СУБД.

При ближайшем рассмотрении оказывается, что многие из приведенных Стоунбрейкером результатов не совсем корректны. Например, при тестировании СУБД Vertica с хранением данных по колонкам используется таблица из более чем 200 столбцов, из которой выбирают всего несколько. Понятно, что здесь традиционная СУБД работает намного медленнее, но и любая операция выборки записей с разумным числом полей из этой таблицы на Vertica будет осуществляться не быстро. Стоунбрейкер предлагает пожертвовать журналами транзакций, отказаться от одновременной работы пользователей и от случайных (ad hoc) запросов, а также работать с базами, целиком размещающимися в оперативной памяти, всю логику приложения реализовывать внутри СУБД (в виде хранимых процедур) и т.д. – все ради достижения высокой производительности за счет надежности, масштабируемости и безопасности.

Производительность СУБД, безусловно, важна, но пользователи делают свой выбор, ориентируясь на совокупность характеристик: надежность и непрерывность работы, масштабируемость, безопасность, простоту управления и разработки, возможность работы с большими базами, поддержку специальных схем, алгоритмов и типов данных (OLTP, XML, геоданные, тексты и т.д.), поддержку стандартов и национального языка. Кроме того, очень важна распространенность данной СУБД в конкретной стране, наличие и возможность обучения, количество удачных внедрений и т.п. Здесь специализированные СУБД конкурировать с универсальными не могут.

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

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

Что касается сложности и избыточного функционала универсальных СУБД – это не проблема. В каждый момент времени пользователи применяют только нужный им функционал. Знать все и сразу не нужно – при необходимости можно освоить и начать применять тот функционал, который понадобится.

Требуется много времени, чтобы новые возможности начали работать быстро и без ошибок. Так, Oracle уже десять лет совершенствует архитектуру shared anything, которая предоставляет средства работы в кластере, а IBM улучшает оптимизатор запросов. Только лидеры рынка могут вкладывать огромные средства в долгосрочные проекты, а новые идеи и технологии, порожденные стартапами, они очень быстро воспринимают либо покупают новую компанию вместе с технологией. Единственное, что может повлиять на судьбу универсальных СУБД, – это революционные изменения в оборудовании, которые могут привести к кардинальному изменению внутренней архитектуры СУБД (например, отказ от дисков в пользу флэш-памяти или увеличение скорости передачи данных по сетям, превращающее множество разбросанных по всему миру компьютеров в один).

Десятка тенденций

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

Виртуализация и grid

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

Все диски объединяются в один виртуальный, на котором располагаются все данные всех приложений. Например, в Oracle GRID [9] диски объединены в Storage Grid, а компьютеры – в Database Grid (виртуальный сервер базы данных) и Application Grid (виртуальный сервер приложений). Для управления таким множеством элементов используется программа Grid Control, которая позволяет работать с множеством объектов как с единым целым.

Если для организации grid используются дешевые элементы (диски и компьютеры стандартной архитектуры), то стоимость такой вычислительной среды будет намного меньше, чем при использовании традиционных архитектур. Поскольку элементы виртуального диска или виртуального компьютера взаимозаменяемы, то система обладает повышенной надежностью и живучестью.

Виртуализация позволяет создавать вычислительный ресурс неограниченной мощности и не заботиться о том, на каких компьютерах в действительности работает приложение. Главное – запросить и получить нужный вычислительный ресурс. Система сама выполнит балансировку нагрузки для приложения, создаст, если надо, базу данных с учетом зеркалирования данных и снижения нагрузки по вводу/выводу, задействует столько элементов grid, сколько необходимо для обеспечения требуемой надежности и производительности.

Сегодня уже реализованы такие корпоративные grid первого поколения на решениях Oracle (Amazon, EDS ABNAMRO), а IBM активно проводит исследования в области grid для научных применений, продвигая инструментарий Globus Toolkit.

Основой Database GRID у Oracle является архитектура Real Application Clusters, реализующая подход shared disk (все узлы кластера одновременно работают с единой базой данных), похожую архитектуру реализует и СУБД IBM DB2 для z/OS.

Самоуправление, самодиагностика, самолечение

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

СУБД постоянно собирает информацию о своей работе, анализирует ее, принимает решения и либо автоматически их реализует (например, меняет размеры областей в памяти), либо информирует администратора о проблеме, рекомендует ему последовательность действий и после одобрения выполняет.

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

Тестирование изменений

ИТ-инфраструктура предприятий постоянно развивается, и в процессе работы приходится все время менять параметры СУБД и структуры данных, создавать новые объекты и т.д. Любое такое действие может привести к ухудшению или остановке работы, а уж переход на новую версию СУБД – хуже пожара. Единственная возможность решить эту проблему – позволить заранее проверить любые изменения на тестовой системе до их выполнения на промышленной системе.

Имеется много пакетов, позволяющих имитировать нагрузку на тестовой системе, однако они часто создают не реальную, а синтетическую нагрузку, и в результате многие проблемы так и остаются невыявленными. Функционал, аналогичный Oracle RAT (Real Application Testing), очевидно, будет реализован во всех СУБД – он позволяет на работающей системе захватить реальную нагрузку (с учетом времени выполнения, одновременности, зависимости операций) и воспроизвести ее на тестовой базе, не устанавливая там приложение. Захват и проигрывание нагрузки позволяют обнаружить появившиеся/пропавшие/изменившиеся после выполнения изменений ошибки, выявить проблемы снижения производительности как всей системы, так и отдельных запросов. После анализа результатов система дает рекомендации по улучшению работы SQL, позволяет попробовать различные варианты оптимизации работы. Откатывая тестовую базу назад, можно тестировать различные изменения и их совокупность. И только после того, как все проблемы выявлены и решены, можно выполнять изменения в производственной среде.

Максимальная доступность

Кроме того, появляются механизмы открытия резервной базы на чтение, в то время как она догоняет основную, что позволяет разгрузить производственную систему, вынеся на резервную базу операции построения отчетности, анализа и резервного копирования.

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

Измерения времени

Поддержка новых типов данных

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

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

Умные механизмы сжатия и дедупликации

Многие приложения хранят данные за большой период времени, а стоимость дискового пространства до сих пор довольно высока, в связи с чем большинство производителей реализовало механизмы сжатия данных. Однако это чревато накладными расходами, поэтому сегодня прослеживается тенденция к совершенствованию механизмов сжатия. Администратор должен иметь возможность выбора различных степеней сжатия, понимая, что за экономию места придется платить временем. Сжатие должно быть прозрачно для приложения – приложение не должно знать о том, сжаты ли данные. Иногда полезен механизм дедуплицирования, когда система сама выявляет дубли полей и хранит их только в одном экземпляре.

Совершенствование методов защиты

Сегодня все чаще механизм управления учетными записями пользователей выносится из отдельных СУБД и приложений в единую централизованную систему организации (Identity&Access Management). Это упрощает управление в масштабах организации и позволяет управлять учетными записями исходя из требований бизнеса. Совершенствуются методы аудита, будет появляться интегрированная среда сбора и анализа информации всей организации. Кроме того, интенсивно совершенствуются средства защиты данных, например быстро развивается механизм задания политик переопределения запросов на лету – запрос автоматически модифицируется в зависимости от разных параметров (имя приложения, время запуска на выполнение, имя пользователя, место поступления запроса и т.д.).

Еще одно перспективное направление – изоляция администратора от данных. Такие средства защиты, как Oracle Data Vault option, позволят выполнять все операции по администрированию, но не дают возможности видеть и менять данные.

СУБД в качестве кэша

Практически все универсальные коммерческие СУБД сегодня ориентированы на работу с дисками, что означает время отклика в несколько миллисекунд, однако для многих приложений требуется быстродействие на порядок выше. Достичь этого можно с помощью специальных СУБД, работающих в оперативной памяти (in memory).

Сегодня наметилась тенденция использования In memory СУБД в качестве высокоскоростных кэшей к дисковым СУБД, например, Oracle использует в таком качестве СУБД Times Ten, а IBM – СУБД SolidDB. Приложения, требующие высокого быстродействия и гарантированного времени отклика, практически работают с таким кэшем в памяти, который сам синхронизируется с дисковой СУБД. При этом размеры основной базы могут быть очень большими, но кэшируется по определенной политике только часть данных.

Облака и машины баз данных

Технология сloud computing притягивает сегодня все больше внимания, и СУБД должны уметь работать в такой среде и использовать ее для создания, хранения и резервного копирования файлов. Работа в облаках предъявляет повышенные требования к СУБД
с точки зрения защиты данных и разграничения доступа, а также с точки зрения масштабируемости. Поскольку управление системой идет через Сеть, да и вообще сам подход подразумевает минимальные усилия по управлению как инфраструктурой, так и самой СУБД, то, очевидно, понадобится еще больше совершенствовать средства администрирования и повысить самоуправляемость СУБД.

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

Обычно при росте объемов узким местом становятся каналы передачи данных между сервером базы и устройствами хранения, поэтому для увеличения пропускной способности часть операций по просмотру и выборке данных переносится на уровень ячеек хранения. Такая связка оборудования и специального ПО называется машиной баз данных [10], реализации которых сегодня предлагают такие компании, как Netezza, Datallegro и Teradata. Однако такие машины работают со специальным ПО и требуют специальной квалификации для разработки приложений, не используют универсальные СУБД, а универсальные СУБД не поддерживали архитектуру машин. Сейчас началось движение универсальных коммерческих СУБД в сторону машин баз данных, и примером такого сближения стала совместная разработка Oracle и HP – машина баз данных с ячейками хранения Exadata. n

Литература

A Conversation with Michael Stonebraker and Margo Seltzer, ACM Queue, Volume 5, Number 4, May/June 2007.

M. Stonebraker and U. Cetintemel. One Size Fits All: An Idea Whose Time has Come and Gone. In Proceedings of the International Conference on Data Engineering (ICDE), 2005.

Michael Stonebraker, Chuck Bear, etc. One Size Fits All? – Part 2: Benchmarking Results, 3rd Biennial Conference on Innovative Data Systems Research (CIDR) January 7-10, 2007, Asilomar, California.

Michael Stonebraker, Samuel Madden, Daniel J. Abadi, Stavros Harizopoulos, Nabil Hachem, Pat Helland. The End of an Architectural Era (It’s Time for a Complete Rewrite). Proceedings of VLDB, 2007, Vienna, Austria.

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

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

При анализе работы применяются лучшие практики и знания, накопленные администраторами СУБД, системы учатся реагировать проактивно, выявляют причины, а не следствия возникновения проблем.

HP Oracle Database Machine обеспечивает для обычных приложений хранилищ данных Oracle ускорение обработки данных до 70 раз без переписывания приложений. В том же направлении движется Microsoft, купившая DATAllegro и интегрирующая ее продукты с SQL Server.

База данных (БД) –это совокупность массивов и файлов данных, организованная по определённым правилам, предусматривающим стандартные принципы описания, хранения и обработки данных независимо от их вида.

Основные классификации баз данных

Существует огромное количество разновидностей баз данных, отличающихся по различным критериям. Основные из них:

Классификация по модели данных

Центральным понятием в области баз данных является понятие модели.

Модель данных — это некоторая абстракция, которая, будучи приложима к конкретным данным, позволяет пользователям и разработчикам трактовать их уже как информацию, то есть сведения, содержащие не только данные, но и взаимосвязь между ними.

Виды:

Иерархическая.
Объектная и объектно-ориентированная.
Объектно-реляционная.
Реляционная.
Сетевая.
Функциональная.

1) Иерархическая база данных – каждый объект, при таком хранение информации, представляется в виде определенной сущности, то есть у этой сущности могут быть дочерние элементы, родительские элементы, а у тех дочерних могут быть еще дочерние элементы, но есть один объект, с которого все начинается. Получается своеобразное дерево. Примером иерархической базы данных может быть документ в формате XML или файловая система компьютера.

Следует сказать, что базы данных подобного вида оптимизированы под чтение информации, то есть базы данных, имеющие иерархическую структуру умеют очень быстро выбирать запрашиваемую информацию и отдавать ее пользователям. Но такая структура не позволяет столь же быстро перебирать информацию. Здесь можно привести первый пример из жизни: компьютер может легко работать с каким-либо конкретным файлом или папкой (которые, по сути, являются объектами иерархической структуры), но проверка компьютера антивирусам осуществляется очень долго. Второй пример – реестр Windows.

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

Объектные базы данных — это модель работы с объектными данными.

Такая модель баз данных, несмотря на то, что она существует уже много лет, считается новой. И её создание открывает большие перспективы, в связи с тем, что использование объектной модели баз данных легко воспринимается пользователем, так как создается высокий уровень абстракции. Объектная модель идеально подходит для трактовки такого рода объектных данных как изображение, музыка, видео, разного вида текст.

Объектно-ориентированная база данных (ООБД) — база данных, в которой данные моделируются в виде объектов, их атрибутов, методов и классов.

Объектно-ориентированные базы данных обычно рекомендованы для тех случаев, когда требуется высокопроизводительная обработка данных, имеющих сложную структуру.

2) Объектно-реляционные СУБД объединяют в себе черты реляционной и объектной моделей. Их возникновение объясняется тем, что реляционные базы данных хорошо работают со встроенными типами данных и гораздо хуже — с пользовательскими, нестандартными. Когда появляется новый важный тип данных, приходится либо включать его поддержку в СУБД, либо заставлять программиста самостоятельно управлять данными в приложении.

Не всякую информацию имеет смысл интерпретировать в виде цепочек символов или цифр. Представим себе музыкальную базу данных. Песню, закодированную в виде аудиофайла, можно поместить в текстовое поле большого размера, но как в таком случае будет ли осуществляться текстовый поиск?

3) Реляционная(или табличная) БД содержит перечень объектов одного типа, т.е. объектов с одинаковым набором свойств.

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

Столбцы такой таблицы называют полями; каждое поле характеризуется своим именем (названием соответствующего свойства объекта) и типом данных, которые это поле может хранить. Каждое поле обладает определенным набором свойств (размер, формат и т. п.). Т. о., поле БД — это столбец таблицы, содержащий значения определенного свойства объектов.

Строки таблицы являются записями. Записи разбиты на поля. Каждая строка таблицы содержит запись об одном единственном объекте, включая все его свойства.

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

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

5) Функциональные базы данных используются для решения аналитических задач: финансовое моделирование и управление производительностью. Функциональная база данных или функциональная модель отличается от реляционной модели. Функциональная модель также отличается от других аналогично названных концепций, включая модель функциональной базы данных DAPLEX и базы данных функциональных языков.

Функциональная модель является частью категории оперативной аналитической обработки (OLAP электронной таблице,), поскольку она включает многомерное иерархическое объединение. Но она выходит за рамки OLAP, требуя ориентирования ячейки, подобно тому, где ячейки могут быть введены или рассчитаны как функции других ячеек. Также, как и в электронных таблицах, данная модель поддерживает интерактивные вычисления, в которых значения всех зависимых ячеек автоматически обновляются каждый раз, когда изменяется значение ячейки.

Географическая.
Историческая.
Научная.
Мультимедийная.
Клиентская.
1. Классификация по степени распределённости:
Централизованная или сосредоточенная (англ. centralized database): БД, которая полностью поддерживается на одном компьютере.
Распределённая (англ. distributed database): БД, составные части которой размещаются в различных узлах компьютерной сети в соответствии с каким-либо критерием.
Неоднородная (англ. heterogeneous distributed database): фрагменты распределённой БД в разных узлах сети поддерживаются средствами более одной СУБД.
Однородная (англ. homogeneous distributed database): фрагменты распределённой БД в разных узлах сети поддерживаются средствами одной и той же СУБД.
Фрагментированная или секционированная (англ. partitioned database): методом распределения данных является фрагментирование (партиционирование, секционирование), вертикальное или горизонтальное.
Тиражированная (англ. replicated database): методом распределения данных является тиражирование.
1. Классификация БД по среде физического хранения:
БД во вторичной памяти (традиционные): средой постоянного хранения является периферийная энергонезависимая память (вторичная память) — это, как правило, жёсткий диск. В оперативную память СУБД помещает лишь кэш и данные для текущей обработки.
БД в оперативной памяти (in-memory databases): все данные находятся в оперативной памяти.
БД в третичной памяти (tertiary databases): средой постоянного хранения является отсоединяемое от сервера устройство массового хранения (третичная память), как правило, на основе магнитных лент или оптических дисков. Во вторичной памяти сервера хранится лишь каталог данных третичной памяти, файловый кэш и данные для текущей обработки; загрузка же самих данных требует специальной процедуры.

SQL

SQL — язык структурированных запросов, основной задачей которого является предоставление простого способа считывания и записи информации в базу данных.

Функции языка SQL:

Организация данных – создание и изменение структуры баз данных.
Чтение данных.
Обработка данных – удаление, добавление и корректировка данных.
Управление доступа к данным – предоставление привилегий (ограничение возможностей) пользователю для чтения и изменения данных.
Совместное использование данных — координация общего пользования данных многими пользователями.
Целостность данных – защита данных от разрушения при сбое системы или других обстоятельствах.

СУБД

Большинство современных СУБД построено на реляционной модели данных. Для получения информации из отношений (таблиц) базы данных в качестве языка манипулирования данными в теоретическом плане используется язык SQL

СУБД — система управления базами данных, совокупность программных и лингвистических средств общего или специального назначения, обеспечивающих управление созданием и использованием баз данных

Основные функции СУБД:

Управление данными во внешней памяти (на дисках).
Управление данными в оперативной памяти с использованием дискового кэша.
Журнализация изменений, резервное копирование и восстановление базы данных после сбоев.
Поддержка языков БД (язык определения данных, язык манипулирования данными).

Типы данных в SQL

Каждый столбец в таблице базы данных должен иметь имя и тип данных.

SQL разработчики должны решить, какие типы данных будут храниться внутри каждого столбца таблицы при создании таблицы SQL. Тип данных представляет собой метку и ориентир для SQL, чтобы понять, какой тип данных, как ожидается, внутри каждого столбца, а также определяет, как SQL будут взаимодействовать с хранимыми данными.

В следующей таблице перечислены общие типы данных в SQL:

SQL Data Type — Краткий справочник в разрезе БД

Тем не менее, различные базы данных предлагают различные варианты для определения типа данных.

В следующей таблице приведены некоторые из общих названий типов данных между различными платформами баз данных:

Читайте также: