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

Умение выбрать СУБД важно при разработке любого ПО. Мы собрали 10 систем управления базами данных и разобрались в их преимуществах.

Особенности выбора современных СУБД

03.08.2017 Константин Селезнев

На протяжении долгого времени доминировали реляционные СУБД.

Сам по себе реляционный подход оказался простым и удобным, что обеспечило его распространение среди разработчиков, а производители смогли выпустить зрелые продукты, пригодные для широкого использования: Oracle Database Server, IBM DB2, Microsoft SQL Server, Teradata, PostgreSQL, MySQL и MariaDB.

Возможности реляционных СУБД полностью соответствовали требованиям приложений того времени, однако появление информационных хранилищ и многомерного анализа данных разделило прикладные информационные системы на OLTP и OLAP, а для нужд последних появились специализированные СУБД, хотя и соответствующие идеологии реляционного подхода, но на уровне реализации имеющие существенные отличия: секционирование, поколоночное хранение, сжатие данных и т. д. Дальнейшее развитие технологий баз данных было стимулировано появлением принципиально новых прикладных задач, связанных с высоконагруженными системами, Большими Данными, потоковой аналитикой, социальными сетями и проч. Каждый новый класс задач требовал принципиально новых СУБД, и реляционные системы оказались неприменимы — излишняя функциональность и универсальность привели к слишком академичной архитектуре, плохо адаптируемой под требования конкретных приложений [1]. В новых СУБД уже на уровне архитектуры не было универсальности реляционного подхода SQL, богатого функционала, обязательной поддержки ACID и др. К сегодняшнему дню появилось большое количество различных систем класса NoSQL [2], способных решать самые разнообразные задачи, но и реляционные системы впитали в себя идеи NoSQL, породив системы NewSQL [3], сочетающие в себе достоинства реляционного и нереляционного подходов.

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

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

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

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

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

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

Выбор СУБД как процесс

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

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

Наконец, сами по себе параметры сравнения часто выглядят слишком расплывчато.

Пример сравнения связанных, но не сопоставимых критериев — оценка скорости работы двух СУБД.

На первый взгляд, все просто: на различных нагрузках выполняется тестовый прогон, а затем на основе полученных результатов принимается окончательное решение [4].

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

Еще большие сложности начинаются при сопоставлении функционала.

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

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

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

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

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

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

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

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

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

СУБД как часть проекта

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

Обзор современных реляционных СУБД - Студенческий портал

Таблица 1. Примеры СУБД, созданных как результат прикладных проектов

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

Таблица 2. Создавать или нет новую СУБД?

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

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

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

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

Некоторые современные СУБД (например, Vertica и VoltDB) стали результатом исследовательских проектов, в рамках которых был создан прототип будущей системы (C-Store — прототип Vertica, H-Store — прототип VoltDB), проверенный затем на реальных практических задачах. Однако для массового создания новых СУБД такой путь невозможен: далеко не каждая компания готова финансировать подобные исследовательские проекты.

Иррациональный мир современных СУБД

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

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

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

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

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

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

Примеры приложений, для которых требуется разработка специализированных СУБД:

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

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

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

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

***

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

Литература

Константин Селезнев (konstantin_seleznyov@relex.ru) — ведущий инженер-программист, группа компаний «РЕЛЭКС» (Воронеж).

Тестирование,NoSQL,Реляционные СУБД,Relational DBMS,benchmark

Поделитесь материалом с коллегами и друзьями

Источник: https://www.osp.ru/os/2017/03/13052702/

Базы данных. Прошлое и будущее

Мало кто будет спорить, что IT будущего неразрывно связано с использованием огромных баз данных.

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

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

Обзор современных реляционных СУБД - Студенческий портал

От прошлого к настоящему

Нет смысла охватывать историю баз данных, цепляясь за любое сходство, поэтому моментом появления баз данных будет не античное время, а 60-е годы 20 века.

Именно тогда компьютеры стали эффективным инструментом для коммерческих компаний, а организация COBASYL (COnference on DAta SYstems Language), создавшая в 1959 году язык COBOL и впоследствии наделив его возможностями для управления БД, помогла им управлять резко возросшими потоками информации.

