Системы управления базами данных относятся к ключевым компонентам корпоративной ИТ-инфраструктуры. От СУБД зависят хранение информации, выполнение транзакций, работа бизнес-приложений, формирование отчетности и доступ пользователей к данным. Для организаций, переходящих на российский программный стек, отдельной задачей становится выбор СУБД, которая может заменить или дополнить существующие решения и при этом сохранить привычную модель разработки и администрирования.
Одним из российских продуктов этого класса является Tantor Postgres - семейство систем управления базами данных, развиваемое компанией "Лаборатории Тантор". Технологической основой СУБД служит PostgreSQL. Это означает сохранение основных принципов его архитектуры: поддержки SQL, транзакций, многоверсионного управления параллельным доступом, журналирования, репликации, индексов, процедурных языков и расширений.
СУБД Tantor включена в Единый реестр российских программ под номером 14818 с 12 сентября 2022 года. В актуальной продуктовой линейке представлены Basic Edition, Special Edition, Special Edition 1C и Certified. Основная линейка развивается в том числе на базе PostgreSQL 18, одновременно существуют поддерживаемые редакции предыдущих основных версий.
Что представляет собой СУБД Tantor
Tantor относится к объектно-реляционным системам управления базами данных. Ее назначение - организовать долговременное хранение структурированных данных и обеспечить приложениям возможность безопасно читать, добавлять, изменять и удалять информацию.
С точки зрения разработчика значительная часть принципов работы соответствует PostgreSQL. Поддерживаются таблицы, представления, последовательности, внешние ключи, триггеры, функции, транзакции, различные типы индексов и другие привычные объекты. Система использует SQL и поддерживает механизмы обеспечения целостности данных.
Такая архитектурная преемственность имеет значение при переходе с PostgreSQL. Команде не требуется осваивать принципиально новую реляционную модель или полностью переписывать весь SQL-код только из-за смены поставщика СУБД. Однако это не означает абсолютной взаимозаменяемости: перед миграцией необходимо проверять расширения, драйверы, функции, особенности конкретных версий и другие зависимости.
Tantor может использоваться как сервер данных для корпоративных приложений, информационных систем, веб-сервисов, учетного программного обеспечения и других решений, работающих с реляционными базами. Фактическая производительность при этом зависит не только от самой СУБД, но и от структуры базы, запросов, аппаратных ресурсов и качества настройки.
Связь Tantor и PostgreSQL
PostgreSQL представляет собой открытую СУБД с длительной историей развития и большой экосистемой. Tantor использует ее кодовую и архитектурную основу, сохраняя многие стандартные возможности PostgreSQL и добавляя собственные изменения в зависимости от редакции.
В документации Tantor указана поддержка сложных SQL-запросов, внешних ключей, триггеров, транзакционной целостности и многоверсионного контроля параллелизма. Также сохраняется возможность расширять СУБД дополнительными типами данных, функциями, операторами, агрегатами и другими объектами.
Для организации это означает возможность применять значительную часть PostgreSQL-компетенций. Администратору знакомы такие понятия, как VACUUM, WAL, роли, схемы, tablespace, потоковая репликация и параметры конфигурации. Разработчики продолжают использовать SQL и распространенные PostgreSQL-драйверы там, где подтверждена их совместимость.
Одновременно Tantor является отдельным программным продуктом со своими версиями, пакетами поставки, дополнительными модулями и лицензионными условиями. Поэтому при проектировании инфраструктуры следует ориентироваться именно на документацию выбранной версии Tantor, а не предполагать, что любые возможности произвольной версии PostgreSQL будут полностью идентичны.
Основные редакции Tantor
Basic Edition, или BE, представляет базовую редакцию. Она ориентирована на сценарии, где требуется PostgreSQL-совместимая российская СУБД без полного набора возможностей и оптимизаций старших редакций.
Special Edition, или SE, предназначена прежде всего для более требовательных корпоративных систем. В нее включаются дополнительные изменения и оптимизации относительно исходной версии PostgreSQL. Конкретный перечень зависит от поколения СУБД, поэтому сравнивать редакции следует для одной и той же основной версии.
Special Edition 1C рассчитана на эксплуатацию с программными решениями семейства "1С:Предприятие". Разработчик выделяет для этой редакции дополнительные доработки и оптимизации, связанные с характерными нагрузками 1С. Само наличие специализированной редакции, однако, не гарантирует одинакового прироста производительности для любой информационной базы. Результат зависит от конфигурации 1С, объема данных, числа пользователей, запросов, блокировок и параметров оборудования.
Certified представляет сертифицированную редакцию, предназначенную для информационных систем с повышенными требованиями безопасности. В актуальной документации Tantor Certified указана сертификация ФСТЭК России. Для конкретного проекта необходимо отдельно проверять действующую версию сертификата и соответствие требованиям защищаемой системы.
Транзакционная модель и целостность данных
Одно из основных назначений корпоративной СУБД - безопасное выполнение транзакций. Например, изменение бухгалтерской операции может затрагивать несколько таблиц. Если часть изменений сохранится, а другая часть из-за ошибки не будет выполнена, база перейдет в противоречивое состояние.
Транзакционная модель позволяет объединить несколько операций в логически единое действие. Оно либо полностью фиксируется, либо откатывается. Такая схема соответствует принципам ACID и применяется в системах, для которых критична согласованность информации.
Tantor наследует соответствующие механизмы PostgreSQL. Поддерживаются различные уровни изоляции транзакций, блокировки и механизмы контроля конкурентного доступа.
Для приложений это особенно важно при одновременной работе большого количества пользователей. СУБД должна разрешать параллельное чтение и изменение информации так, чтобы отдельные транзакции не нарушали целостность данных.
MVCC и параллельная работа
Tantor использует многоверсионный механизм управления конкурентным доступом - MVCC. Вместо того чтобы при каждом изменении полностью блокировать таблицу для остальных пользователей, СУБД может поддерживать несколько версий строк.
Транзакция получает согласованное представление данных в соответствии с уровнем изоляции. Благодаря этому обычное чтение во многих ситуациях не блокирует изменение данных другой транзакцией, а запись не останавливает все операции чтения.
MVCC повышает возможности параллельной работы, но создает и эксплуатационные особенности. Старые версии строк должны постепенно очищаться. Для этого PostgreSQL-подобные СУБД используют VACUUM и автоматический механизм autovacuum.
Если обслуживание настроено неправильно или не успевает за высокой интенсивностью изменений, таблицы и индексы могут увеличиваться, а производительность - постепенно ухудшаться. Поэтому администрирование промышленной базы включает наблюдение не только за загрузкой процессора и памяти, но и за состоянием таблиц, статистикой и работой фоновых процессов.
WAL и защита от сбоев
Для сохранения надежности изменений используется журнал предзаписи WAL - Write-Ahead Log. Перед тем как измененные страницы данных окончательно окажутся в основных файлах базы, информация о выполненных операциях фиксируется в журнале.
WAL позволяет СУБД восстановить согласованное состояние после аварийного завершения. Он также используется при физической репликации: изменения основного сервера передаются на резервные узлы в виде последовательности записей журнала.
При этом WAL не следует рассматривать как замену резервному копированию. Журнал является одним из элементов стратегии восстановления, но администраторам необходимо отдельно создавать и проверять резервные копии.
Правильная схема защиты данных обычно включает базовые копии, архивирование WAL, контроль срока их хранения и периодические тестовые восстановления.
Резервное копирование и восстановление
Для критичных информационных систем недостаточно просто создавать резервную копию по расписанию. Организация должна заранее определить, какой объем изменений допустимо потерять и сколько времени может занять восстановление.
Первый показатель обычно обозначается как RPO - Recovery Point Objective. Например, если допустимая потеря данных составляет не более пяти минут, инфраструктура должна обеспечивать соответствующую частоту сохранения изменений.
Второй показатель - RTO, Recovery Time Objective. Он определяет допустимое время, в течение которого информационная система может оставаться недоступной после аварии.
На основании RPO и RTO выбирается схема резервного копирования, архивирования WAL, репликации и размещения резервных серверов. Для некоторых систем достаточно ежедневного копирования, для других требуется непрерывная передача журнала и возможность восстановления практически до момента перед сбоем.
Особенно важно регулярно проверять восстановление. Наличие файлов резервной копии еще не подтверждает, что база действительно может быть восстановлена в необходимое время.
Репликация и высокая доступность
Для повышения доступности СУБД может использоваться потоковая репликация. Один сервер выполняет роль основного узла, а изменения передаются на одну или несколько реплик.
При выходе основного сервера из строя одна из реплик может быть повышена до роли нового основного узла. Это уменьшает время восстановления по сравнению с развертыванием базы из резервной копии.
При этом репликация сама по себе не решает все задачи высокой доступности. Необходимы механизмы контроля состояния серверов, выбора лидера и переключения клиентских соединений.
В экосистеме Tantor для кластеризации применяется Patroni. В документации Платформы Tantor описывается использование Patroni поверх потоковой репликации для создания высокодоступного кластера с контролируемым и аварийным переключением.
Автоматическое переключение требует корректно настроенной инфраструктуры. Необходимо учитывать сетевые разделения, состояние кворума, маршрутизацию подключений, синхронность репликации и предотвращение ситуации, когда два узла одновременно считают себя основными.
Реплика не является резервной копией
При проектировании инфраструктуры часто смешивают две разные задачи - высокую доступность и защиту от потери данных.
Реплика помогает при отказе сервера. Если основной узел физически вышел из строя, работа может быть продолжена на другом сервере.
Однако если пользователь случайно удалил важную таблицу, ошибочная операция также может быть быстро передана на реплику. То же относится к части программных ошибок и некорректных массовых обновлений.
Поэтому надежная инфраструктура сочетает репликацию с независимым резервным копированием и архивированием WAL. Дополнительно желательно хранить хотя бы часть резервных копий отдельно от основного контура СУБД.
Производительность Tantor
Оценивать производительность СУБД только по ее названию или версии некорректно. Скорость работы базы складывается из нескольких уровней.
На уровне сервера значение имеют процессор, объем оперативной памяти, дисковая подсистема и сеть. На уровне СУБД - параметры буферного кэша, WAL, контрольных точек, фоновых процессов, планировщика запросов и параллельного выполнения. На уровне базы - таблицы, индексы, статистика, секционирование и структура данных.
Наконец, большое влияние оказывает само приложение. Один неэффективный SQL-запрос способен создавать существенно большую нагрузку, чем тысячи коротких индексных обращений.
Разработчик Tantor включает в различные редакции собственные оптимизации относительно соответствующих версий PostgreSQL. В актуальной таблице сравнения для семейства Tantor Postgres 18 перечисляются изменения ядра, оптимизации кэшей, обработки данных, архитектуры ARM64 и другие функции. Их доступность зависит от выбранной редакции.
При выборе СУБД эти улучшения целесообразно проверять нагрузочными испытаниями именно на характерном для организации профиле работы.
Особенности Tantor Postgres 18
Современная ветка Tantor развивается на базе PostgreSQL 18. Сам PostgreSQL 18 получил ряд изменений, в том числе подсистему асинхронного ввода-вывода, расширение возможностей индексного поиска и изменения в механизме обновления версий.
Документация Tantor SE 18 также отражает эти возможности. В частности, указывается поддержка асинхронного ввода-вывода для ряда операций, что потенциально может влиять на производительность последовательного сканирования, VACUUM и других процедур.
Однако переход на новую основную версию СУБД необходимо рассматривать как отдельный проект. Следует проверять расширения, драйверы, планы выполнения запросов и изменения поведения оптимизатора.
Для уже работающей информационной системы наиболее новая версия не всегда автоматически является наиболее подходящей: значение имеют поддержка прикладного ПО, требования сертификации и результаты тестирования.
Индексы и оптимизация запросов
Индекс позволяет быстрее находить строки без полного просмотра таблицы. Как PostgreSQL-совместимая СУБД, Tantor предоставляет различные механизмы индексирования.
Наиболее распространен B-tree, применяемый для сравнений, сортировки и поиска по диапазону. Для специализированных задач используются другие типы индексов.
При этом индексирование требует баланса. Каждый дополнительный индекс занимает дисковое пространство и должен обновляться при изменении данных. Поэтому большое количество ненужных индексов способно замедлить INSERT, UPDATE и DELETE.
Оптимизация начинается с анализа реальных запросов. Администратор изучает планы выполнения, фактическое количество обрабатываемых строк, использование индексов, сортировки, соединения таблиц и временные файлы.
Особенно важно поддерживать актуальную статистику. Планировщик принимает решения на основании оценки распределения данных, и устаревшая статистика способна привести к неоптимальному плану.
Партиционирование крупных таблиц
При больших объемах информации применяется секционирование, или партиционирование. Логически единая таблица разделяется на отдельные части по заданному правилу, например по месяцу, году или диапазону идентификаторов.
Это может упростить удаление устаревших данных, обслуживание таблиц и выполнение запросов, которые работают только с ограниченным диапазоном.
Партиционирование не является универсальным способом ускорения. Если запросы регулярно обращаются ко всем разделам, эффект может оказаться небольшим. Слишком большое число секций, в свою очередь, усложняет эксплуатацию.
Поэтому структура партиционирования должна соответствовать реальному жизненному циклу данных и типичным SQL-запросам.
Безопасность и разграничение доступа
Tantor использует характерную для PostgreSQL модель ролей и привилегий. Администратор может управлять правами на подключение к базе, использование схем, чтение и изменение таблиц, выполнение функций и другие действия.
Для корпоративных систем рекомендуется соблюдать принцип минимальных привилегий. Прикладное приложение не должно подключаться к базе под суперпользователем, если для его работы достаточно прав на ограниченный набор объектов.
Дополнительно необходимо контролировать сетевой доступ, использовать защищенные соединения там, где они требуются, управлять паролями и сертификатами, устанавливать обновления и анализировать журналы.
Для систем с нормативными требованиями применяется Tantor Certified. При этом сертифицированная СУБД представляет только один элемент защищенной информационной системы. Требования могут распространяться также на операционную систему, сеть, средства защиты, процессы администрирования и физическую инфраструктуру.
Tantor и российские операционные системы
Для проектов импортозамещения важна совместимость не только прикладного программного обеспечения, но и всего серверного стека.
Документация актуальных версий Tantor содержит перечни поддерживаемых операционных систем. Среди них присутствуют российские Linux-дистрибутивы, включая Astra Linux, РЕД ОС и другие системы, а также ряд распространенных Linux-платформ. Для отдельных редакций поддерживаются архитектуры x86-64 и ARM64.
Конкретную комбинацию СУБД, операционной системы и аппаратной архитектуры необходимо проверять для выбранной версии. Особенно это важно для сертифицированных информационных систем, где допустимые сочетания программных компонентов могут быть ограничены требованиями проекта.
Платформа Tantor и администрирование
СУБД Tantor и Платформа Tantor - не одно и то же. СУБД непосредственно хранит и обрабатывает информацию, а Платформа предназначена для централизованного управления и мониторинга баз данных на основе PostgreSQL и Tantor.
С ее помощью может организовываться наблюдение за состоянием экземпляров и кластеров, ключевыми показателями производительности и эксплуатационными событиями. Платформа поддерживает кластерные конфигурации на базе Patroni.
Такие средства особенно полезны при большом количестве серверов. Администратору необходимо одновременно контролировать подключения, длительные транзакции, блокировки, использование диска, отставание реплик и состояние фоновых процессов.
При этом мониторинг не заменяет анализ причины проблемы. Высокая нагрузка на CPU может быть следствием неоптимального SQL, недостатка индексов или большого числа подключений. Рост дисковой активности может быть связан с нехваткой памяти, VACUUM, контрольными точками или особенностями самого приложения.
Tantor для систем "1С"
Для приложений "1С:Предприятие" существует отдельная редакция Tantor SE 1C. Она основана на том же PostgreSQL-направлении, но содержит дополнительные изменения, рассчитанные на характерную для 1С нагрузку.
Для эксплуатации крупных баз 1С это может быть существенным фактором при выборе редакции. Однако производительность информационной системы формируется не одной СУБД.
Необходимо учитывать версию платформы "1С:Предприятие", конфигурацию, число активных пользователей, фоновые задания, структуру запросов, сервер приложений, диски и оперативную память.
Поэтому переход базы 1С на Tantor желательно предварять нагрузочным испытанием копии промышленной информационной базы. Тест должен воспроизводить не только отдельные операции, но и типичный рабочий день системы.
Миграция на Tantor
Миграция начинается с инвентаризации исходной среды. Необходимо определить размер базы, версию исходной СУБД, установленные расширения, функции, роли, драйверы, интеграции и требования к времени простоя.
При переходе с PostgreSQL или совместимой системы могут использоваться стандартные инструменты экосистемы. В документации Tantor для миграции между соответствующими версиями рассматриваются pg_dump, pg_dumpall и pg_upgrade.
При переходе с СУБД другой архитектуры процесс сложнее. Может потребоваться преобразование типов данных, SQL-конструкций, хранимых процедур и прикладной логики.
Следующий этап - тестовая миграция. После переноса необходимо проверить количество объектов и строк, права доступа, функции, отчеты, интеграционные процессы и резервное копирование.
Затем проводят нагрузочное тестирование. Только после этого можно определить параметры промышленной системы и длительность технологического окна.
Почему необходим план отката
Даже хорошо протестированная миграция может выявить проблему после запуска реальной нагрузки. Поэтому процедура перехода должна содержать условия возврата к предыдущей системе.
До переключения фиксируются момент остановки записи, способ передачи последних изменений, процедура проверки целостности и порядок изменения строк подключения приложений.
Также необходимо определить момент, после которого возврат на старую базу становится сложным из-за появления новых данных в Tantor.
Подготовленный rollback-план является обычным элементом управления рисками и необходим независимо от выбранной СУБД.
Что учитывать при выборе Tantor
Первый вопрос - совместимость. Следует проверить прикладное ПО, драйверы, расширения и инструменты интеграции.
Второй - требуемая редакция. Возможности Basic Edition, Special Edition, SE 1C и Certified отличаются. Нельзя автоматически переносить характеристики одной редакции на другую.
Третий фактор - требования к доступности. Для критичной системы необходимо заранее определить схему репликации, резервного копирования, автоматического переключения и восстановления после аварии.
Четвертый - производительность. Ее следует оценивать на реальной или максимально близкой к реальной нагрузке.
Наконец, важны эксплуатационные компетенции. PostgreSQL-совместимая архитектура упрощает использование уже накопленного опыта, однако крупная промышленная база по-прежнему требует квалифицированного администрирования.
Ограничения PostgreSQL-совместимого подхода
Совместимость с PostgreSQL является преимуществом при миграции, но имеет определенные границы. Стороннее расширение может не поддерживаться в нужной версии Tantor. Поведение оптимизатора после обновления основной версии может измениться. Возможны различия в составе пакетов и дополнительных модулей.
Отдельный вопрос - лицензирование. Tantor является коммерческим продуктом, поэтому условия его использования отличаются от свободного PostgreSQL. Перед промышленным внедрением необходимо учитывать модель лицензирования и сопровождения выбранной редакции.
Смена СУБД также не исправляет автоматически проблемы приложения. Неоптимальная схема данных, чрезмерные блокировки, неэффективные запросы или недостаточная дисковая производительность останутся факторами риска и после миграции.
Заключение
Tantor представляет собой российское субд семейство систем управления базами данных, построенное на технологической основе PostgreSQL. СУБД сохраняет реляционную модель, SQL, транзакции, MVCC, WAL, механизмы резервного копирования и репликации, а также значительную часть привычных подходов к PostgreSQL-администрированию.
В линейке существуют несколько редакций для разных задач: Basic Edition, Special Edition, специализированная версия SE 1C и сертифицированная Tantor Certified. Это позволяет выбирать вариант в зависимости от характера нагрузки, используемого прикладного ПО и требований информационной безопасности.
Для обеспечения высокой доступности Tantor может использовать потоковую репликацию и кластерные механизмы, а Платформа Tantor предназначена для централизованного управления и мониторинга инфраструктуры баз данных.
Практическая целесообразность внедрения определяется конкретным проектом. Необходимо проверить совместимость приложений и расширений, провести тестовую миграцию, измерить производительность, настроить резервное копирование и смоделировать отказ серверов.
Таким образом, Tantor следует рассматривать не просто как формальную замену зарубежной или открытой СУБД, а как отдельную PostgreSQL-совместимую платформу со своими редакциями, версиями, оптимизациями и условиями эксплуатации. Решение о переходе должно приниматься на основании технического обследования и испытаний, поскольку надежность корпоративной базы данных зависит не только от выбранного продукта, но и от архитектуры всей информационной системы.
