что такое субд примеры
Системы управления базами данных¶
Система управления базами данных (СУБД) — совокупность программных и лингвистических средств общего или специального назначения, обеспечивающих управление созданием и использованием баз данных.
Основные функции СУБД¶
Обычно современная СУБД содержит следующие компоненты:
Классификации СУБД¶
По модели данных¶
Иерархические¶
Используется представление базы данных в виде древовидной (иерархической) структуры, состоящей из объектов (данных) различных уровней.
Между объектами существуют связи, каждый объект может включать в себя несколько объектов более низкого уровня. Такие объекты находятся в отношении предка (объект более близкий к корню) к потомку (объект более низкого уровня), при этом возможна ситуация, когда объект-предок не имеет потомков или имеет их несколько, тогда как у объекта-потомка обязательно только один предок. Объекты, имеющие общего предка, называются близнецами (в программировании применительно к структуре данных дерево устоялось название братья).
Иерархической базой данных является файловая система, состоящая из корневого каталога, в котором имеется иерархия подкаталогов и файлов.
Примеры: Caché, Google App Engine Datastore API.
Сетевые¶
Сетевые базы данных подобны иерархическим, за исключением того, что в них имеются указатели в обоих направлениях, которые соединяют родственную информацию.
Реляционные¶
Практически все разработчики современных приложений, предусматривающих связь с системами баз данных, ориентируются на реляционные СУБД. По оценке Gartner в 2013 году рынок реляционных СУБД составлял 26 млрд долларов с годовым приростом около 9%, а к 2018 году рынок реляционных СУБД достигнет 40 млрд долларов. В настоящее время абсолютными лидерами рынка СУБД являются компании Oracle, IBM и Microsoft, с общей совокупной долей рынка около 90%, поставляя такие системы как Oracle Database, IBM DB2 и Microsoft SQL Server.
Объектно-ориентированные¶
Управляют базами данных, в которых данные моделируются в виде объектов, их атрибутов, методов и классов.
Этот вид СУБД позволяет работать с объектами баз данных так же, как с объектами в программировании в объектно-ориентированных языках программирования. ООСУБД расширяет языки программирования, прозрачно вводя долговременные данные, управление параллелизмом, восстановление данных, ассоциированные запросы и другие возможности.
Объектно-реляционные¶
Этот тип СУБД позволяет через расширенные структуры баз данных и язык запросов использовать возможности объектно-ориентированного подхода: бъекты, классы и наследование.
Зачастую все те СУБД, которые называются реляционными, являются, по факту, объектно-реляционными.
В данном курсе мы будем, в первую очередь, гооврить об этом виде СУБД.
Примеры: PostgreSQL, DB2, Oracle, Microsoft SQL Server.
По степени распределённости¶
По способу доступа к БД¶
Файл-серверные¶
В файл-серверных СУБД файлы данных располагаются централизованно на файл-сервере. СУБД располагается на каждом клиентском компьютере (рабочей станции). Доступ СУБД к данным осуществляется через локальную сеть. Синхронизация чтений и обновлений осуществляется посредством файловых блокировок. Преимуществом этой архитектуры является низкая нагрузка на процессор файлового сервера. Недостатки: потенциально высокая загрузка локальной сети; затруднённость или невозможность централизованного управления; затруднённость или невозможность обеспечения таких важных характеристик как высокая надёжность, высокая доступность и высокая безопасность. Применяются чаще всего в локальных приложениях, которые используют функции управления БД; в системах с низкой интенсивностью обработки данных и низкими пиковыми нагрузками на БД.
На данный момент файл-серверная технология считается устаревшей, а её использование в крупных информационных системах — недостатком.
Примеры: Microsoft Access, Paradox, dBase, FoxPro, Visual FoxPro.
Клиент-серверные¶
Клиент-серверная СУБД располагается на сервере вместе с БД и осуществляет доступ к БД непосредственно, в монопольном режиме. Все клиентские запросы на обработку данных обрабатываются клиент-серверной СУБД централизованно. Недостаток клиент-серверных СУБД состоит в повышенных требованиях к серверу. Достоинства: потенциально более низкая загрузка локальной сети; удобство централизованного управления; удобство обеспечения таких важных характеристик как высокая надёжность, высокая доступность и высокая безопасность.
Примеры: Oracle, Firebird, Interbase, IBM DB2, Informix, MS SQL Server, Sybase Adaptive Server Enterprise, PostgreSQL, MySQL, Caché, ЛИНТЕР.
Встраиваемые¶
Встраиваемая СУБД — СУБД, которая может поставляться как составная часть некоторого программного продукта, не требуя процедуры самостоятельной установки. Встраиваемая СУБД предназначена для локального хранения данных своего приложения и не рассчитана на коллективное использование в сети. Физически встраиваемая СУБД чаще всего реализована в виде подключаемой библиотеки. Доступ к данным со стороны приложения может происходить через SQL либо через специальные программные интерфейсы (API).
Примеры: OpenEdge, SQLite, BerkeleyDB, Firebird Embedded, Microsoft SQL Server Compact, ЛИНТЕР.
Стратегии работы с внешней памятью¶
СУБД с непосредственной записью — это СУБД, в которых все измененные блоки данных незамедлительно записываются во внешнюю память при поступлении сигнала подтверждения любой транзакции. Такая стратегия используется только при высокой эффективности внешней памяти.
СУБД с отложенной записью — это СУБД, в которых изменения аккумулируются в буферах внешней памяти до наступления любого из следующих событий:
Такая стратегия позволяет избежать частого обмена с внешней памятью и значительно увеличить эффективность работы СУБД.
Какую СУБД выбрать и почему? (Статья 1)
Заметил, что когда спрашиваешь кого-нибудь, особенно на собеседовании, какие типы СУБД существуют, то первое что вспоминают многие – это реляционные базы данных, и NoSQL, а вот про разновидности часто забывают или не могут сформулировать их отличие. Поэтому начнем с простого перечисления наиболее используемых.
Нужно обязательно сделать ремарку, что некоторые крупные производители, имеют в своем арсенале несколько типов СУБД, как в виде отдельных продуктов, так и в виде внутренней реализации. Например, у Oracle на самом деле чего только нет, начиная с классической реляционной СУБД, продолжая с отдельным продуктом Oracle NoSQL Database, который может использоваться и как документная, и как колоночная, и как ключ-значение. Отдельное решение от того же Oracle, Autonomous Data Warehouse – это уже специализированное решение для хранилищ данных. Еще один отдельный продукт от Oracle – Oracle Graph Server для работы с графами, и еще много другого. Этому можно посвятить отдельную серию статей.
Реляционные СУБД
Начнем по порядку, классические, реляционные СУБД чаще всего используются для построения решений OLTP (Online Transaction Processing). В таких решениях СУБД работает с небольшими по размерам транзакциями, но идущими большим потоком, и при этом от системы требуется минимальное время отклика, а так же возможность, при определенных условиях, отменить любые изменения выполняемых в рамках транзакции. Если вы строите систему, в рамках которой требуется хранить значительное количество сущностей (таблиц), с различными типами связей между ними (один-к-одному, один-к-многим, многие-ко-многим), то это скорее всего про реляционные СУБД.
Когда выбирать реляционную СУБД
Один из основных признаков, который говорит о том что нужно выбирать реляционную СУБД – это высокая нормализация данных. Дополнительными признаками будет необходимость обработки большого кол-ва коротких транзакций, с большей долей операций на вставку
Когда не выбирать реляционную СУБД
Если предполагается хранить не структурируемые данные, или наоборот очень простые структуры типа ключ-значение, то лучше посмотреть в сторону документных СУБД и специализированных СУБД типа ключ-значение соответственно.
Так же один из признаков, что имеет смысл подумать не о реляционных СУБД, это такой факт как необходимость часто обновлять значения в одних и тех же строках. Обычно это обходится «дорого» в реляционных СУБД, и нужно применять «продвинутую магию» что бы делать это корректно.
Конечно, тут есть много «но», или «а если очень хочется», и других ситуаций, когда данные рекомендации можно игнорировать. Это нормально, особенно когда за дело берется эксперт, который знает как это сделать.
СУБД типа ключ-значение
Наверное один из самых простых типов СУБД. В упрощенном виде, это некая таблица с уникальным ключом и собственно связанным с ним значением, в котором может быть что угодно. Чаще всего такие СУБД используют для кэширования, т.к. они очень быстро работают, а это и не сложно, когда есть уникальный ключ, и запрос возвращает только одно значение. У некоторых представителей данных СУБД есть возможность работать полностью в памяти, а так же есть возможность задавать срок жизни записи, после истечения которого, записи будут автоматически удаляться.
Когда выбирать СУБД ключ-значение
Если СУБД будет использоваться для кэширования данных или для брокеров сообщений, то это очень подходящий тип. Так же, такая СУБД хорошо подходит для баз где нужно хранить достаточно простые структуры, и иметь к ним очень быстрый доступ.
Когда не выбирать СУБД ключ-значение
Если вы предполагаете хранить в базе данных много сущностей (таблиц), а у сущностей будут сложные структуры с разными типами данных. Так же, если вы предполагаете делать из этой таблицы сложные запросы которые возвращают множества строк.
Документные СУБД
Иногда встречаются мнения что модель данных в документных БД похожа на модель данных в объектно-ориентированных базах данных. В этом есть доля правды, единственная реальная разница между ними заключается в том, что базы данных документов только сохраняют состояние, но не поведение.
Так же, само название «документо-ориентированная» подчас вводит в заблуждение, и мне встречались коллеги, которые считали, что это база для систем документооборота. Нет, это не так.
Интересно, что документные СУБД развиваются достаточно активно, и сейчас некоторые из них, в том числе, поддерживают проверку схемы.
Известными представителями таких СУБД являются CouchDB, MongoDB, Amazon DocumentDB.
Когда выбирать документную СУБД
Если нужно хранить объекты в одной сущности, но с разной структурой. Если нужно хранит структуры, включая объекты, списки и словари, особенно в формате близкому к JSON.
На самом деле область применения документных СУБД очень широкая. Их можно использовать как компактную базу данных для отдельно взятого микро-сервиса, так и для вполне масштабных решений, в качестве хранилища состояний чего-либо.
Когда не выбирать документную СУБД
Не самое лучшее решение для реализации транзакционная модели, и точно не лучший вариант для формирования отчетности.
Графовые СУБД
Очень простой пример, это организация связей в различного типа социальных сетях, где нужно хранить связи между пользователями (узлами) по разным критериям (родственные связи, коллеги, общие интересы).
Когда выбирать графовые СУБД
Точно стоит обратить внимание на графовые СУБД, если строите какое-то подобие социальной сети, или реализуете систему оценок и рекомендаций. Ну и во всех случаях когда вы хорошо понимаете что такое графы, и для чего это нужно.
Когда не выбирать графовые СУБД
Практически во всех остальных случаях, кроме указанных выше, лучше воздержаться от использования графовых СУБД.
Колоночные СУБД
Колоночные СУБД очень похожи на реляционные. Они так же состоят из строк, которые имеют атрибуты, а строки группируются в таблицах. Различия в логических моделях несущественные, а вот на уровне физического хранения данных различия значительные.
Основные преимущества колоночных СУБД – эффективное выполнения сложных аналитических запросов на больших объемах, и легкое, практически мгновенное, изменение структуры таблиц с данными, плюс существенная компрессия и сжатие, которое позволяет значительно экономить место.
Когда выбирать колоночные СУБД
Когда не выбирать колоночные СУБД
Учитывая специфику колоночных СУБД, будет не эффективно ее использовать, если выборки достаточно простые, параметры выборки статичны, и если преобладают выборки по ключевым значениям. Так же, если количество строк в таблице, из которой делается выборка, меньше сотен миллионов строк, то скорее всего не будет большого преимущества, по сравнению с реляционной СУБД.
Нужно так же иметь ввиду, что в колоночных СУБД могут быть и другие ограничения. Например, может отсутствовать поддержка транзакций, а язык запросов может отличаться от классического SQL, и прочее.
Итоги
Важное замечание – не пытайтесь сразу все задачи решить в рамках одной СУБД. Это более чем нормально иметь несколько разных типов СУБД. Так же, не пытайтесь сразу определиться с производителем СУБД, или связать свою жизнь с одним конкретным брендом.
При выборе типа СУБД следует, прежде всего, исходить из типа решаемых задач, типов обрабатываемых данных, перспектив роста и масштабирования.
Обращайте так же внимание на популярность и наличие широкого круга разработчиков и средств разработки – это даст вам возможность, при необходимости, найти ответ на возникший вопрос быстро.
Итак, в таблице представленной ниже, кратко собрано то, что описано выше в статье.
Тип СУБД
Когда выбирать
Примеры популярных СУБД
Нужна транзакционность; высокая нормализация; большая доля операций на вставку
Oracle, MySQL, Microsoft SQL Server, PostgreSQL
Задачи кэширования и брокеры сообщений
Для хранения объектов в одной сущности, но с разной структурой; хранение структур на основе JSON
CouchDB, MongoDB, Amazon DocumentDB
Задачи подобные социальным сетям; системы оценок и рекомендаций
Neo4j, Amazon Neptune, InfiniteGraph, InfoGrid
Хранилища данных; выборки со сложными аналитическими вычислениями; количество строк в таблице превышает сотни миллионов
Vertica, ClickHouse, Google BigTable, Sybase \ SAP IQ, InfoBright, Cassandra
Надеюсь данная статья оказалась полезной.
В следующих статьях посмотрим на выбор между облачными и on-premise СУБД, платными и бесплатными, и многое другое.
Какую СУБД выбрать и почему? (Статья 2)
После публикации статьи “Какую СУБД выбрать и почему? (Статья 1)” ко мне поступили справедливые комментарии о том, что я не упомянул такие типы СУБД, как Time Series и Spatial. В этой статье я кратко опишу их и добавлю еще два типа — Search engines и Object-oriented (объектные).
Напомню, в предыдущей статье мы описали:
В заключении я традиционно добавлю сводную таблицу со всеми типами СУБД — теперь их девять. Если вас интересует только компактное обобщение (тип, когда выбирать, популярные СУБД этого типа), то можете просто пролистать в самый конец.
Time Series СУБД
Такие СУБД оптимизированы для хранения данных временных меток или временных рядов. Данные временных рядов могут содержать измерения или события, которые отслеживаются, собираются или объединяются в течение определенного периода времени. Это могут быть данные, собранные с датчиков отслеживания движения, метрики JVM из приложений Java, рыночные торговые данные, сетевые данные, ответы API, время безотказной работы процессов и т.д.
Данные хранятся с отметками времени (это ключевое), которые индексируются и записываются таким образом, чтобы можно было запрашивать данные этих временных рядов намного быстрее, чем при использовании классической реляционной базы данных.
Когда выбирать Time series СУБД
Основная область применения таких СУБД — это системы мониторинга, сбора телеметрии и финансовые системы.
Когда не выбирать Time series СУБД
Желательно воздержаться от применения такой СУБД для задач, не связанных с временными рядами и временными метками.
Объектные СУБД (Object-oriented)
Как следует из названия, такие СУБД оптимизированы под хранение и работу с объектами. Как и полагается в ООП, у таких объектов в СУБД также имеются свойства и методы. Так же в них реализованы инкапсуляция и полиморфизм. Основная цель использования объектных СУБД — избавить разработчиков, применяющих объектную модель программирования, от необходимости трансформировать объекты в таблицы, строки и их связи, и обратно.
Когда выбирать объектные СУБД
Честно говоря, я видел не так много успешных реализаций с использованием объектных СУБД. Тем не менее, объектные базы данных обычно рекомендованы для тех случаев, когда требуется высокопроизводительная обработка данных, имеющих сложную структуру, при этом разработка ведется с использованием языков объектно-ориентированного программирования.
Когда не выбирать объектные СУБД
Не выбирайте объектную СУБД, если вы планируете использовать классический язык SQL, если вы не используете ООП или если вы планируете в дальнейшем мигрировать с данной СУБД на другие. Если нет хорошего понимания ООП, в большинстве случаев лучше выбрать документо-ориентированные СУБД.
Search engine СУБД
Такой тип СУБД используется для организации полнотекстового поиска. Причем поиск может производиться по различным данным — это например, данные из других БД, e-mail, RSS-feed, текст, JSON, XML, CSV, и даже по документам PDF и MS Office. У Search engine СУБД свои оптимизированные подходы к индексированию данных. В том числе используются так называемые инвертированные индексы, для того, чтобы предоставлять практически real-time поиск. В разных СУБД данного типа могут использоваться свои языки запросов, отличающихся друг от друга.
Известные СУБД данного типа: Apache Solr, Elasticsearch, Splunk.
Когда выбирать Search engine СУБД
Подходят для организации быстрого полнотекстового поиска по различным источникам данных, как по структурированным, так и по слабо структурированным. Яркий пример — системы сбора логов и поиска по ним.
Когда не выбирать Search engine СУБД
Если поиск производится по ограниченному количеству полей структурированных данных.
Spatial СУБД
Этот тип СУБД оптимизирован и предназначен для работы с объектами определенными в геометрическом пространстве. Это могут быть простые объекты (точки, линии, многоугольники) или сложные (3D-объекты, топологические покрытия, линейные сети). В таких СУБД реализован набор специальных функций, позволяющих проводить с объектами операции создания, трансформации, измерения (расстояния, площади, объема), вычисления (пересечений \ соприкосновений) и выборки по определенным критериям. В таких СУБД существуют специальные индексы, оптимизирующие работу с объектами, и специальный стандартизированный SQL/MM язык.
Когда выбирать Spatial СУБД
Если строите GIS-решения. Если планируете не просто хранить, но и работать с геометрическими объектами на уровне СУБД.
Когда не выбирать Spatial СУБД
Если планируете просто хранить геометрические объекты в виде координат.
Заключение
Мы пополнили наш перечень типов СУБД еще четырьмя: Time series, Object-oriented, Search engines и Spatial. Это все еще не полный перечень, и в одной из следующих статей мы продолжим. Отдельно рассмотрим несколько крупных вендоров, которые предлагают сразу множество типов СУБД.
Тип СУБД
Когда выбирать
Популярные СУБД данного типа
Нужна транзакционность; высокая нормализация; большая доля операций на вставку
Задачи кэширования и брокеры сообщений
Для хранения объектов в одной сущности, но с разной структурой; хранение структур на основе JSON
Задачи подобные социальным сетям; системы оценок и рекомендаций
Хранилища данных; выборки со сложными аналитическими вычислениями; количество строк в таблице превышает сотни миллионов
Системы мониторинга, сбора телеметрии, и финансовые системы, с привязкой к временным меткам или временным рядам
Высокопроизводительная обработка данных, имеющих сложную структуру, с использованием языков объектно ориентированного программирования
Системы полнотекстового поиска
GIS-решения, работа с геометрическими объектами
Как выбрать СУБД для решения ваших задач?
Значительная часть программного обеспечения — будь то ПО для банков, страховых организаций, фондов, денежного рынка, платежных сервисов — разрабатывается на основе базы данных.
Но многие разработчики испытывают трудности при выборе подходящей БД: иногда лучший выбор действительно не очевиден. Если реляционные и нереляционные базы данных сразу приходят на ум, то о системах управления базами данных (СУБД) часто забывают или не знают разницу между ними.
Восполним этот пробел и простыми словами расскажем, какие решения существуют на рынке СУБД, из каких продуктов стоит выбирать и как сделать правильный выбор в соответствии с решаемыми задачами.
Вот список наиболее часто используемых СУБД:
В конце статьи приведена резюмирующая таблица с кратким описанием того, в каких случаях подходит конкретный тип СУБД и какие популярные решения существуют. Так что самые нетерпеливые могут перейти прямо к таблице.
Отметим, что у ряда крупных поставщиков имеется по нескольку типов СУБД — в виде отдельных продуктов или внутренних реализаций.
У Oracle, например, есть все: классическая реляционная БД; отдельный продукт Oracle NoSQL Database (нереляционная БД Oracle), применяющийся в качестве столбцовой, документной и базы данных типа «ключ — значение»; автономная база данных, ориентированная на хранилища данных; сервер для графов Oracle Graph Server и многие другие продукты.
Типы СУБД. Как выбрать правильный?
Реляционная СУБД
Это классическая система, которая чаще используется для создания OLTP-решений (обработка транзакций в реальном времени), когда СУБД работает с большим количеством маленьких транзакций. Системе требуется короткое время отклика и возможность отменять любые изменения, сделанные во время транзакции при определенных условиях.
Реляционная СУБД подойдет для создания системы, предназначенной для хранения значительного числа сущностей — таблиц — с различными типами отношений между ними (один к одному, один ко многим, многие ко многим).
Самые известные реляционные СУБД:
Когда следует выбирать реляционную базу данных?
Во-первых (1), при высокой нормализации данных. А во-вторых (2), при обработке большого количества коротких транзакций, среди которых немалый процент транзакций с вставкой.
Когда не следует выбирать реляционную СУБД?
Для хранения 1) неструктурированных данных и 2) очень простых структур «ключ — значение». Для первых лучше подойдет документная СУБД. А для вторых — специализированная СУБД типа «ключ — значение».
А еще 3) при необходимости часто обновлять значения в одних и тех же строках. Это дорого обойдется реляционной СУБД: чтобы сделать все корректно, понадобятся «танцы с бубном». Но при наличии умелого танцора (или когда вы точно знаете, как это делать) используйте реляционную СУБД.
Графовая СУБД
Это особый тип СУБД для работы с графами, их узлами и свойствами, а также произвольными отношениями между узлами.
Простой пример — создание приложений типа соцсетей, где нужно хранить соединения между пользователями (узлами) в соответствии с критериями: общие интересы, коллеги, родственники.
Самые известные графовые СУБД:
Когда следует выбирать графовую базу данных?
1) При создании соцсети или реализации рейтинговой и рекомендательной системы и 2) при глубоком понимании графов и их назначения.
Когда не следует выбирать графовую базу данных?
Почти во всех остальных случаях.
Документная СУБД
Документная или документоориентированная СУБД — это одна из самых популярных разновидностей нереляционных СУБД. В качестве базовой единицы логической модели данных у нее структурированный текст со специфическим синтаксисом (документ).
Считается, что модели данных документных и объектно-ориентированных БД аналогичны. Это так, хотя разница все же есть: документные БД не хранят поведение объектов, а только их состояние. Документные СУБД активно развиваются — некоторые даже поддерживают проверку схемы.
Самые известные документные СУБД:
Когда следует выбирать документную БД?
У документной СУБД широкий диапазон применения: от 1) компактной БД для одного микросервиса до 2) крупномасштабных решений в качестве хранилища состояния.
Лучше хранить объекты в одной сущности, но с разными структурами. Кстати, очень полезны они и 3) для хранения структур (включая объекты, списки и словари), особенно в JSON-подобном формате.
Когда не следует выбирать документную СУБД?
Документная система не подходит для реализации модели транзакций и, конечно, это не лучшее решение для формирования отчетов.
Столбцовая СУБД
Столбцовая СУБД очень непохожа на реляционную: хотя так же состоит из сгруппированных в таблицы строк с атрибутами и по логической модели мало чем от нее отличается — на уровне физического хранилища имеет существенные различия.
Реляционная СУБД хранит данные построчно. То есть для считывания значения конкретного столбца приходится считывать почти всю строку — от первого до этого столбца.
Столбцовая СУБД хранит данные по столбцам. То есть столбец предстает в виде отдельной таблицы. А считывание выполняется прямо из конкретного столбца. На самом деле работает очень быстро — протестировано на нескольких реализованных хранилищах данных.
Преимущества столбцовой СУБД:
Самые известные столбцовые СУБД:
Когда следует выбирать столбцовую БД?
1) При создании хранилища данных и осуществлении выборки со сложными аналитическими вычислениями. 2) Когда количество запрашиваемых строк превышает сотни миллионов.
Когда не следует выбирать столбцовую СУБД?
1) Когда количество строк в таблице, из которой делаются запросы, меньше сотен миллионов. Здесь у столбцовой СУБД перед реляционной преимуществ будет немного.
2) Когда запросы достаточно простые и со статичными параметрами. В этом случае — учитывая специфику системы — столбцовая СУБД будет неэффективна.
К тому же у столбцовой СУБД есть и другие ограничения. Например, язык запросов может отличаться от классического SQL или отсутствует поддержка транзакций.
СУБД типа «ключ — значение»
Это одна из простейших СУБД, что-то вроде таблицы с уникальным ключом и связанным значением, в котором может быть что угодно. Такие СУБД чаще всего используются для кеширования, потому что они быстры — ведь есть уникальный ключ и запрос возвращает только одно значение.
Некоторые СУБД типа «ключ — значение» полностью работают в памяти, а другие устанавливают для записи время жизни, по истечении которого запись автоматически удаляется.
Самые известные СУБД типа «ключ — значение»:
Когда следует выбирать БД типа «ключ — значение»?
Она идеальна, когда 1) необходимо кеширование данных или брокеры сообщений и когда 2) надо хранить довольно простые структуры с быстрым доступом к ним.
Когда не следует выбирать БД типа «ключ — значение»?
Когда 1) в БД хранится много сущностей (таблиц), имеющих сложные структуры с разными типами данных. Когда 2) надо выполнять сложные запросы, возвращающие много строк.
СУБД временных рядов
Эта СУБД оптимизирована для хранения данных с метками времени или данных временных рядов. Данные временных рядов содержат измерения или события, которые отслеживаются, собираются или объединяются за определенный период времени.
Это данные с датчиков отслеживания движения, метрики JVM из приложений на Java, данные о рыночной торговле, сетевые данные, ответы от API, время безотказной работы процесса и т. д.
Данные хранятся с метками времени — это ключевая особенность — и индексируются и записываются так, чтобы данные этого временного ряда запрашивались намного быстрее, чем при использовании в классической реляционной БД.
Самые известные СУБД временных рядов:
Когда следует выбирать СУБД временных рядов?
Основная область применения таких СУБД — мониторинг, обработка телеметрии и финансовые системы.
Когда не следует выбирать СУБД временных рядов?
Воздержитесь от использования такой СУБД в задачах, не связанных с временными рядами и метками времени.
Объектно-ориентированная СУБД
Эта СУБД предназначена для хранения и обработки объектов. Как и в ООП (объектно-ориентированном программировании), у этих объектов в СУБД есть свойства и методы. И они тоже реализуют инкапсуляцию и полиморфизм.
Главная цель применения объектно-ориентированной СУБД — облегчить жизнь разработчикам, использующим модель объектного программирования. Им не придется преобразовывать объекты в таблицы и строки со связями и обратно.
Самые известные объектно-ориентированные СУБД:
Когда следует выбирать объектно-ориентированную СУБД?
Вообще-то не доводилось видеть много успешных реализаций с такими СУБД. Объектно-ориентированные базы данных обычно рекомендуется использовать при 1) высокопроизводительных манипуляциях с объектами, имеющими сложную структуру.
В то же время разработка 2) предполагает применение объектно-ориентированных языков программирования. Объектно-ориентированные БД распространены в системах реального времени, архитектуре и инженерии для 3D-моделирования, телекоммуникациях и научных продуктах, молекулярной науке и астрономии.
Когда не следует выбирать объектно-ориентированную СУБД?
1) При использовании классического языка SQL, 2) когда не применяется ООП или 3) при переходе на другую БД. И 4) при отсутствии глубокого понимания ООП. Тогда стоит выбрать документную СУБД.
Поисковая СУБД
Этот тип СУБД используется для осуществления полнотекстового поиска. А также поиска по различным данным, например из других БД, электронной почты, RSS-канала, текста, JSON, XML, CSV и даже PDF и документам MS Office.
Поисковая СУБД имеет собственные оптимизированные подходы к индексированию данных, в том числе использование так называемых инвертированных и фасетных индексов для поиска почти в реальном времени.
Различные СУБД этого типа применяют разные языки запросов.
Самые известные поисковые СУБД:
Когда следует выбирать поисковую СУБД?
Идеальные примеры — подходящие для быстрого полнотекстового поиска в различных источниках данных системы сбора и поиска по журналам структурированных, полуструктурированных и неструктурированных данных.
Когда не следует выбирать поисковую СУБД?
При поиске по ограниченному числу полей структурированных данных.
СУПБД (система управления пространственными базами данных)
Этот тип СУБД оптимизирован для работы с объектами, определенными в геометрическом пространстве — как простыми (точки, кривые, многоугольники), так и сложными (3D-объекты, топологическое покрытие, линейные сети).
СУПБД имеет набор специальных функций для обработки создания, преобразования, измерения (расстояние, площадь, объем), вычисления (пересечение/контакт) и выбора на основе определенных критериев. И содержит специальные индексы, оптимизирующие обработку объектов, и особый стандартизированный язык SQL/MM.
Самые известные СУПБД:
Когда следует выбирать СУПБД?
При создании ГИС-решений — не только для хранения, но и для работы с геометрическими объектами на уровне СУПБД.
Когда не следует выбирать СУПБД?
Для хранения геометрических объектов в качестве координат.
Заключение
Определиться с выбором СУБД бывает нелегко, ведь их так много! Надеемся, вы немного прояснили для себя этот вопрос и теперь легко выберите подходящую.
Хотите создать сложное решение? Тогда понадобится несколько типов СУБД. И не торопитесь с выбором поставщиков СУБД: обычно это тема второстепенная.
Выбирайте тип СУБД на основе следующих трех факторов:
Обратите внимание на популярные СУБД — такой выбор гарантирует наличие большого разнообразия инструментов разработки и единомышленников, которые помогут быстро найти решение возникающих вопросов.
В таблице в сжатом виде собрано все, что описывалось в статье: