Главная » Блоги Экспертов И ИТ-Компаний » Выбор СУБД: данные, индексы, запросы
Начинаем публикацию статей о практике внедрения СЭД 2 года назад

Выбор СУБД: данные, индексы, запросы

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

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

Важность соответствия модели данных отмечают и аналитики Gartner в отчете «Magic Quadrant for Operational Database Management Systems» (IDG00271405), опубликованном 12.10.2015. В отчете говорится, что в ближайшее время все ведущие вендоры СУБД предложат несколько моделей данных (реляционных и NoSQL), в рамках одной платформы. Также нас ожидает череда слияний и поглощений компаний вендоров СУБД с целью предложить конечным пользователям платформу, наиболее подходящую для решения задач. Аналитики также отмечают, что термин NoSQL перестанет употребляться.

Реляционные СУБД пока еще находятся на лидирующих позициях, но рейтинги показывают, что популярность нереляционных данных неуклонно растет. Например, согласно рейтингу популярности СУБД за 2015 год, размещенному на CITforum (http://citforum.ru/news/35020/) нереляционная MongoDB находится на 4-м месте. В десятку лучших вошли Cassandra и Redis (8 и 10 место соответственно).

Информационный ресурс DB-Engines составил свой рейтинг СУБД (http://db-engines.com/en/ranking). Из 315 представленных в списке СУБД, реляционными являются только 116. Суммарный объем рейтинговых баллов у группы реляционных СУБД пока в четыре раза больше, чем у группы нереляционных СУБД. Но, судя по тенденциям, это положение дел скоро изменится. Пока этого не произошло, прикладные разработчики выбирают СУБД, исходя из функциональных требований, предъявляемых к разрабатываемой информационной системе, а также модели данных, которые в ней используются.

Игроки рынка СУБД

Традиционные СУБД ориентируются на требования ACID к транзакционной системе: атомарность (англ. atomicity), согласованность (англ. consistency), изолированность (англ. isolation), надёжность (англ. durability), тогда как в NoSQL вместо ACID может рассматриваться набор свойств BASE:

  • базовая доступность (англ. basic availability) — каждый запрос гарантированно завершается (успешно или безуспешно).
  • гибкое состояние (англ. soft state) — состояние системы может изменяться со временем, даже без ввода новых данных, для достижения согласования данных.
  • согласованность в конечном счёте (англ. eventual consistency) — данные могут быть некоторое время рассогласованы, но приходят к согласованию через некоторое время.

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

Наиболее распространенные реляционные СУБД: MySQL, Oracle, Microsoft SQL Server. Существует достаточно большое количество классификаций видов СУБД, архитектура которых отличается от классической реляционной модели. Например, информационный ресурс DB-Engines, разделяет нереляционные СУБД на 14 групп (Content store, Document store, Event Store, Graph DBMS, Key-value store, Multi-model , Multivalue DBMS, Native XML DBMS, Navigational DBMS, Object oriented DBMS, RDF store, Search engine, Time Series DBMS, Wide column store).

Согласно информации, размещенной в википедии (https://ru.wikipedia.org/wiki/NoSQL), выделяют следующие 4 основные группы NoSQL решений:

  • «Ключ-значение». «Ключ-значение» является простейшим хранилищем данных, использующим ключ для доступа к значению. Такие хранилища используются, например, для создания специализированных файловых систем. Примеры таких хранилищ — Berkeley DB, MemcacheDB, Redis, Riak, Amazon DynamoDB.
  • Семейство колонок (или Bigtable-подобные базы данных). В этом хранилище данные хранятся в виде разреженной матрицы, строки и столбцы которой используются как ключи. Типичным применением этого вида СУБД является веб-индексирование, а также задачи, связанные с большими данными и с пониженными требованиями к согласованности данных. Примерами СУБД данного типа являются: Apache HBase, Apache Cassandra, Apache Accumulo, Hypertable, SimpleDB.
  • Документо-ориентированная СУБД. Документо-ориентированные СУБД служат для хранения иерархических структур данных и находят свое применение в системах управления содержимым, издательском деле и т.п. Примеры СУБД данного типа — CouchDB, Couchbase, MarkLogic, MongoDB, eXist, Berkeley DB XML.
  • База данных на основе графов. Графовые базы данных применяются для задач, в которых данные имеют большое количество связей, например, социальные сети. Примеры: Neo4j, OrientDB, AllegroGraph, Blazegraph (RDF-хранилище, ранее называлось Bigdata), InfiniteGraph, FlockDB, Titan.

Какие бывают данные

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

Возьмем для примера одну из задач документооборота – управление электронным архивом. Для того, чтобы электронный архив работал, необходимо организовать сбор, хранение удобный поиск и предоставление доступа к документам. Информационная модель содержит следующие взаимосвязанные группы данных (перечислим некоторые из них): пользователи (таблица), заявители (таблица), документ (объект), номенклатура дел (иерархия), организационная структура (иерархия), описи дел (таблица), дела (иерархия). Конечно, реальные данные обладают более сложной структурой, нежели «таблица» или «иерархия»: например, учетная запись пользователя – это не просто набор текстовых реквизитов, а сложный объект, включающий в себя разные виды данных (текст, ссылки на другие объекты, даты, числа, файлы и пр.) Но для того, чтобы реализовать практическую задачу приходится идти на такое «упрощение».

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

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

Данные

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

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

В своих проектах мы используем СУБД Cache, которая хранит и предоставляет доступ к данным с учетом их структуры: табличные данные имеют «SQL-проекцию», иерархические данные размещаются в «глобалах» и пр. СУБД предоставляет возможность организовать шесть способов доступа к данным: NoSQL key-value и document, а также column, graph, SQL и объектный доступ.

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

Индексы

СУБД не только «хранит», но и «ищет» данные. Чтобы искать данные нужно строить индексные файлы (временные структуры данных, позволяющие быстро понять, где размещена нужная информация). Например, если в списке сотрудников для каждой позиции указаны: «ФИО», «Дата рождения», «Паспортные данные», «Группа доступа», «Подразделение», «Должность» и пр. параметры (т.е. таблица состоит из 10 и более столбцов). Если индексирование не производится, то потребуется пройти последовательно все записи, пока не будет найдена нужная фамилия. Индексный файл для поиска «по фамилии» будет представлять собой таблицу только из двух столбцов: отсортированные по алфавиту фамилии и номер записи основного файла.

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

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

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

Язык запросов при обращении к СУБД

Обращение пользовательских приложений к базе данных выполняется с помощью запросов. Для реляционных СУБД используется структурированный язык запросов SQL. Для NoSQL - специализированные языки, учитывающие особенность хранимых структур данных. MongoDB использует BSON, eXist применяет XQuery, а Sonic GraphDB требует от разработчика знания GraphQL. Используются также GQL — SQL-подобный язык для Google BigTable, Gremlin — язык обхода графов,  Sones Graph Query Language — язык запросов к Sones Graph и пр. Реляционные СУБД могут предоставлять также возможность объектного доступа к данным. Но только используемая нами СУБД Cache предоставляет возможность организовать три варианта доступа: прямой, объектно-ориентированный и SQL. На практике это означает, что разработчик может выбирать наиболее эффективный способ доступа к данным, чтобы реализовать более быстрое конечное решение для пользователя.

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

Резюме

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

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

СУБД Cache позволяет создавать надежные и быстрые решения с низкими требованиями к аппаратным ресурсам, поскольку работает с разными моделями данных, не требует создания дополнительных структур хранения и позволяет работать с данными наиболее эффективным способом.

Аналитики Gartner уверены, что в ближайшее время все ведущие вендоры СУБД предложат несколько моделей данных в рамках одной платформы. Это означает, что InterSystems Cache получит ощутимое преимущество перед остальными игроками рынка. «Заточенные» под работу с определенными структурами данных, вендоры вынуждены вносить изменения на очень «низком уровне». А любое серьезное изменение, которое не было учтено при проектировании изначально, влечет за собой необходимость создания дополнительных структур данных и снижает скорость работы. Чем сложнее вносимые изменения, тем дольше будет производиться их отладка на конечных проектах.

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

InterSystems Cache предоставляет возможность работать с разными структурами данных уже сегодня. Технология работы с данными используется в реальных проектах уже более 30 лет, и, что очень важно, архитектура системы изначально была разработана с учетом возможности работы с различными структурами данных.


Данный материал является частной записью члена сообщества Club.CNews.
Редакция CNews не несет ответственности за его содержание.
Комментарии
Другие публикации
RU, Москва
+7 (495) 741-48-08
---

О компании

Компания ЛЕТОГРАФ занимается разработкой и внедрением одноименной системы управления документами, автоматизации бизнес-процессов и интеграции приложений. Основные направления деятельности - развитие платформы ЛЕТОГРАФ и реализация масштабных проектов внедрения.

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

О платформе ЛЕТОГРАФ

ЛЕТОГРАФ – готовое централизованное расширяемое решение для автоматизации документооборота и архива территориально-распределенных организаций. С помощью платформы ЛЕТОГРАФ могут быть решены все задачи по управлению документами: от «классического» документооборота и архива до управления корпоративным контентом (ЕСМ).

Масштабируемые отказоустойчивые решения на базе платформы ЛЕТОГРАФ устанавливаются централизованно на кластере серверов и реализуют на практике концепцию управления «большими данными». Пользователи работают с системой в интерфейсе веб-браузера и получают доступ к информации в режиме он-лайн со стационарных или мобильных устройств.

 

Система ЛЕТОГРАФ унифицирует работу со всеми электронными и бумажными документами организации (входящими, исходящими, внутренними, кадровыми, архивными, договорами, счетами, заявками и пр.), а также может быть интегрирована с корпоративными и внешними системами.

Адрес: Россия, 105066, г. Москва, ул. Бауманская, д. 6 

Контактное лицо: Александр Иванов, специалист по маркетингу


Забыл пароль?
Авторизоваться через
Зарегистрируйся сейчас!
Присоединяйся к нашему обществу для того чтобы познакомиться с новыми людьми, создать собственный блог, публиковать анонсы событий и объявления, а также участвовать в обсуждении публикаций CNews. Мы создали единое пространство для общения специалистов рынка информационных технологий и всех, кто интересуется современными технологиями. Регистрация =>