К концу 60-х появилась первая сетевая модель данных, возникло понятие СУБД, а в 1974 году компания IBM стала работать над языком для System R. Так на свет появился SEQUEL (Structured English QUEry Language). Однако позже, когда стало известно, что такое название используется британской авиастроительной компанией, было решено немного сократить до привычного SQL.

С увеличением доступности компьютеров стали появляться ориентированные на простых пользователей БД (Paradox, RBASE 5000, RIM, Dbase III), API (ODBC, Excel, Access) и средства разработки (VB, Oracle Developer, PowerBuilder). Само-собой, тенденция охватила и интернет, на сегодняшний день эффективное взаимодействие с БД – негласное требование к любому ресурсу с более-менее динамической информацией.

Если говорить о компаниях, то на рынке установилось троевластие: практически вся власть в области баз данных распределена между IBM, Microsoft и Oracle.

Настоящее и будущее

До старта нового тысячелетия в IT доминировал реляционный подход к базам данных, однако необходимость повышать быстродействие неизбежно привела к развитию идеи NoSQL (not only SQL). Если вы с трудом представляете, что это и в чём разница, то перейдя по ссылке вы получите исчерпывающие ответы на все свои вопросы.

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

NoSQL подход позволяет избежать этих проблем за счёт отсутствия строгих информационных связей. Но тут возникает другая проблема – организация доступа.

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

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

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

Обзор современных реляционных СУБД - Студенческий портал

Рейтинг

Итак, рейтинг 10 наиболее популярных баз данных, согласно ресурсу DB-Engines, выглядит следующим образом:

Oracle;
MySQL;
Microsoft SQL Server;
PostgreSQL;
MongoDB;
DB2;
Cassandra;
Microsoft Access;
Redis;
SQLite.

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

Итого, 7 из 10 представителей рейтинга – реляционные базы данных, а также по одному экземпляру документоориентированной БД (MongoDB), с распределёнными значениями (Cassandra) и использующей подход «ключ-значение» (Redis). Таким образом, на сегодняшний день доминирование реляционных баз данных неоспоримо, но что будет завтра?

Для ответа на этот вопрос обратимся на этом же ресурсе к разделу тренды. Если брать отметки времени в более чем в 2 или 4 года, то наибольший рост демонстрирует подход с использованием теории графов.

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

На данный момент наиболее популярным представителем Time Series БД является InfluxDB.

А какие базы данных используете вы? И какая на ваш взгляд наиболее перспективная NoSQL БД?

Источник: https://geekbrains.ru/posts/databases_trends

Краткий обзор современных СУБД | World-X

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

MySQL – самая популярная СУБД в мире

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

Обзор современных реляционных СУБД - Студенческий портал

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

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

SQLite – СУБД для приложений

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

У SQLite отсутствует система пользователей, поэтому ее невозможно использовать в многопользовательских приложениях. Кроме того, она сравнительно медленно работает на запись.

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

Эта СУБД сейчас активно применяется, например, в играх для Android.

PostgreSQL – профессиональное решение

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

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

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

Источник: https://wd-x.ru/kratkij-obzor-sovremennyx-subd/

Топ 5 популярных систем управления базами данных (субд) в 2020 | info-comp.ru — it-блог для начинающих

Приветствую всех посетителей сайта Info-Comp.ru! Сегодня мы с Вами узнаем, какие системы управления базами данных (СУБД) являются самыми популярными в 2020 году. Иными словами, в этом материале представлен рейтинг популярности СУБД, и мы рассмотрим ТОП 5 баз данных, которые находится на вершине данного рейтинга.

Обзор современных реляционных СУБД - Студенческий портал

На чем основан данный рейтинг

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

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

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

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

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

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

Источник: https://info-comp.ru/top-popular-database-management-systems

Обзор систем управления базами данных (СУБД) для систем контроля и управления доступом (СКУД)

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

Источник: Журнал «Технологии Защиты» № 1, 2014

Терминология

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

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

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

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

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

Требования к СУБД, применяемым в СКУД

Какие же особенные требования следует предъявить к СУБД, используемой в СКУД с точки зрения пользователя?

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

Виды СУБД

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

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

Способы доступа к БД

Клиент-серверные СУБД.
Файл-серверные СУБД.
Встраиваемые СУБД.

В клиент-серверных СУБД (Microsoft SQL Server, Oracle, Firebird, PostgreSQL, InterBase, MySQL и др.)

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

Все промышленные СУБД на данный момент являются именно клиент-серверными.

В файл-серверных СУБД (Paradox, Microsoft Access, FoxPro, dBase и др.), наоборот,

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

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

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

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

Встраиваемые СУБД (SQLite, Firebird Embedded, Microsoft SQL Server Compact и др.)

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

Источник: https://www.parsec.ru/articles/obzor-sistem-upravleniya-bazami-dannykh-subd-dlya-sistem-kontrolya-i-upravleniya-dostupom-skud/

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

С появлением большого числа микрокомпьютеров был разработан ряд СУБД для персональных компьютеров. Наиболее успешной из них была dBase – продукт корпорации Ashton-Tate. Среди ранних персональных СУБД наиболее известны Rbase корпорации Microrim и Paradox от Borland.

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

Среди них можно выделить трех несомненных лидеров (как по уровню развития технологий, так и по объему рынка – они вместе занимают более 90% мирового рынка СУБД). Это СУБД первого эшелона – Oracle, Microsoft SQL Server и IBM DB2.

Список СУБД второго эшелона довольно велик, сюда относят такие СУБД, как Sybase, Informix, Ingress, Adabas, Interbase, Progress, Postgres, Cache, Linter, Firebird, Teradata и т.д.

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

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

Для решения этих проблем была разработана технология «клиентсервер». В основе этой технологии лежит принцип централизации хранения и обработки данных: вся обработка и хранение данных полностью перекладывается на сервер; машина-клиент посылает запросы, а сервер их выполняет и посылает ответы клиенту.

Рынок корпоративных серверных СУБД представлен Oracle, MS SQL, DB2, Sybase и InterBase. СУБД Oracle остается лидером на рынке хранилищ данных как в отношении доли рынка (48.6%), так и инноваций разработок.

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

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

Разделение и сжатие данных в Oracle существенно оптимизирует работу СУБД:
· сокращает время обработки запросов от минут до секунд;
· позволяет осуществлять доступ к критической информации 24 часа в сутки, 7 дней в неделю;

· позволяет управлять небольшими «порциями» данных;

· дает возможность экономически эффективно использовать хранилища данных.

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

Oracle Database 11g помогает компаниям хранить данные в надежной и защищенной от искажений базе данных, оставляя их доступными для существующих приложений.

Total Recall не требует внесения изменений в приложения или особых интерфейсов и обеспечивает оптимальное использование дискового пространства.

В конце восьмидесятых годов Sybase разработала SQL Server и продала его Microsoft. Одним из преимуществ SQL Server является простота его применения, в частности, администрирования. Основным языком запросов является язык Transact-SQL, созданный совместно Microsoft и Sybase.

Для обеспечения доступа к данным Microsoft SQL Server поддерживает ODBC (Open DataBase Connectivity – интерфейс взаимодействия приложений с СУБД).

Система SQL Server 2008 позволяет обращаться к данным из любого приложения, разработанного с применением технологий Microsoft.

NET и Visual Studio, или в пределах сервисно-ориентированной архитектуры и бизнес-процессов – через Microsoft BizTalk Server.

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

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

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

SQL Server 2008 имеет развитые средства создания корпоративной отчетности, позволяя без труда создавать отчеты любого размера и сложности, а также организовывать общий доступ к ним. Предоставить нужные сведения также можно с помощью развертывания отчетов в Интернете.

Средства упреждающей аналитики SQL Server 2008, основанные на мощном интеллектуальном анализе данных и тесно интегрированные с технологиями Microsoft BI (Microsoft Business Intelligence – бизнес-анализ в Microsoft), позволяют принимать взвешенные, обоснованные решения.
К их числу относятся:
· возможность оптимизировать прогнозирование за счет улучшенной поддержки временных рядов;
· улучшенные структуры интеллектуального анализа позволяют накладывать ряд фильтров, оставляя только необходимую практическую информацию;
· повышение информативности отчетов за счет увеличения детализации;
· встроенная поддержка контрольных значений позволяет легко разделять данные на группы для подтверждения правильности прогноза;
· новые средства перекрестной проверки дают возможность одновременно проверять точность и стабильность построенных моделей;
· средства прогнозирования можно интегрировать в любую точку жизненного цикла данных и в реальном времени отслеживать изменения скрытых тенденций.

В настоящее время разработано большое количество бесплатных СУБД. Наиболее популярными и распространенными среди них являются MySQL и PostgreSQL. Обе СУБД довольно динамично развиваются и повсеместно используются

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

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

В небольших фирмах и компаниях, в которых нет необходимости использовать сервер и закупать дорогостоящие базы данных типа «клиент-сервер», применяются локальные (настольные) СУБД. Основными представителями таких СУБД являются Microsoft Access, Paradox, Visual FoxPro и dBase.

Paradox и Access входят в офисные пакеты. СУБД Paradox, выпускаемая компанией Corel, входит в пакет WordPerfect Office. СУБД Access выпускается Microsoft и входит в состав MS Office.

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

Не нашли то, что искали? Воспользуйтесь поиском:

Источник: https://studopedia.ru/5_131302_obzor-sushchestvuyushchih-relyatsionnih-baz-dannih.html

SQLite, MySQL и PostgreSQL: сравниваем популярные реляционные СУБД

Перевод статьи «SQLite vs MySQL vs PostgreSQL: A Comparison Of Relational Database Management Systems»

Реляционные базы данных используются уже очень давно. Они стали популярными благодаря успешным реализациям реляционных моделей в системах управления, оказавшимся весьма удобными для работы с данными. В этой статье мы сравним три самые популярные реляционные системы управления базами данных (РСУБД): SQLite, MySQL и PostgreSQL.

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

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

Чтобы лучше разобраться в СУБД, ознакомьтесь с этой статьёй.

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

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

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

Отношения и типы данных

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

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

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

SQLite

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

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

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

INTEGER: целое со знаком, хранящееся в 1, 2, 3, 4, 6, или 8 байтах.

REAL: число с плавающей запятой, хранящееся в 8-байтовом формате IEEE.

TEXT: текстовая строка с кодировкойUTF-8, UTF-16BE или UTF-16LE.

BLOB: тип данных, хранящийся точно в таком же виде, в каком и был получен.

Note: для получения более подробной информации ознакомьтесь с документацией.

Преимущества

Файловая: вся база данных хранится в одном файле, что облегчает перемещение.

Стандартизированная: SQLite использует SQL; некоторые функции опущены (RIGHT OUTER JOIN или FOR EACH STATEMENT), однако, есть и некоторые новые.

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

Недостатки

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

Невозможность дополнительной настройки: опять-таки, SQLite нельзя сделать более производительной, поковырявшись в настройках — так уж она устроена.

Когда стоит использовать SQLite

Встроенные приложения: все портируемые не предназначенные для масштабирования приложения — например, локальные однопользовательские приложения, мобильные приложения или игры.

Система доступа к дисковой памяти: в большинстве случаев приложения, часто производящие прямые операции чтения/записи на диск, можно перевести на SQLite для повышения производительности.

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

Когда не стоит использовать SQLite

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

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

MySQL

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

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

TINYINT: очень маленькое целое.

SMALLINT: маленькое целое.

MEDIUMINT: целое среднего размера.

INT или INTEGER: целое нормального размера.

FLOAT: знаковое число с плавающей запятой одинарной точности.

DOUBLE, DOUBLE PRECISION, REAL: знаковое число с плавающей запятой двойной точности.

DECIMAL, NUMERIC: знаковое число с плавающей запятой.

DATETIME: комбинация даты и времени.

TIMESTAMP: отметка времени.

YEAR: год в формате YY или YYYY.

CHAR: строка фиксированного размера, дополняемая справа пробелами до максимальной длины.

VARCHAR: строка переменной длины.

TINYBLOB, TINYTEXT: BLOB- или TEXT-столбец длиной максимум 255 (2^8 – 1) символов.

BLOB, TEXT: BLOB- или TEXT-столбец длиной максимум 65535 (2^16 – 1) символов.

MEDIUMBLOB, MEDIUMTEXT: BLOB- или TEXT-столбец длиной максимум 16777215 (2^24 – 1) символов.

