Архитектура хранилища данных для небольшой компании

Когда продажи, бухгалтерия и поддержка ведут данные в разных сервисах, проблема не в отсутствии ещё одной базы. Проблема в том, что непонятно, где лежит актуальная запись, как её восстановить и можно ли безопасно строить по ней отчёты. Разберём архитектуру небольшой компании на примере PostgreSQL 16: от источников данных до резервной копии — без предположения, что вам уже нужен большой корпоративный склад.

Сначала разделите данные по назначению

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

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

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

Как проходит запись и чтение

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

Например, заказ создаётся в приложении и сохраняется в рабочей базе. Если заказу прикрепили акт, в файловом хранилище лежит сам файл, а в базе — ссылка на него и сведения о заказе. Отчёту по выручке нужны поля заказа и платежа, но не содержимое акта. Это снижает объём лишних копий и упрощает доступ.

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

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

Один сервер, реплика или отдельный аналитический слой

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

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

Резервная копия — не то же самое, что реплика

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

WAL — журнал предварительной записи PostgreSQL: система сначала фиксирует изменения в журнале, а затем применяет их к файлам базы. При правильно настроенном архивировании WAL можно использовать вместе с базовой копией для восстановления на момент времени. Наличие файлов журнала само по себе не доказывает, что восстановление получится: важны целая цепочка архивов, подходящая базовая копия и проверенная процедура.

Для каждой системы зафиксируйте два ожидания:

• RPO — сколько последних изменений компания готова потерять при сбое.
• RTO — сколько времени допустимо потратить на возвращение сервиса к работе.

Чем меньше допустимые RPO и RTO, тем сложнее и обычно дороже схема резервирования. Не назначайте значения «на глаз»: обсудите с владельцами процессов, что будет стоить потеря часа данных или простой на полдня.

Что измерять и где архитектура ломается

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

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

Чаще всего проблемы обнаруживаются на границах компонентов:

• Отчёт нагружает рабочую базу. Ограничьте тяжёлые запросы, проверьте план выполнения и повторите замер. Если проблема сохраняется, переносите отчётную нагрузку отдельно.
• Повторная загрузка создаёт дубли. Определите устойчивый идентификатор записи и правила обработки повторов. Повторный запуск выгрузки должен быть безопасным.
• Файлы есть, а связи с ними нет. Храните метаданные и идентификатор файла в базе, а удаление и изменение проверяйте как единый бизнес-процесс.
• Копия сделана, но восстановление не проверяли. Проведите пробное восстановление в отдельной среде и засеките время. Иначе срок возврата сервиса остаётся предположением.
• Реплика отстаёт. Для операций, которым нужна немедленно актуальная запись после изменения, читайте с основного узла либо учитывайте задержку репликации.

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

Что делать дальше

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

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