Система управления базами данных

Наиболее популярные СУБД

Различные рейтинги самых популярных СУБД возглавляют Oracle, MySQL, Microsoft SQL Server, PostgreSQL.

MySQL

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

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

Microsoft SQL Server

Как следует из названия, фирменная СУБД, разработанная Microsoft. Оптимальная для использования в операционных системах семейства Windows, однако может работать и с Linux.

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

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

PostgreSQL

СУБД PostgreSQL — еще одна популярная и бесплатная система. Наибольшее применение нашла для управления БД веб-сайтов и различных сервисов. Она универсальна, то есть подойдет для работы с большинством популярных платформ.

При этом PostgreSQL — объектно-реляционная СУБД, что дает ей некоторые преимущества над другими бесплатными СУБД, в большинстве являющимися реляционными.

Oracle

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

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

Индексы

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

Существует несколько видов индексов:

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

Что такое нереляционная база данных

Реляционная база данных не эффективна для хранения большого количества данных, таких как BigData. Нереляционная база данных является решением этой проблемы. Кроме того, нереляционная база данных также называется NoSQL, Эти базы данных могут хранить большие данные. Также возможно кластеризовать данные на несколько машин, чтобы снизить затраты на обслуживание.

Существуют различные типы нереляционных баз данных.

Базы документов — Хранить динамические данные. Они хранят данные в формате JavaScript Object Notation (JSON). Например. CouchDB, Монго

Базы данных столбцов — Чтение и запись данных столбца мудро. Это полезно в аналитике данных. Например. Апач Кассандра.

Значение ключа хранимых баз данных — Быстро и не очень настраиваемый. Например. Couchbase Server, Redis.

Кэш базы данных — Храните данные на диске или в кеше. Например. Memcache

Граф базы данных — состоят из узлов. Отношения создаются с использованием ребер. Например. Oracle NoSQL, Neo4J.

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

Реляционная модель базы данных состоит из трех частей:Структурная часть – описывает, какие объекты рассматриваются реляционной моделью. Реляционная база данных состоит из набора отношений. Схемой реляционной базы данных называется набор заголовков отношений, входящих в базу данных.Целостная часть – описывает ограничения специального вида, которые должны выполняться для любых отношений в любых реляционных базах данных. Это целостность сущностей и целостность внешних ключей.Манипуляционная часть – описывает два эквивалентных способа манипулирования реляционными данными – реляционную алгебру и реляционное исчисление.

Термины реляционных баз данных.

Реляционный термин	Описание
Отношение	Таблица
Заголовок отношения	Заголовок таблицы
Тело отношения	Тело таблицы
Атрибут отношения	Наименование столбца (поля)  таблицы
Кортеж отношения	Строка (запись) таблицы
Степень отношения	Количество столбцов таблицы
Мощность (кардинальность)  отношения	Количество строк таблицы
Домен	Базовый или пользовательский тип  данных

Первичные ключи

Строки в реляционной базе данных неупорядоченные. Для выбора в таблице конкретной строки создается один или несколько столбцов, значения которых во всех строках уникальны. Такой столбец называется первичным ключом.Первичный ключ (primary key) – является уникальным значением в столбце. Никакие из двух записей таблицы не могут иметь одинаковых значений первичного ключа.
По способу задания первичных ключей различают логические (естественные) ключи и суррогатные (искусственные).Логический ключ – представляет собой значение, определяющее запись естественным образом.Суррогатный ключ – представляет собой дополнительное поле в базе данных, предназначенное для обеспечения записей первичным ключом.

Значение реляционных баз данных

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

Персистентные данные

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

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

Резервное хранилище может быть организовано разными способами. Для большинства высокопроизводительных приложений (например, для текстовых процессоров) резервным хранилищем является файл, записанный в файловой системе. Однако для большинства промышленных приложений резервным хранилищем является база данных.

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

Параллельность

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

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

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

Транзакции также играют важную роль в обработке ошибок. Используя транзакции, можно внести изменение, и если возникнет ошибка при обработке этого изменения, выполнить откат, исправив ситуацию.