LONGBLOB, LONGTEXT: BLOB- или TEXT-столбец длиной максимум 4294967295 (2^32 – 1) символов.

Преимущества

Простота: MySQL легко устанавливается. Существует много сторонних инструментов, включая визуальные, облегчающих начало работы с БД.

Много функций: MySQL поддерживает большую часть функционала SQL.

Безопасность: в MySQL встроено много функций безопасности.

Мощность и масштабируемость: MySQL может работать с действительно большими объёмами данных, и неплохо походит для масштабируемых приложений.

Скорость: пренебрежение некоторыми стандартами позволяет MySQL работать производительнее, местами срезая на поворотах.

Недостатки

Известные ограничения: по определению, MySQL не может сделать всё, что угодно, и в ней присутствуют определённые ограничения функциональности.

Вопросы надёжности: некоторые операции реализованы менее надёжно, чем в других РСУБД.

Застой в разработке: хотя MySQL и является open-source продуктом, работа над ней сильно заторможена. Тем не менее, существует несколько БД, полностью основанных на MySQL (например, MariaDB). Кстати, подробнее о родстве MariaDB и MySQL можно из нашего интервью с создателем обеих РСУБД — Джеймсом Боттомли.

Когда стоит использовать MySQL

Распределённые операции: когда вам нужен функционал бо́льший, чем может предоставить SQLite, стоит использовать MySQL.

Высокая безопасность: функции безопасности MySQL предоставляют надёжную защиту доступа и использования данных.

Веб-сайты и приложения: большая часть веб-ресурсов вполне может работать с MySQL, несмотря на ограничения. Этот инструмент весьма гибок и прост в обращении, что только на руку в длительной перспективе.

Кастомные решения: если вы работаете над очень специфичным продуктом, MySQL подстроится под ваши потребности благодаря широкому спектру настроек и режимов работы.

Когда не стоит использовать MySQL

SQL-совместимость: поскольку MySQL не пытается полностью реализовать стандарты SQL, она не является полностью совместимой с SQL. Из-за этого могут возникнуть проблемы при интеграции с другими РСУБД.

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

Недостаток функций: в зависимости от выбора движка MySQL может недоставать некоторых функций.

PostgreSQL

PostgreSQL — это самая продвинутая РСУБД, ориентирующаяся в первую очередь на полное соответствие стандартам и расширяемость. PostgreSQL, или Postgres, пытается полностью соответствовать SQL-стандартам ANSI/ISO.

PostgreSQL отличается от других РСУБД тем, что обладает объектно-ориентированным функционалом, в том числе полной поддержкой концепта ACID (Atomicity, Consistency, Isolation, Durability).

Будучи основанным на мощной технологии Postgres отлично справляется с одновременной обработкой нескольких заданий. Поддержка конкурентности реализована с использованием MVCC (Multiversion Concurrency Control), что также обеспечивает совместимость с ACID.

Хотя эта РСУБД не так популярна, как MySQL, существует много сторонних инструментов и библиотек для облегчения работы с PostgreSQL.

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

bigint: знаковое 8-байтное целое.

bigserial: автоматически инкрементируемое 8-битное целое.

bit [(n)]: битовая строка фиксированной длины.

bit varying [(n)]: битовая строка переменной длины.

boolean: булевская величина.

box: прямоугольник на плоскости.

character varying [(n)]: строка символов фиксированной длины.

character [(n)]: строка символов переменной длины.

cidr: сетевой адрес IPv4 или IPv6.

circle: круг на плоскости.

double precision: число с плавающей запятой двойной точности.

inet: адрес хоста IPv4 или IPv6.

integer: знаковое 4-байтное целое.

interval [fields] [(p)]: временной промежуток.

line: бесконечная прямая на плоскости.

lseg: отрезок на плоскости.

money: денежная величина.

path: геометрический путь на плоскости.

point: геометрическая точка на плоскости.

polygon: многоугольник на плоскости.

real: число с плавающей запятой одинарной точности.

smallint: знаковое 2-байтное целое.

serial: автоматически инкрементируемое 4-битное целое.

text: строка символов переменной длины.

time [(p)] [without time zone]: время суток (без часового пояса).

time [(p)] with time zone: время суток (с часовым поясом).

timestamp [(p)] [without time zone]: дата ивремя (без часового пояса).

timestamp [(p)] with time zone: дата и время (с часовым поясом).

tsquery: запрос текстового поиска.

tsvector: документ текстового поиска.

txid_snapshot: снэпшот ID пользовательской транзакции.

uuid: уникальный идентификатор.

Преимущества

Полная SQL-совместимость.

Сообщество: PostgreSQL поддерживается опытным сообществом 24/7.

Поддержка сторонними организациями: несмотря на очень продвинутые функции, PostgreSQL используется в многих инструментах, связанных с РСУБД.

Расширяемость: PostgreSQL можно программно расширить за счёт хранимых процедур.

Объектно-ориентированность: PostgreSQL — не только реляционная, но и объектно-ориентированная СУБД.

Недостатки

Производительность: В простых операциях чтения PostgreSQL может уступать своим соперникам.

Популярность: из-за своей сложности инструмент не очень популярен.

Хостинг: из-за вышеперечисленных факторов проблематично найти подходящего провайдера.

Когда стоит использовать PostgreSQL

Целостность данных: если приоритет стоит на надёжность и целостность данных, PostgreSQL — лучший выбор.

Сложные процедуры: если ваша БД должна выполнять сложные процедуры, стоит выбрать PostgreSQL в силу её расширяемости.

Интеграция: если в будущем вам предстоит перемещать всю базу на другое решение, меньше всего проблем возникнет с PostgreSQL.

Когда не стоит использовать PostgreSQL

Скорость: если всё, что нужно — это быстрые операции чтения, не стоит использовать PostgreSQL.

Простые ситуации: если вам не требуется повышенная надёжность, поддержка ACID и всё такое, использование PostgreSQL — это стрельба из пушки по мухам.

Источник: https://tproger.ru/translations/sqlite-mysql-postgresql-comparison/

Разработчик	Лицензия	Написана на
Oracle	Oracle Corporation	Проприетарная	Assembly, C, C++
MySQL	Oracle Corporation	GPL v2 или проприетарная	C, C++
Microsoft SQL Server	Microsoft Corporation	Проприетарная	C, C++
PostgreSQL	PostgreSQL Global Development Group	Лицензия PostgreSQL (бесплатное ПО с открытым исходным кодом, либеральная лицензия)	C
MongoDB	MongoDB Inc.	Различные варианты лицензирования	C++, C, JavaScript
DB2	IBM	Проприетарная EULA	Assembly, C, C++
Microsoft Access	Microsoft Corporation	Пробное ПО
Redis	Salvatore Sanfilippo	Лицензия BSD	ANSI C

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

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

SQL-базы данных

1. Oracle

Особенности

2. MySQL

Особенности

3. Microsoft SQL Server

Особенности

4. PosgreSQL

Особенности

NoSQL-базы данных

5. MongoDB

Особенности

6. DB2

Особенности DB2 11.1

7. Microsoft Access

Особенности

8. Cassandra

Особенности выбора современных СУБД

Выбор СУБД как процесс

СУБД как часть проекта

Иррациональный мир современных СУБД

Литература

Базы данных. Прошлое и будущее

От прошлого к настоящему

Настоящее и будущее

Рейтинг

Краткий обзор современных СУБД | World-X

MySQL – самая популярная СУБД в мире

SQLite – СУБД для приложений

PostgreSQL – профессиональное решение

Топ 5 популярных систем управления базами данных (субд) в 2020 | info-comp.ru — it-блог для начинающих

На чем основан данный рейтинг

Обзор систем управления базами данных (СУБД) для систем контроля и управления доступом (СКУД)

Терминология

Требования к СУБД, применяемым в СКУД

Виды СУБД

Способы доступа к БД

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

SQLite, MySQL и PostgreSQL: сравниваем популярные реляционные СУБД

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

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

Отношения и типы данных

Популярные РСУБД

SQLite

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

Преимущества

Недостатки

Когда стоит использовать SQLite

Когда не стоит использовать SQLite

MySQL

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

Преимущества

Недостатки

Когда стоит использовать MySQL

Когда не стоит использовать MySQL

PostgreSQL

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

Преимущества

Недостатки

Когда стоит использовать PostgreSQL

Когда не стоит использовать PostgreSQL