Статья опубликована в рамках: XLVII Международной научно-практической конференции «Научное сообщество студентов: МЕЖДИСЦИПЛИНАРНЫЕ ИССЛЕДОВАНИЯ» (Россия, г. Новосибирск, 21 июня 2018 г.)
Наука: Информационные технологии
Скачать книгу(-и): Сборник статей конференции
дипломов
ВЫБОР СИСТЕМЫ УПРАВЛЕНИЯ БАЗОЙ ДАННЫХ ДЛЯ ШИНЫ МУЛЬТИПЛЕКСНОГО КАНАЛА ПЕРЕДАЧИ ДАННЫХ
Магистральный последовательный интерфейс (мультиплексный канал передачи данных): совокупность технических средств и правил, обеспечивающих обмен информацией между абонентами интерфейса последовательным кодом по общей информационной магистрали. Шина мультиплексного канала передачи данных (МКПД) является одной из самых распространенных шин, используемых в бортовой аппаратуре. На предприятии, где проходит обучение, была поставлена задача создания базы данных для сохранения записи обменов, которые «ходят» по шине. Текущий вариант представляет запись всех данных в файл текстового формата. В итоге, при продолжительной работе аппаратуры, текстовый файл получается объемом в несколько гигабайт. Так как это обычный текстовый файл, то стандартными средствами операционной системы такой файл открыть и использовать невозможно. Необходимы специальные программы для открытия файла, но даже они не могут обеспечить приемлемую скорость открытия файла, не говоря уже о том, что в таком файле необходимо находить нужную информацию и даже на современных машинах это происходит с очень большими временами, если программа просмотра такого большого файла не завершается аварийно. Поэтому необходимо создать такую базу данных, которая бы не занимала так много места на диске, обеспечивала комфортную скорость доступа к данным в базе.
MySQL – популярная система управления реляционными базами данных, которая разработана распространяется и поддерживается корпорацией Oracle. Как и другие реляционные системы, MySQL хранит данные в таблицах и использует язык структурированных запросов (SQL) для доступа к базе данных. В MySQL вы предварительно определяете свою схему базы данных на основе ваших требований и устанавливаете правила для управления отношениями между полями в ваших таблицах. Любые изменения в схеме требуют процедуры миграции, которая может привести к отключению базы данных или значительно снизить производительность приложения.
MongoDB – это открытая, нереляционная база данных, разработанная MongoDB, Inc. MongoDB хранит данные в виде документов в двоичном представлении BSON (Binary JSON). Связанная информация хранится вместе для быстрого доступа к запросам через язык запросов MongoDB. Поля могут варьироваться от документа к документу; нет необходимости декларировать структуру документов в системе – документы самоописаны. Если в документ необходимо добавить новое поле, то это поле можно создать, не затрагивая все другие документы в коллекции, не обновляя центральный системный каталог и не переводя систему в автономный режим. По выбору разработчика, валидация схемы может использоваться для обеспечения контроля за управлением данными над каждой коллекцией.
Модель данных документа MongoDB естественным образом сопоставляется с объектами в коде приложения, что упрощает разработку и использование разработчиками. Документы позволяют легко представлять иерархические отношения для хранения массивов и других более сложных структур. В отличии от MySQL и других реляционных баз данных, MongoDB построен на архитектуре распределенных систем, а не на монолитной конструкции с одним узлом. В результате MongoDB предлагает готовое масштабирование и локализацию данных с автоматическим очертанием и набор реплик для обеспечения постоянной готовности. Многие понятия в MySQL имеют близкие аналоги в MongoDB. Таблица ниже описывает общие понятия через MySQL и MongoDB.
Таблица 1.
Сравнение общих понятий баз данных
|
MySQL |
MongoDB |
|
ACID транзакции |
ACID транзакции |
|
Таблица |
Коллекция |
|
Строка |
Документ |
|
Столбец |
Поле |
|
Вторичный индекс |
Вторичный индекс |
|
JOINs |
Встроенные документы, функции агрегации ($graphLookup и $lookup) |
|
GROUP_BY |
Агрегационный конвейер |
Как и MySQL, MongoDB предлагает богатый набор функций и возможностей, намного превосходящих возможности простых хранилищ данных NoSQL. MongoDB имеет богатый язык запросов, высокофункциональные вторичные индексы (включая текстовый поиск и геопространственный), мощную платформу агрегации для анализа данных, фасетный поиск, обработку графиков и многое другое. В MongoDB также можно использовать эти функции для более разнообразных типов данных, чем реляционная база данных.
Таблица 2.
Общая сравнительная таблица
|
|
MySQL |
MongoDB |
NoSQL |
|
Open source |
Да |
Да |
Да |
|
ACID транзакции |
Да |
Да |
Нет |
|
Гибкая, широкая по возможности хранения модель данных |
Нет |
Да |
Частично: гибкие схемы, но поддержка только простых структур данных |
|
Управление схемой |
Да |
Да |
Нет |
|
Выразительные слияния, фасетный поиск, запрос по графам, мощные агрегации |
Да |
Да |
Нет |
|
Идиоматический, естественный язык для драйверов |
Нет |
Да |
Нет |
|
Горизонтальное масштабирование с контролем местоположения данных |
Нет |
Да |
Частично: нет контроля за местоположением данных |
|
Анализ и бизнес-аналитика |
Да |
Да |
Нет |
|
Безопасность корпоративного уровня и развитые инструменты управления |
Да |
Да |
Нет |
|
База данных как сервис на всех основных облаках |
Да |
Да |
Нет |
И MySQL, и MongoDB имеют богатый язык запросов. Ниже в таблицы представлены примеры запросов на обоих языках.
Таблица 3.
Примеры запросов
|
MySQL |
MongoDB |
|
INSERT INTO users (user_id, age, status) VALUES (‘bcd001’, 45, ‘A’) |
db.users.insert({ user_id: ‘bcd001’, age: 45, status: ‘A’ }) |
|
SELECT * FROM users |
db.users.find() |
|
UPDATE users SET status = ‘C’ WHERE age > 25 |
db.users.update( { age: { $gt: 25 } }, { $set: { status: ‘C’ } }, { multi: true; } |
Организации всех размеров используют MongoDB, потому что это позволяет им быстрее создавать приложения, обрабатывать самые разнообразные типы данных и более эффективно управлять приложениями в масштабе. Разработка упрощается, поскольку документы MongoDB естественным образом сопоставляются с современными объектно-ориентированными языками программирования. Использование MongoDB ликвидирует слой сложного объектно-реляционного сопоставления (ORM), который преобразует объекты в коде в реляционные таблицы. Гибкая модель данных MongoDB также означает, что ваша схема базы данных может развиваться со временем. Именно по этим причинам MySQL и другие реляционные базы данных добавили поддержку JSON. Однако простое добавление типа данных JSON не приносит разработчику преимущества производительности базы данных документов в MySQL. Потому что подход MySQL может отвлечь от производительности разработчика, а не улучшить его. Рассмотрим основные проблемы реляционных баз:
- Устаревшие реляционные непроизводительные издержки: даже с поддержкой JSON, пользователи все еще привязаны к слоям SQL/реляционной функциональности (в MongoDBдрайверы реализованы в методах и функциях, которые удобны для разработчиков и являются идиоматическими и естественными для языков программирования)
- Отсутствие механизма управления данными: MySQL не предлагает собственного механизма проверки схемы JSON, вставленной или обновленной в базе данных (в MongoDBпроверка схемы, основанная на стандарте IETF схемы JSON, позволяет разработчикам и администраторам баз данных определять и применять предписанную структуру схемы для каждой коллекции MongoDB)
- Жесткость схемы: пользователям MySQL по-прежнему необходимо определять схему для их реляционной базы данных. Если схема затем меняется для удовлетворения новым требованиям, то таблица блокируется для некоторых операций, пока существующие данные не будут скопированы в новую схему, требуя, чтобы приложения были в состоянии покоя при миграции схемы (в MongoDBразработчики и администраторы баз данных могут объединить гибкость полностью динамической схемы с элементами управления, необходимыми для некоторых приложений, для всех данных, хранящихся в базе, а не только для их подмножеств)
В итоге была выбрана СУБД MongoDB, так как она позволяет более гибко работать с документами – мы можем просто напрямую сохранять приходящие к нам данные с шины МКПД, а не строить таблицы и настраиваться связи между ними и тратить на эти действия большое количество времени. MongoDB поддерживает горизонтальное масштабирование, это важный пункт, так как со временем объем данных растет и, необходимо более оптимально хранить. В силу использования для хранения документов BSON формат, можно строить гибкие запросы в базу и получать различного рода выборки.
Список литературы:
- ГОСТ Р 52070-2003
- https://docs.microsoft.com/ru-ru/visualstudio/
- https://docs.mongodb.com/
- http://doc.qt.io/
дипломов
Оставить комментарий