Интеграция

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

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

Традиционно для этого используется интеграция баз данных коллективного пользования (shared database integration) , при которой несколько приложений хранят свои данные в одной базе. Использование одной базы данных позволяет всем приложениям легко использовать данные другого приложения, а механизм управления параллельной работой базы данных обрабатывает запросы от нескольких приложений так, будто он обрабатывает запросы нескольких пользователей одного и того же приложения.

(Почти) стандартная модель

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

Логическое проектирование и оптимизация

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

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

OLAP системы характеризуются следующими признаками:

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

BDB (BerkeleyDB)

Таблицы типа BDB обслуживаются транзакционным обработчиком Berkeley DB, разработанным компанией Sleepycat. При создании таблиц данного типа формируются два файла: первый с расширением frm, в котором определяется структура базы данных, а второй с расширением db, в котором размещаются данные и индексы.

Особенности типа BDB:

• Для каждой таблицы ведется журнал. Это позволяет значительно повысить устойчивость базы и увеличить вероятность успешного восстановления после сбоя.
• Таблицы BDB хранятся в виде бинарных деревьев. Такое представление замедляет сканирование таблицы и увеличивает занимаемое место на жестком диске по сравнению с другими типами таблиц. С другой стороны, поиск отдельных значений в таких таблицах осуществляется быстрее.
• Каждая таблица BDB должна иметь первичный ключ, в случае его отсутствия создается скрытый первичный ключ, снабженный атрибутом AUTO_INCREMENT.
• Поддерживаются транзакции на уровне страниц.
• Подсчет числа строк в таблице при помощи встроенной функции count() осуществляется медленнее, чем для MyISAM, так как в отличие от последних, для BDB-таблиц не поддерживается подсчет количества строк в таблице, и MySQL вынужден каждый раз сканировать таблицу заново.
• Ключи не являются упакованными, и ключи занимают больше места.
• Если таблица займет все пространство на диске, то будет выведено сообщение об ошибке и выполнен откат транзакции. 
• Для обеспечения блокировок таблиц на уровне операционной системы в файл db в момент создания таблицы записывается путь к файлу. Это приводит к тому, что файлы нельзя перемещать из текущего каталога в другой каталог.
• При создании резервных копий таблиц необходимо использовать утилиту mysqldump или создать резервные копии всех db файлов и файлов журналов. Обработчик таблицы хранит незавершенные транзакции в файлах журналов, их наличие требуется при запуске сервера MySQL.

Особенности

• MVCC (англ. MultiVersion Concurrency Control) — многоверсионность данных для управления параллельными транзакциями.
• Секционирование.
• Автономные транзакции.
• Automatic Storage Management — автоматическое управление хранением файлов БД.
• Oracle Enterprise Manager — набор инструментов, предназначенных для управления и мониторинга СУБД Oracle и серверов, на которых они установлены.
• Пакеты.
• Поддержка последовательностей.
• Аналитические функции в SQL.
• Profile manager.
• Oracle Label Security.
• Streams.
• Advanced Queuing.
• Flashback Query.
• RAC (англ. Real Application Clusters).
• RAT (Real Application Testing) — позволяет значительно снизить затраты на испытание новой конфигурации программного или аппаратного обеспечения, так как способна точно воспроизвести на ней нагрузку рабочего сервера.
• Data Guard — технология, позволяющая создать резервный сервер, который может работать в паре с основным, снижая нагрузку на него, и который может автоматически заменить основной сервер в случае его отказа или планового отключения (есть вариант с постоянной доступностью резервного сервера для чтения — Active Data Guard).
• Total Recall — даёт возможность разгрузить базу данных от устаревшей, редко используемой информации, сохраняя при этом возможность доступа к ней, так что для пользователя базы данных это изменение остаётся незамеченным.
• Объектные типы (в смысле объектно-ориентированного подхода).
• Automatic Database Diagnostic Monitoring — автоматический мониторинг и диагностика баз для выявления проблем производительности и, возможно, автоматической корректировки (если таковая определена администратором).
• Подсказки для изменения плана выполнения запроса.

Стратегии работы с внешней памятью

СУБД с непосредственной записью

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

СУБД с отложенной записью

В таких СУБД изменения аккумулируются в буферах внешней памяти до наступления любого из следующих событий:

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

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

Подробности

Реляционная модель ориентирована на организацию данных в виде двумерных таблиц. Каждая реляционная таблица представляет собой двумерный массив и обладает следующими свойствами:

• Каждый элемент таблицы является одним элементом данных
• Каждый столбец обладает своим уникальным именем
• Одинаковые строки в таблице отсутствуют
• Все столбцы в таблице однородные, то есть все элементы в столбце имеют одинаковый тип
• Порядок следования строк и столбцов может быть произвольным

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

Состав СУБД

Обычно современная СУБД содержит следующие компоненты:

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

Литература

• Том Кайт. Oracle для профессионалов: архитектура, методики программирования и особенности версий 9i, 10g и 11g, 2-е издание = Expert Oracle Database Architecture: Oracle Database Programming 9i, 10g, and 11g Techniques and Solutions, Second Edition. — М.: «Вильямс», 2011. — 848 с. — ISBN 978-5-8459-1703-4.
• Сэм Р. Алапати. Oracle Database 11g: руководство администратора баз данных = Expert Oracle Database 11g Administration. — М.: «Вильямс», 2009. — 1440 с. — ISBN 978-5-8459-1592-4.
• Рик Гринвальд, Роберт Стаковьяк, Гэри Додж, Дэвид Кляйн, Бен Шапиро, Кристофер Дж. Челья. Программирование баз данных Oracle для профессионалов = Professional Oracle Programming. — М.: «Диалектика», 2007. — 784 с. — ISBN 978-5-8459-1138-4.

СУБД в СКУД

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

Производитель	СКУД	СУБД
Parsec	ParsecNET 3	Microsoft SQL Server (в поставке 2012 Express, заявлена поддержка версий 2008 R2 и выше) — центральная БД; SQLite — локальные базы рабочих станций.
Elsys	Бастион 2	Oracle (в поставке 11g Express), заявлена поддержка версий Oracle 12с, Oracle SE2, также может использоваться СУБД PostgreSQL 10 или Postgres Pro
Perco	S20	Firebird 2.0
НВП Болид	Орион ПРО	Microsoft SQL Server (в поставке 2012 Express), заявлена поддержка версий 2008/2012/2014
РусГард	RusGuard	Microsoft SQL Server (в поставке 2014 Express), заявлена поддержка версий 2014/2016
Равелин ЛТД	Gate	Microsoft Access
ПромАвтоматика Сервис	Сфинкс	MySQL
Кодос	ИКБ Кодос	Firebird
TSS	Семь Печатей	Firebird
Bosсh	Access PE	Microsoft SQL Server (рекомендуется версия 2014 Express Edition)
Honeywell	Pro-Watch	Microsoft SQL Server 2012/2014/2016
Siemens	SiPass	Microsoft SQL Server 2000
ААМ Системз	Apacs 3000	Firebird 2.5 (входит в комплект поставки), поддерживается также Microsoft SQL Server 2017
Lyrix	Borland Interbase 2007 (в комплекте поставки), поддержка Oracle 10g и Microsoft SQL Server 2005

Как видно, большинство производителей СКУД поставляют бесплатную версию промышленной клиент-серверной СУБД Microsoft SQL Server Express Edition и свободную (бесплатную) кроссплатформенную СУБД Firefird (примерно 50 на 50).

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

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

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

Вторая частая проблема — восстановление данных после сбоя. Здесь опять же на выручку приходит свежая резервная копия, но если её нет, или критично восстановление всех возможных данных, то потребуются дополнительные усилия. К счастью, в промышленных СУБД (чего не скажешь о старых файловых СУБД типа Paradox) такие явления происходят нечасто, их может вызвать разве что «умирающий» жёсткий диск или сбой электропитания. В этом случае потребуются услуги специалиста-администратора СУБД, который сможет с помощью встроенных в любую серьёзную СУБД инструментов восстановить максимум из возможного. Также следует учесть, что некоторые производители СКУД в рамках технической поддержки оказывают услуги по восстановлению баз.

Состав СУБД

Обычно современная СУБД содержит следующие компоненты:

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

Классификации СУБД

По модели данных

Примеры:

• Иерархические
• Сетевые
• Реляционные
• Объектно-ориентированные
• Объектно-реляционные

По степени распределённости

• Локальные СУБД (все части локальной СУБД размещаются на одном компьютере)
• Распределённые СУБД (части СУБД могут размещаться не только на одном, но на двух и более компьютерах).

По способу доступа к БД

Файл-серверные

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

Преимуществом этой архитектуры является низкая нагрузка на процессор файлового сервера.

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

На данный момент файл-серверная технология считается устаревшей, а её использование в крупных информационных системах — недостатком.

Примеры: Microsoft Access, Paradox, dBase, FoxPro, Visual FoxPro.

Клиент-серверные

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

Недостаток клиент-серверных СУБД состоит в повышенных требованиях к серверу.

Достоинства: потенциально более низкая загрузка локальной сети; удобство централизованного управления; удобство обеспечения таких важных характеристик, как высокая надёжность, высокая доступность и высокая безопасность.

Примеры: Oracle Database, Firebird, Interbase, IBM DB2, Informix, MS SQL Server, , PostgreSQL, MySQL, Caché, ЛИНТЕР.

Встраиваемые

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

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

Примеры: OpenEdge, SQLite, BerkeleyDB, Firebird Embedded, Microsoft SQL Server Compact, ЛИНТЕР.

Чем хороши и плохи нереляционные базы данных: главные достоинства и недостатки

По сравнению с классическими SQL-базами, нереляционные СУБД обладают следующими преимуществами:

• линейная масштабируемость – добавление новых узлов в кластер увеличивает общую производительность системы ;
• гибкость, позволяющая оперировать полуструктирированные данные, реализуя, в. т.ч. полнотекстовый поиск по базе ;
• возможность работать с разными представлениями информации, в т.ч. без задания схемы данных ;
• высокая доступность за счет репликации данных и других механизмов отказоустойчивости, в частности, шаринга – автоматического разделения данных по разным узлам сети, когда каждый сервер кластера отвечает только за определенный набор информации, обрабатывая запросы на его чтение и запись. Это увеличивает скорость обработки данных и пропускную способность приложения .
• производительность за счет оптимизации для конкретных видов моделей данных (документной, графовой, колоночной или «ключ‑значение») и шаблонов доступа ;
• широкие функциональные возможности – собственные SQL-подобные языки запросов, RESTful-интерфейсы, API и сложные типы данных, например, map, list и struct, позволяющие обрабатывать сразу множество значений .

Обратной стороной вышеуказанных достоинств являются следующие недостатки:

• ограниченная емкость встроенного языка запросов . Например, HBase предоставляет всего 4 функции работы с данными (Put, Get, Scan, Delete), в Cassandra отсутствуют операции Insert и Join, несмотря на наличие SQL-подобного языка запросов. Для решения этой проблемы используются сторонние средства трансляции классических SQL-выражений в исполнительный код для конкретной нереляционной базы. Например, Apache Phoenix для HBase или универсальный Drill.
• сложности в поддержке всех ACID-требований к транзакциям (атомарность, консистентность, изоляция, долговечность) из-за того, что NoSQL-СУБД вместо CAP-модели (согласованность, доступность, устойчивость к разделению) скорее соответствуют модели BASE (базовая доступность, гибкое состояние и итоговая согласованность) . Впрочем, некоторые нереляционные СУБД пытаются обойти это ограничение с помощью настраиваемых уровней согласованности, о чем мы рассказывали на примере Cassandra. Аналогичным образом Riak позволяет настраивать требуемые характеристики доступности-согласованности даже для отдельных запросов за счет задания количества узлов, необходимых для подтверждения успешного завершения транзакции . Подробнее о CAP-и BASE-моделях мы расскажем в отдельной статье.
• сильная привязка приложения к конкретной СУБД из-за специфики внутреннего языка запросов и гибкой модели данных, ориентированной на конкретный случай ;
• недостаток специалистов по NoSQL-базам по сравнению с реляционными аналогами .

