Краткий вывод: что выбрать
Для ядра коллекторской CRM в большинстве случаев лучше выбирать PostgreSQL. Долговой портфель состоит из связанных сущностей: должников, договоров, начислений, платежей, контактов, судебных дел, исполнительных производств, документов и действий сотрудников. Здесь критичны транзакции, целостность данных, отчётность и доказуемый аудит.
«В системах взыскания база данных должна быть не просто быстрым хранилищем, а юридически надёжным источником правды: кто, когда, на каком основании и с каким результатом работал с долгом.»
— Алексей Громов, технический директор КоллектСофт
MongoDB может быть полезна как дополнительное хранилище для событий, логов, гибких анкет, временных витрин или документов с нестабильной структурой. Но использовать MongoDB как единственную базу для финансового контура взыскания рискованно: сложнее контролировать связи, отчёты, ограничения ФЗ-230, историю изменений и сверку платежей.
Что хранит база данных долгового портфеля
Ошибка многих проектов — воспринимать долговой портфель как таблицу с ФИО, телефоном и суммой долга. В реальной системе взыскания данные живут дольше одного обзвона и проходят несколько стадий: soft collection, hard collection, претензия, суд, исполнительное производство, реструктуризация, закрытие.
Когда выбирать PostgreSQL
PostgreSQL подходит для долгового портфеля, когда система должна хранить финансово значимые данные, выдерживать регулярные сверки и давать управленческие отчёты без ручного восстановления логики из документов. Это классический выбор для ядра CRM взыскания, потому что реляционная модель хорошо отражает связи между договором, должником, платежом, оператором и юридическим событием.
Сильные стороны PostgreSQL для взыскания
- Транзакции ACID для платежей, перерасчётов, закрытия дел и массовых операций с портфелем.
- Внешние ключи и ограничения, которые защищают данные от разрыва связей между должником, договором и историей работы.
- JSONB для дополнительных атрибутов портфеля без потери основной реляционной структуры.
- Партиционирование больших таблиц контактов, событий, платежей и логов по дате, портфелю или заказчику.
- Материализованные представления и индексы для дашбордов по Recovery Rate, PTP, RPC, стадиям взыскания и операторам.
- Row-Level Security, роли и расширения для контроля доступа к персональным данным.
Когда уместна MongoDB
MongoDB полезна там, где структура данных часто меняется и не требуется строгая реляционная связность каждого поля. Например, в прототипах, хранилищах внешних ответов API, событиях скоринга, анкетах с нестандартными полями или в сервисах, где документ целиком читается чаще, чем участвует в сложных отчётах.
Для коллекторского агентства MongoDB можно рассматривать как дополнительный слой, но не как универсальную замену PostgreSQL. Если хранить в документах платежи, контакты, лимиты взаимодействий и юридические статусы, со временем усложняются сверки, миграции, отчёты и доказательная база.
PostgreSQL vs MongoDB: сравнение для долговых портфелей
Сравнивать базы данных нужно не по популярности, а по нагрузкам конкретного агентства: объём портфеля, частота импорта, количество операторов, число коммуникаций, глубина судебного контура и требования заказчиков к отчётности.
| Критерий | PostgreSQL | MongoDB |
|---|---|---|
| Финансовые операции | Сильная сторона: транзакции, ограничения, сверки. | Возможны, но требуют более строгой дисциплины проектирования. |
| Связи между сущностями | Естественная модель для должников, договоров, платежей и дел. | Лучше для автономных документов с небольшим числом связей. |
| Гибкие поля портфеля | JSONB закрывает большинство задач без отказа от SQL. | Сильная сторона, если структура часто меняется. |
| Отчёты и аналитика | SQL, представления, индексы и BI-интеграции работают прозрачно. | Агрегации возможны, но сложные отчёты часто дороже поддерживать. |
| Аудит и compliance | Проще построить неизменяемый журнал и контроль доступа. | Нужна отдельная архитектура аудита и контроля схемы. |
| Масштабирование | Партиционирование, реплики, read/write-разделение, архивы. | Хорошо масштабируется горизонтально для документных нагрузок. |
Рекомендуемая архитектура базы данных
Надёжная архитектура не обязана сводиться к одной технологии. В проектах взыскания мы обычно проектируем ядро вокруг PostgreSQL, а отдельные компоненты выносим в специализированные сервисы, если нагрузка этого требует.
| Компонент | Технология | Зачем нужен |
|---|---|---|
| Основное хранилище | PostgreSQL 16 | Договоры, долги, платежи, контакты, суды, аудит. |
| Гибкие атрибуты | JSONB | Поля заказчика, скоринговые признаки, импорт нестандартных реестров. |
| Поиск | OpenSearch / Elasticsearch | Быстрый поиск по ФИО, телефонам, адресам, документам и комментариям. |
| Кэш и лимиты | Redis | Оперативные счётчики контактов, очереди интерфейса, быстрые блокировки. |
| Асинхронные задачи | RabbitMQ / Kafka | Импорт реестров, генерация документов, рассылки, обновление индексов. |
| Аналитика | DWH / BI | Отчёты заказчикам, воронка взыскания, Recovery Rate, прогнозы. |
ФЗ-230, 152-ФЗ и аудит: что должна обеспечивать база
Для коллекторской CRM compliance нельзя прикрутить после релиза. Ограничения взаимодействий, согласия, отказы, часовые пояса, роли пользователей и история изменений должны быть заложены в модель данных с первого дня.
- Хранить источник, дату и основание обработки персональных данных.
- Фиксировать согласия, запреты, представителей и особые ограничения взаимодействия.
- Считать лимиты звонков, сообщений и встреч до отправки задачи оператору или автодозвону.
- Вести неизменяемый audit trail для действий пользователей, массовых выгрузок, изменений карточек и ручных корректировок.
- Разделять доступ по ролям, заказчикам, портфелям и стадиям взыскания.
- Поддерживать резервное копирование, восстановление и регламент архивного хранения.
Интеграции и аналитика
База данных для взыскания редко живёт изолированно. Она должна принимать реестры, отдавать задачи в телефонию, получать платежи, сверяться с внешними источниками и формировать отчёты для заказчиков. Поэтому важно заранее проектировать не только таблицы, но и контракты интеграций.
- ФССП: исполнительные производства и статусы взыскания.
- БКИ: обогащение и скоринговые признаки.
- Телефония и автодозвон: задачи, результаты звонков, записи.
- SMS, email и мессенджеры: события доставки и ответы.
- Платёжные шлюзы и 1С: фактические оплаты и сверки.
- BI-системы: отчёты по портфелям, заказчикам и операторам.
Типичные ошибки при выборе базы данных
Технический долг в базе данных взыскания быстро становится операционным долгом: отчёты расходятся, операторы видят разные статусы, заказчики спорят с выгрузками, а compliance проверяется вручную.
- Выбирать NoSQL только потому, что реестры приходят в JSON.
- Хранить платежи и изменения долга без строгих транзакций.
- Не проектировать аудит действий до запуска операторов.
- Держать все атрибуты должника в одном большом JSON-документе.
- Не разделять данные по заказчикам, портфелям и ролям.
- Строить отчёты напрямую по боевым таблицам без витрин.
- Не учитывать архивирование старых контактов и событий.
- Откладывать индексы, партиционирование и мониторинг до роста нагрузки.
- Не фиксировать источник данных и основание обработки ПДн.
- Не тестировать восстановление из резервной копии.
FAQ: частые вопросы о базах данных для взыскания
Можно ли хранить долговой портфель только в MongoDB?
Технически можно, но для финансового и юридического ядра это обычно повышает стоимость поддержки. Придётся отдельно контролировать связи, транзакционность, схемы, аудит и сложные отчёты.
Хватит ли PostgreSQL для крупного портфеля?
Да, если правильно спроектировать индексы, партиции, архивы, реплики и фоновые задачи. Для миллионов должников PostgreSQL обычно остаётся ядром, а поиск и аналитику выносят в отдельные слои.
Зачем нужен JSONB, если есть реляционная схема?
JSONB удобен для дополнительных полей заказчика, скоринговых признаков и нестандартных импортов. Важно не превращать JSONB в основную модель финансовых операций.
Где хранить документы и записи разговоров?
Обычно сами файлы хранят в объектном хранилище или файловом контуре, а в PostgreSQL фиксируют метаданные, ссылки, права доступа, контрольные суммы и связь с делом.
Когда нужна отдельная аналитическая база?
Когда отчёты заказчикам, BI-дашборды и прогнозы начинают нагружать боевую CRM. Тогда данные выгружают в DWH или витрины, не мешая операторам работать с карточками.
Нормативная база и источники
При проектировании базы данных для взыскания технические решения нужно сверять не только с нагрузкой, но и с нормативными требованиями к взаимодействию с должниками и обработке персональных данных.
- Федеральный закон № 230-ФЗ — правила взаимодействия с должниками.
- Федеральный закон № 152-ФЗ — требования к обработке персональных данных.
- Документация PostgreSQL — транзакции, индексы, JSONB, партиционирование и права.
- Документация MongoDB — документная модель, индексы и репликация.
Вывод: оптимальный выбор для коллекторской CRM
Если вы проектируете CRM для агентства взыскания, начинайте с PostgreSQL как с системного ядра. Он лучше подходит для долгов, платежей, контактов, ограничений, аудита и отчётности. MongoDB стоит использовать точечно, когда есть документная нагрузка, нестабильная структура данных или отдельный сервис, который не является финансовым источником правды.
КоллектСофт проектирует базы данных и CRM для агентств взыскания с учётом портфеля, интеграций, требований ФЗ-230, 152-ФЗ и будущей аналитики. На консультации мы можем разобрать вашу текущую схему, оценить риски и предложить архитектуру под реальные объёмы.