Механизм хранения данных может меняться на протяжении всего жизненного цикла приложения. Абсолютно нормально, когда от решения, которое использовалось на старте, отказываются в пользу более подходящего спустя пару лет эксплуатации. Частый сценарий — «переезд» с MongoDB на PostgreSQL.

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

Ещё по теме: «Как перейти с MongoDB на Postgres без простоев и сократить расходы на 30%»

Что такое MongoDB

MongoDB — документно-ориентированная база данных, которая следует парадигме NoSQL. 

В обычных реляционных базах данных информация хранится в виде взаимосвязанных таблиц. Их структура жёстко задана, и поменять её непросто. Строки каждой таблицы имеют одинаковый набор полей, данные обрабатывают с помощью запросов на языке SQL. В MongoDB всё устроено несколько иначе. Базы состоят из коллекций и документов — иерархических структур, содержащих пары «ключ-значение». 

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

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

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

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

Что такое PostgreSQL

PostgreSQL — система управления реляционными базами данных (RDBMS) с открытым исходным кодом. Совместима с языком структурированных запросов (SQL) и известна своей надёжностью, целостностью данных и активным сообществом. 

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

  • Совместимость с ACID. PostgreSQL соблюдает требования ACID благодаря технологии MVCC. Это делает систему надёжной и безопасной в использовании, а данные — защищенными от возможных сбоев, ошибок и потерь. Совместимость с ACID гарантирует, что транзакции будут обработаны полностью или не будут обработаны вообще. Это предотвращает появление ошибок при частичном выполнении операции и значительно упрощает восстановление после сбоя. 

  • Поддержка множества типов данных. PostgreSQL поддерживает большое количество типов записи информации. Это не только стандартные целочисленные значения, числа с плавающей точкой, строки и булевы значения («да/нет»), но и денежный, геометрический, перечисляемый, бинарный и другие типы. PostgreSQL «из коробки» поддерживает битовые строки и сетевые адреса, массивы данных, в том числе многомерные, композитные типы и другие сложные структуры. В ней есть поддержка XML, JSON и NoSQL-баз.

  • Работа с большими объёмами. В большинстве СУБД есть ограничения по объёму базы и количеству записей в ней. В PostgreSQL ограничений нет. Точнее есть, но они касаются конкретных записей. Скажем, одна таблица не может занимать больше 32 Тб, а одна запись — 1,6 Тб. Однако максимальных значений хватает, чтобы хранить в БД любые данные.

«PostgreSQL База»

MongoDB или PostgreSQL: что выбрать

Для начала разберёмся с ключевыми различиями между MongoDB и PostgreSQL:

  • MongoDB — это документно-ориентированная база данных, а PostgreSQL — объектно-реляционная база данных.

  • MongoDB хранит данные в коллекциях JSON-подобных документов, тогда как PostgreSQL хранит данные в таблицах.

  • Документы MongoDB в коллекции эквивалентны строкам в PostgreSQL.

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

  • MongoDB использует язык запросов MongoDB для взаимодействия с базой данных, тогда как PostgreSQL использует SQL.

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

Что насчёт недостатков PostgreSQL по сравнению с MongoDB? PostgreSQL полагается на реляционные модели данных, несовместимые со структурами данных, с которыми разработчики работают в коде, и которые должны быть определены заранее. Из-за этого может замедляться прогресс при изменении требований, что препятствует инновациям. MongoDB поддерживает быстрый итеративный цикл разработки (данные превращаются в код под контролем разработчиков). 

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

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

Однако вопрос не в том, что лучше — MongoDB или PostgreSQL, а в том, когда имеет смысл использовать документно-ориентированную, а когда — реляционную базу данных

Допустим, «отказоустойчивость» часто упоминается как сильная сторона MongoDB (СУБД легко реплицируется разбивается на сегменты в центрах обработки данных). Однако исследование надёжности PostgreSQL и MongoDB показало, что история MongoDB изобилует проблемами потери данных. Есть подробные обзоры надёжности MongoDB, проведённые Jepsen совсем недавно — в 2020 году (№1, №2, №3, №4, №5). Очевидно, что ни PostgreSQL, ни MongoDB не идеальны. Но когда речь идёт о надёжности данных, более предпочтительный выбор — Postgres. 

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

Интеграция MongoDB и PostgreSQL

Есть два способа переноса данных из нереляционной базы данных MongoDB в реляционную базу данных PostgreSQL:

  • в рамках однократной миграции базы данных;

  • в рамках текущего процесса репликации, когда MongoDB рассматривается как исходная база данных, а PostgreSQL — как целевая база данных.

Разберём каждый способ более подробно. 

Способ 1: ручной процесс ETL

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

Шаг 1. Извлечём данные из MongoDB с помощью mongoexport.

mongoexport --host localhost --db productdb --collection products --type=csv 
--out products.csv --fields name,category,color, brand,description

Здесь productdb — имя базы данных, products — имя коллекции, products.csv — выходной файл. Поля последнего атрибута будут содержать имена ключей, которые будут экспортированы в CSV. Это важно, потому что MongoDB не поддерживает жёсткую структуру ключей, и вполне возможно, что не все ключи присутствуют во всех документах. 

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

Шаг 2. Создадим в PostgreSQL таблицу, отражающую существующую структуру.

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

CREATE TABLE products (
id SERIAL PRIMARY KEY,
name VARCHAR NOT NULL,
category VARCHAR NOT NULL,
color VARCHAR  NOT NULL,
brand VARCHAR  NOT NULL,
description VARCHAR NOT NULL
)

Шаг 3. Загрузим экспортированные данные в PostgreSQL с помощью команды COPY.

COPY products(name,category,color, brand,description)
FROM 'C:tmppersons.csv' DELIMITER ',' CSV HEADER;

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

Ограничения ручного ETL, связанные с интеграцией MongoDB и PostgreSQL:

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

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

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

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

Способ 2: платформы интеграции данных без кода

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

Разберём, как выполнить интеграцию данных между MongoDB и PostgreSQL на примере Airbyte (предполагается, что у вас есть учётная запись).

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

Шаг 1. Войдём в учётную запись Airbyte.

Шаг 2. Настроим коннектор источника. На панели инструментов Airbyte нажмём на «New source», затем выберём MongoDB из списка источников. Далее нужно предоставить сведения о подключении к инстансу базы данных MongoDB, а затем нажать «Set up source».

Шаг 3. Настроим коннектор назначения. Для этого нажмём «Destinations» на панели инструментов Airbyte, затем выберите «Create destination» и выберите «PostgreSQL».

Шаг 4. Введём параметры подключения и нажмём «Set up destination», чтобы завершить процесс.

Шаг 5. Настроим соединение Airbyte между источником и получателем. Для этого нажмём «Connections» на панели инструментов Airbyte и выберем «New connection». Выберем источник и место назначения, которые создали на предыдущем шаге. Коллекции в MongoDB будут автоматически обнаружены, и мы сможем выбрать режим репликации и частоту репликации.

Вместо заключения

В статье разобрали, как переносить данные из MongoDB в PostgreSQL, а перед этим познакомились с каждой системой управления базами данных и рассмотрели основные различия между ними.

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

*** 

Ещё по теме: «Как перейти с MongoDB на Postgres без простоев и сократить расходы на 30%»

«PostgreSQL База»

Комментарии (4)