Подводя итог описанию основных аспектов нереляционных СУБД, стоит отметить некоторую некорректность запроса «NoSQL vs SQL» в связи с разными архитектурными подходами и прикладными задачами, на которые ориентированы эти ИТ-средства. Традиционные SQL-базы отлично справляются с обработкой строго типизированной информации не слишком большого объема. Например, локальная ERP-система или облачная CRM. Однако, в случае обработки большого объема полуструктурированных и неструктурированных данных, т.е. Big Data, в распределенной системе следует выбирать из множества NoSQL-хранилищ, учитывая специфику самой задачи. В частности, для самостоятельных решений интернета вещей (Internet of Things), в т.ч. промышленного, отлично подходит Cassandra, о чем мы рассказывали здесь

А в случае многоуровневой ИТ-инфраструктуры на базе Apache Hadoop стоит обратить внимание на HBase, которая позволяет оперативно, практически в режиме реального времени, работать с данными, хранящимися в HDFS

Нереляционные СУБД находят больше областей приложений, чем традиционные SQL-решения

Источники

1. https://ru.wikipedia.org/wiki/NoSQL
2. https://aws.amazon.com/ru/nosql/
3. https://ru.bmstu.wiki/NoSQL
4. https://tproger.ru/translations/types-of-nosql-db/
5. https://habr.com/ru/sandbox/113232/

2019

Включение в продукты DeviceLock

22 октября 2019 года стало известно, что DeviceLock включил в свои продукты поддержку Postgres Pro и PostgreSQL. Подробнее .

Запуск программы сертификации специалистов по СУБД PostgreSQL

21 мая 2019 года Postgres Professional сообщил о запуске программы сертификации специалистов по СУБД PostgreSQL.

Программа сертификации предусматривает три уровня с возрастающей квалификацией:

1. «Профессионал»
2. «Эксперт»
3. «Мастер»

Для получения сертификата необходимо пройти тестирование в офисе компании Postgres Professional и набрать проходной балл. Материалом для подготовки могут служить авторские курсы Postgres Professional, доступные на сайте, а также регулярно читаемые в сертифицированных учебных центрах. Ежегодно слушателями курсов становятся более 500 человек.

Тест для первого уровня — «Профессионал» — включает в себя 50 вопросов по основам администрирования PostgreSQL и длится 75 минут. Поскольку для каждого релиза PostgreSQL характерны свои особенности администрирования, сертификация соотносится с конкретной версией СУБД. Например, на май 2019 года доступен тест для 10-ой версии PostgreSQL DBA1-10. Для прошедших тестирование на знание PostgreSQL 10 и желающих в будущем подтвердить свои навыки для 11-ой версии достаточно будет пройти короткое дополнительное тестирование, сфокусированное на отличиях продуктов.

Для получения сертификата уровня «Эксперт» понадобится успешно пройти уже три теста:

1. DBA2-10 (настройка и мониторинг PostgreSQL)
2. DBA3-10 (резервное копирование и репликация PostgreSQL)
3. QPT-10 (оптимизация запросов)

А переход на уровень «Мастер» предполагает выполнение практических заданий по работе с PostgreSQL. В дальнейших планах компании Postgres Professional – запуск программы сертификации для разработчиков приложений на PostgreSQL.

Иван Панченко прокомментировал запуск программы сертификации:

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

Совместимость с Live Universal Interface

15 апреля 2019 года компания ФОРС Телеком сообщила о появлении в экосистеме программно-инструментальных средств, совместимых с открытой платформой Postgres Pro/PostgreSQL конструктора пользовательских веб-интерфейсов к базам данных — Live Universal Interface (LUI). Подробнее здесь.

Совместимость с TerraLink xDE

12 марта 2019 года TerraLink сообщил, что TerraLink xDE поддерживает OC семейства Linux и СУБД PostgreSQL. Подробнее .