XML, JSON, базы данных и Lakehouse: как выбрать хранение данных

Обновлено 3 сентября 2026 года.

Формат файла, СУБД и архитектура аналитического хранилища решают разные задачи. XML и JSON описывают представление данных; PostgreSQL и MySQL управляют их хранением и запросами; Data Warehouse, Data Lake и Lakehouse определяют, как организовать данные для анализа. Эти технологии можно использовать вместе.

Поэтому цепочка «XML → JSON → JSONL → PostgreSQL → Lakehouse» вводит в заблуждение. Новые инструменты расширяют выбор, но не отменяют предыдущие. Ниже — различия, которые влияют на интеграцию, качество отчётов и стоимость эксплуатации.

Четыре уровня, которые стоит разделять

Например, приложение может получать XML от учётной системы, сохранять заказы в PostgreSQL, писать события в JSONL, а для аналитики формировать Parquet-файлы и SQL-витрины. Противоречия в таком сочетании нет.

XML и JSON: выбирать по контракту обмена

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

JSON описывает объекты, массивы, строки, числа, логические значения и null. Он удобен для обмена структурами данных через API. Несмотря на происхождение названия от JavaScript, формат независим от языка и требует разбора парсером. Даты и денежные единицы не являются отдельными встроенными типами JSON: их представление согласуют стороны интеграции. Синтаксис описан в RFC 8259.

Для JSON тоже можно проверять структуру по схеме — например, задавать обязательность полей, типы и допустимые значения через JSON Schema. Отсутствие XML-тегов не означает отсутствие правил. Для обоих форматов отдельно проверяют, существует ли указанный клиент, допустима ли валюта и не пришёл ли заказ повторно.

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

JSON Lines: запись на строку, но не транзакционная система

JSON Lines, или JSONL, задаёт три основных правила: UTF-8, одно допустимое JSON-значение на каждой строке и разделитель строк. BOM не допускается; пустая строка не является JSON-значением. Значением может быть объект, массив, число или null. Завершающий перевод строки рекомендуется, но не обязателен.

Например, файл событий может содержать две независимые записи:

{"event_id":"e-101","order_id":42,"amount_minor":125000,"currency":"RUB"}
{"event_id":"e-102","order_id":43,"amount_minor":89000,"currency":"RUB"}

В этом учебном примере amount_minor — сумма в копейках, а event_id — ключ события. Эти значения полей являются нашим контрактом, а не требованиями JSONL. Если программа получила e-101 второй раз, она должна распознать повтор по ключу, иначе сумма в отчёте удвоится.

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

Разделитель строк не защищает от одновременной записи несколькими процессами. Нужны согласованный механизм записи, очередь или гарантии конкретной файловой системы и операций ввода-вывода. JSONL также не даёт подтверждения доставки, порядка событий между источниками, уникальности и отката. Эти свойства обеспечивает система вокруг файла.

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

MySQL и PostgreSQL: две СУБД, а не старое и новое поколение

Обе системы развиваются и применяются для транзакционных приложений. Нельзя выбирать СУБД по тезису «MySQL умеет только простые таблицы». Например, в документации MySQL 8.4 описаны оконные функции, CTE и операции с JSON. Для транзакционных гарантий MySQL существенен используемый движок таблиц, обычно InnoDB.

PostgreSQL поддерживает JSON через типы json и jsonb. Первый сохраняет исходное текстовое представление; второй хранит разобранное представление и поддерживает индексацию. При этом jsonb не сохраняет пробелы, порядок ключей и повторяющиеся ключи объекта: остаётся последнее значение. Поэтому jsonb нельзя считать побайтовым архивом входящего документа. Различия объяснены в документации PostgreSQL.

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

Где здесь Supabase

Supabase — платформа вокруг PostgreSQL, включающая сервисы для разработки приложения. Она не заменяет PostgreSQL другим движком. Состав и взаимодействие компонентов показаны в описании архитектуры Supabase.

Готовый API не отменяет модель доступа. Для таблиц в схемах, доступных через API, необходимо согласовать SQL-привилегии и политики Row Level Security. Привилегии определяют допустимые операции, RLS — доступные строки. Служебный ключ с обходом RLS нельзя передавать в клиентское приложение. Подробности — в руководстве Supabase по RLS.

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

NoSQL не означает отказ от схемы и транзакций

NoSQL объединяет разные модели: документы, пары ключ–значение, графы и другие способы организации данных. Свойства одной системы нельзя переносить на всю категорию. Например, MongoDB поддерживает атомарность записи одного документа и распределённые транзакции для нескольких документов на replica set и sharded cluster. При этом транзакции имеют ограничения и дополнительные издержки — см. описание атомарности MongoDB.

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

DWH, Data Lake и Lakehouse: различия в организации аналитики

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

Data Lake не обязан содержать только необработанные файлы. В нём могут быть исходные, очищенные и подготовленные наборы. Schema-on-read означает применение структуры при чтении, но не разрешение забыть о происхождении данных, контроле доступа и проверках. Чтобы BI-система построила отчёт, нужны поддерживаемый источник запросов и понятная модель; отдельный перенос в DWH требуется не во всех архитектурах.

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

Parquet и формат таблиц — разные вещи

Apache Parquet — колоночный формат файлов. Он подходит для аналитического чтения выбранных колонок и поддерживает эффективное кодирование и сжатие. Сам по себе каталог Parquet-файлов не задаёт согласованную транзакцию обновления всей таблицы.

Apache Iceberg управляет снимками таблицы и метаданными: читатель работает с согласованным состоянием, а запись публикует новое состояние атомарно через поддерживаемый механизм каталога. Конкурирующие изменения проверяются, при допустимых условиях операция повторяется. Это описано в документации по надёжности Iceberg.

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

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

Пример: аналитика заказов без лишней миграции

Рассмотрим учебную ситуацию: CRM хранит сделки, учётная система отдаёт XML с оплатами, сайт отправляет JSON-события. Руководителю нужен ежедневный отчёт по заказам, оплатам и каналам привлечения.

1. Зафиксировать значения. Заказ, сделка и платёж — разные сущности. Указать ключи связи, валюту, часовой пояс и дату, по которой попадает в отчёт каждая операция.
2. Сохранить исходные ответы. В объёме и на срок, необходимые для повторной обработки и разбора расхождений. Формат источника можно оставить прежним.
3. Загрузить нормализованные записи. Проверить типы, ссылки и повторную доставку. Обновление статуса старого заказа должно корректировать его состояние, а не создавать вторую продажу.
4. Построить витрину нужной детализации. Перед соединением заказов с оплатами агрегировать платежи до уровня заказа, если отчёт требует одну строку на заказ.
5. Сверить результат. Проверить несколько заказов вручную, суммы по закрытому периоду, отмены, возвраты, поздние оплаты и повторный запуск загрузки.

Для такой задачи может хватить PostgreSQL или MySQL и управляемого процесса загрузки. Lakehouse имеет смысл оценивать, если появляются большие объёмы файловой истории, несколько движков обработки, необходимость совместного доступа к таблицам и команда, способная обслуживать эту архитектуру. Размер компании сам по себе не определяет выбор.

Что проверить перед изменением архитектуры

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

Хороший результат перехода — подтверждённое улучшение по этим критериям. Замена формата или платформы без исправления ключей, истории и правил расчёта перенесёт прежние ошибки в новую систему.