`1.1. Бюджетирование проектов, аналитика и прогнозирование рисков: реляционная СУБД (например, PostgreSQL, MS SQL Server, Oracle). Обоснование: для финансовых данных критически важна целостность, строгая структура, поддержка транзакций и сложных аналитических запросов. Реляционные СУБД обеспечивают ACID-гарантии, сложные связи между сущностями и мощные инструменты для аналитики.
1.2. Лендинги и CRM для лидов: для лендингов — NoSQL-СУБД (например, MongoDB) или лёгкая реляционная (например, SQLite) для хранения контента; для CRM — реляционная СУБД (PostgreSQL, MS SQL Server) для хранения структурированных данных о клиентах и сделках.
1.2.*- можно использовать одну реляционную СУБД (например, PostgreSQL) с гибкой структурой таблиц и поддержкой JSONB для хранения динамических данных лендингов. Это позволит объединить данные CRM и лендингов в одной базе, обеспечивая гибкость и скорость.
1.3. База корпоративных норм и обучающих материалов: реляционная СУБД с простой структурой (например, PostgreSQL). Обоснование: структура компании обычно хорошо ложится на реляционную модель, простота и понятность обеспечиваются грамотным проектированием схемы.
1.3. Использование существующей СУБД* - можно использовать ту же реляционную СУБД, что и для бюджетирования или CRM. Для этого создаётся отдельная схема или набор таблиц, связанных с корпоративными нормами и обучением.
1.4. Логистика: маршруты, курьеры, доставка: графовая СУБД или реляционная с поддержкой гео-функций (PostgreSQL + PostGIS). Обоснование: для задач маршрутизации и анализа связей графовые СУБД наиболее эффективны. `
`Стандартное пополнение счёта
-
Инициация транзакции. Пользователь вводит номер телефона и сумму пополнения, подтверждает операцию в интерфейсе платёжного сервиса.
-
Проверка платежных данных: Далее платежная система выполняет следующие шаги (на стороне БД банка): 2.1. Проверка данных: Система проверяет корректность введённого номера, доступность суммы на счёте пользователя, а также отсутствие блокировок или ограничений. 2.2 .Резервирование средств. Происходит блокировка (холд) необходимой суммы на счёте пользователя, чтобы исключить двойное списание или использование этих средств в других операциях. 2.3. Система отправляет запрос оператору связи для зачисления средств на указанный номер телефона.
-
Аутентификация пользователя: Оператор связи на своей стороне : 3.1. По номеру телефона проверяет есть ли такой абонент в его базе, проверяется остатки баланса абонента ( суммы и блокировки, задолженности). 3.2. Подтверждает готовность принять платёж и отправляет ответ в платежную систему.
-
Проведение платежа: 4.1. Банк отправляет платеж. 4.2. Оператор связи сообщает о успешном зачислении средств. 4.3. После чего система банка снимает резерв с баланса пользователя и окончательно списывает сумму.
-
Завершение транзакции и уведомление.
Пользователь получает уведомление о пополнении, а в истории операций появляется запись о выполненной транзакции.
`Преимущества SQL-систем по сравнению с NoSQL
- Строгая структура и целостность данных. SQL-системы используют заранее определённую схему (schema), что гарантирует однородность данных и исключает появление некорректных или неожидаемых значений. Это особенно важно для финансовых, кадровых и других критически значимых данных.
- Гарантии ACID.
- Мощные инструменты для аналитики и сложных запросов. SQL поддерживает сложные объединения (JOIN), агрегации, вложенные запросы и оконные функции. Это позволяет строить сложные отчёты и проводить глубокий анализ данных без необходимости дополнительной обработки на стороне приложения.
- Стандартизация и зрелость экосистемы. Язык SQL стандартизирован, а реляционные СУБД существуют десятилетиями. Это обеспечивает широкий выбор инструментов, библиотек, интеграций и квалифицированных специалистов.
- Развитые механизмы безопасности и разграничения прав. В SQL-системах реализованы гибкие системы ролей, прав доступа, аудита и шифрования, что позволяет строить защищённые корпоративные решения с многоуровневым контролем.
NewSQL — это современное поколение СУБД, сочетающее преимущества реляционных и NoSQL-решений.
- Масштабируемость без потери транзакционной надёжности. В отличие от классических SQL-систем, NewSQL легко масштабируется горизонтально (добавление новых узлов), при этом сохраняя ACID-гарантии. NoSQL часто жертвует согласованностью ради скорости и масштабируемости.
- Высокая производительность при сложных запросах. NewSQL оптимизированы для современных аппаратных платформ и распределённых вычислений, что позволяет выполнять сложные аналитические запросы быстрее, чем в традиционных SQL-СУБД, и с большей гибкостью, чем в большинстве NoSQL.
- Гибкость и поддержка различных моделей данных. Многие NewSQL-решения поддерживают не только реляционную модель, но и работу с JSON, графами или ключ-значение, что позволяет использовать одну систему для разных задач.
- Автоматическое управление распределением данных .В отличие от классических SQL, где шардинг часто требует ручной настройки, NewSQL автоматизирует распределение данных по кластеру, упрощая администрирование.
- Совместимость с SQL и современными инструментами. NewSQL обычно поддерживает стандартный SQL и интегрируется с популярными BI- инструментами, что облегчает миграцию и развитие существующих систем. `
`ключевым критерием выбора СУБД становится масштабируемость и способность эффективно распределять нагрузку между узлами. Важно, чтобы система поддерживала горизонтальное масштабирование, автоматическое разбиение данных и была устойчива к отказам отдельных узлов.
Критерии выбора СУБД:
- Горизонтальная масштабируемость: возможность добавлять новые узлы без существенного снижения производительности.
- Поддержка распределённых вычислений: СУБД должна уметь выполнять сложные аналитические запросы параллельно на множестве машин.
- Отказоустойчивость: система должна автоматически восстанавливаться после сбоев и обеспечивать сохранность данных.
- Совместимость с инструментами аналитики: поддержка интеграции с BI-системами, ETL-инструментами и языками анализа данных.
- Гибкость модели данных: для аналитических задач часто предпочтительны колоночные СУБД, а для транзакционных — реляционные или гибридные решения.
В данном случае наиболее эффективной будет модель MapReduce или её современные реализации (например, Apache Spark). Почему именно эта модель?
- Параллелизм: MapReduce позволяет разбивать большие задачи на множество мелких, которые выполняются одновременно на разных узлах кластера. Это идеально подходит для обработки петабайтов данных.
- Отказоустойчивость: если один из 1000 узлов выходит из строя, задача автоматически перераспределяется между оставшимися машинами.
- Эффективное использование ресурсов: модель позволяет минимизировать передачу данных между узлами, что критично при работе с огромными массивами информации.
- Гибкость: современные реализации (например, Spark) поддерживают не только пакетную обработку, но и потоковую аналитику, машинное обучение и сложные SQL-запросы.
Для аналитики: колоночные СУБД (например, ClickHouse, Apache HBase, Google BigQuery), которые оптимизированы для быстрого выполнения агрегирующих запросов на больших объёмах данных. Для гибридных задач: NewSQL-системы (например, CockroachDB, TiDB), сочетающие масштабируемость NoSQL с транзакционной надёжностью SQL.`