В информационной системе предприятия база данных редко существует изолированно. Вокруг неё формируется целая инфраструктура: прикладные серверы, средства резервного копирования, системы мониторинга, механизмы высокой доступности, инструменты администрирования и программные интерфейсы. По мере увеличения количества информационных систем организациям становится важно управлять не отдельными базами данных, а единой средой работы с данными.
Такой подход можно обозначить как платформенный. Его смысл заключается в том, что система управления базами данных рассматривается не только как механизм хранения таблиц и выполнения SQL-запросов, но и как часть комплекса инструментов для администрирования, наблюдения, обеспечения доступности, миграции и сопровождения данных. Семейство Tantor Postgres и Платформа Tantor развиваются именно в этой области. Tantor Postgres представляет собой линейку СУБД на основе PostgreSQL, а Платформа Tantor предназначена для централизованного управления и мониторинга экземпляров СУБД.
Что такое платформенная СУБД
СУБД, или система управления базами данных, отвечает за хранение структурированной информации и предоставляет приложениям средства для её создания, изменения, поиска и удаления. В реляционной модели данные организуются преимущественно в таблицах, а взаимодействие с ними выполняется при помощи SQL.
PostgreSQL, на котором основано семейство Tantor Postgres, является объектно-реляционной СУБД с открытым исходным кодом. Проект развивается более трёх десятилетий и поддерживает транзакции, индексы, ограничения целостности, расширения и другие механизмы, используемые в корпоративных информационных системах.
Понятие платформенной СУБД шире базового ядра хранения. В корпоративной эксплуатации необходимо решать дополнительные задачи: следить за производительностью, искать медленные запросы, управлять множеством экземпляров, анализировать журналы, контролировать резервное копирование и организовывать отказоустойчивость.
Поэтому платформенный подход подразумевает объединение самой СУБД и средств, обеспечивающих её жизненный цикл. В случае Tantor эти функции распределяются между семейством Tantor Postgres, Платформой Tantor и другими продуктами экосистемы управления данными. Производитель характеризует Tantor Postgres как семейство российских СУБД на базе PostgreSQL с дополнительными возможностями и вендорской поддержкой.
Архитектурная основа Tantor Postgres
Tantor Postgres создан на основе PostgreSQL. Это означает сохранение привычной для PostgreSQL архитектуры и значительной части его экосистемы: SQL, типов данных, клиентских библиотек, инструментов разработки и расширений. Такой подход важен при переносе существующих приложений, поскольку разработчикам не обязательно полностью менять модель работы с базой данных.
При этом Tantor Postgres является отдельным коммерческим продуктом. В линейке существуют разные редакции, предназначенные для различных сценариев. На официальном сайте представлены Basic Edition, Special Edition, Special Edition 1C и Certified, а также специализированные решения семейства. Набор функций, ограничения и назначение конкретных редакций различаются, поэтому при проектировании системы необходимо ориентироваться на документацию именно выбранной версии.
Важный практический момент заключается в том, что совместимость с PostgreSQL не отменяет тестирование приложений. Даже при сохранении SQL и основных интерфейсов конкретная корпоративная система может использовать сторонние расширения, специфические настройки или особенности определённой версии PostgreSQL. Поэтому миграцию обычно проверяют на тестовом стенде до переноса промышленной нагрузки.
Роль Платформы Tantor
Платформа Tantor - отдельный компонент экосистемы, предназначенный для централизованной работы с базами данных. Она предоставляет графический интерфейс для управления, мониторинга и анализа экземпляров СУБД. Производитель описывает её как набор профессиональных инструментов для работы с СУБД, объединённых в одном интерфейсе.
Если организация управляет одним небольшим сервером PostgreSQL, многие операции можно выполнять средствами командной строки. При десятках или сотнях экземпляров ситуация меняется. Администратору необходимо видеть состояние множества систем, сравнивать показатели и быстро переходить от общего обзора к проблемному объекту.
Платформа позволяет формировать единый административный уровень над несколькими базами данных. В числе её функций указаны мониторинг, работа с логами, анализ производительности и управление рабочими пространствами. Поддерживается мультитенантность - логическое разделение групп рабочих пространств при работе с большим количеством экземпляров СУБД.
Таким образом, Tantor Postgres и Платформа Tantor не являются одним и тем же продуктом. Первая выполняет функции непосредственно СУБД, а вторая предоставляет централизованный слой управления и наблюдения.
Как организовано хранение данных
В реляционной СУБД основными объектами остаются базы, схемы и таблицы. Таблица содержит строки и столбцы, а схема помогает логически объединять объекты. Для обеспечения целостности используются первичные и внешние ключи, ограничения, уникальные индексы и правила типов данных.
Приложение обращается к серверу СУБД и выполняет транзакции. Транзакция позволяет объединить несколько операций в логическую единицу: либо изменения фиксируются успешно, либо при ошибке отменяются. Подобный механизм особенно важен для банковских, учётных, торговых и других систем, где частичное выполнение операции может привести к противоречивому состоянию данных.
Поскольку Tantor Postgres базируется на PostgreSQL, при проектировании приложений используются знакомые реляционные принципы и SQL-инструменты PostgreSQL.
Физическая организация хранения при этом остаётся задачей администратора. Необходимо учитывать объём базы, характер операций чтения и записи, число одновременных подключений, скорость накопителей и объём оперативной памяти. Сама принадлежность СУБД к корпоративному классу не устраняет необходимость расчёта серверных ресурсов.
Индексы и производительность запросов
Когда объём таблицы небольшой, поиск записи может выполняться достаточно быстро даже при последовательном просмотре данных. На миллионах строк такой подход становится дорогим. Для ускорения используются индексы.
Индекс создаёт дополнительную структуру, по которой СУБД может находить нужные записи без полного просмотра таблицы. Но индекс не является бесплатным ускорителем: он занимает дисковое пространство и требует обновления при изменении данных.
Поэтому задача администратора и разработчика состоит не в создании максимального количества индексов, а в поиске подходящего набора для реальной нагрузки.
Другой фактор - структура самого SQL-запроса. Два запроса, возвращающих одинаковый результат, могут требовать совершенно разного объёма вычислений. PostgreSQL использует планировщик запросов, который оценивает возможные способы выполнения и выбирает один из них. Поскольку Tantor основан на PostgreSQL, анализ планов выполнения остаётся важной частью настройки производительности.
В платформенной модели администрирования такие задачи дополняются централизованными средствами наблюдения, что позволяет анализировать состояние базы не только в момент поступления жалобы от пользователя.
Мониторинг как часть платформы данных
Производительность базы данных нельзя оценить одним показателем загрузки процессора. Необходимо учитывать число подключений, продолжительность запросов, блокировки, операции чтения и записи, использование памяти и другие показатели.
В Платформе Tantor предусмотрены средства централизованного мониторинга экземпляров СУБД и визуального анализа их состояния. Платформа также предназначена для сбора, хранения и анализа логов баз данных и предоставления рекомендаций по оптимизации.
С архитектурной точки зрения сама Платформа Tantor также использует СУБД в качестве ядра хранения своих технических данных. В документации версии 6.0 указано, что эта база основана на PostgreSQL и включает ряд расширений, используемых в том числе для обработки большого количества метрик. Среди перечисленных компонентов присутствуют pg_stat_statements, pg_store_plans, pg_cron и другие расширения.
Для администратора централизованный мониторинг полезен тем, что позволяет сравнивать несколько экземпляров и искать изменения во времени. Например, рост нагрузки можно сопоставить с появлением нового приложения, увеличением числа подключений или изменением определённого запроса.
Журналы и диагностика проблем
СУБД записывает значимую часть информации о своей работе в журналы. В них могут находиться сведения об ошибках подключения, сбоях, проблемах выполнения запросов и системных событиях.
При большом количестве серверов ручной просмотр журналов становится неудобным. Администратор сначала должен определить, где произошла проблема, затем подключиться к нужному серверу, найти соответствующий файл и отфильтровать записи.
Платформа Tantor предусматривает централизованный сбор и хранение логов баз данных, а также их визуальный анализ.
Но автоматизация не отменяет правильной настройки журналирования. Слишком низкая детализация может не дать информации для расследования, тогда как чрезмерно подробное журналирование способно создать большой объём данных и дополнительную нагрузку.
Поэтому политика логирования должна соответствовать критичности системы и практическим требованиям эксплуатации.
Высокая доступность СУБД
Для корпоративной базы данных отказ сервера может означать остановку связанного приложения. Поэтому критичные системы часто строятся не на одном экземпляре СУБД, а на нескольких узлах.
Один из распространённых подходов - репликация. Основной сервер обрабатывает изменения, а дополнительные экземпляры получают их копии. При аварии архитектура высокой доступности должна обеспечить переход приложения на работоспособный узел.
Однако наличие второй копии базы само по себе ещё не означает высокой доступности. Требуются корректное управление переключением, контроль состояния узлов, сетевой доступ и процедуры возврата системы в нормальный режим.
В экосистеме Tantor существуют средства для построения кластерных решений PostgreSQL, а сама продуктовая линейка ориентирована в том числе на корпоративные высоконагруженные системы.
Перед промышленным внедрением отказоустойчивость необходимо проверять практическими тестами: искусственно отключать компоненты и оценивать, сохраняется ли доступность приложения и корректно ли работает восстановление.
Резервное копирование не заменяет репликацию
Высокая доступность и резервное копирование решают разные задачи. Реплика позволяет продолжать работу при отказе определённого узла, но ошибка пользователя может быстро распространиться и на реплики. Например, случайное удаление данных способно стать частью нормального потока изменений.
Резервная копия предназначена для восстановления состояния базы на определённый момент. Поэтому критичные информационные системы обычно используют оба подхода.
При проектировании необходимо определить допустимую потерю данных и максимальное время восстановления. От этих требований зависит частота резервного копирования, хранение журналов транзакций и расположение копий.
Дополнительно следует регулярно проверять восстановление. Файл резервной копии имеет ценность только в том случае, если из него действительно можно получить работоспособную базу.
Платформенность СУБД удобна именно тем, что эксплуатационные процессы рассматриваются как часть общего жизненного цикла данных, а не как отдельная процедура, вспоминаемая только после аварии.
Tantor для высоконагруженных систем
Нагрузка на СУБД зависит от типа приложения. В одной системе преобладают короткие транзакции, в другой выполняются продолжительные аналитические запросы, а в третьей одновременно присутствуют оба сценария.
Tantor Postgres Special Edition позиционируется как редакция для высоконагруженных корпоративных систем. В линейке также выделена Special Edition 1C, оптимизированная для приложений на платформе "1С:Предприятие 8".
Однако слово "высоконагруженная" не задаёт конкретной конфигурации. Для одной организации это несколько сотен одновременных пользователей, для другой - тысячи транзакций в секунду или десятки терабайт данных.
Поэтому производительность необходимо оценивать на профильной нагрузке. Полезен тестовый стенд с объёмом данных и структурой запросов, похожими на будущую промышленную систему. Измерять следует не только число транзакций, но и задержки, нагрузку на CPU, память и накопители, а также поведение при увеличении числа соединений.
Работа с системами "1С"
Отдельная редакция Tantor Postgres предназначена для использования с продуктами "1С". Производитель указывает, что Tantor Special Edition 1C оптимизирована и одобрена для работы с бизнес-приложениями на платформе "1С:Предприятие".
Выделение отдельной редакции связано с особенностями нагрузки таких систем. Корпоративная информационная база "1С" может одновременно выполнять большое количество транзакций, отчётных запросов и фоновых операций, поэтому производительность зависит не только от процессора сервера, но и от взаимодействия приложения с СУБД.
При миграции базы "1С" требуется тестировать типовые бизнес-операции: проведение документов, формирование отчётов, закрытие периода и массовые фоновые задания. Результаты синтетического теста SQL не всегда точно отражают производительность реальной прикладной системы.
Сертифицированная редакция
Для информационных систем с дополнительными требованиями к защите данных производитель предлагает Tantor Certified. На странице продукта эта редакция описывается как сертифицированная СУБД, а в её состав входит Платформа Tantor для централизованного мониторинга и администрирования корпоративных PostgreSQL-баз.
Выбор сертифицированной версии обычно связан не только с функциями СУБД. Организация должна учитывать требования к операционной системе, аппаратной платформе, средствам защиты, процедурам обновления и всей архитектуре информационной системы.
Поэтому наличие сертификата у отдельного программного продукта не следует рассматривать как автоматическую сертификацию всей инфраструктуры.
Миграция на Tantor
Переход на новую СУБД состоит из нескольких этапов. Сначала проводится инвентаризация существующей базы: оцениваются объём данных, структура схем, используемые расширения, функции, процедуры и особенности SQL.
Затем проверяется совместимость приложения. Если исходная система уже использует PostgreSQL, переход обычно отличается от миграции с другой СУБД, однако даже в этом случае следует проверить версии расширений и настройки.
После переноса структуры выполняется миграция данных. Для больших систем она может потребовать отдельной стратегии, поскольку длительная остановка приложения не всегда допустима.
Следующий этап - функциональное и нагрузочное тестирование. Необходимо убедиться, что данные перенесены корректно, запросы возвращают ожидаемые результаты, а производительность соответствует требованиям.
Дополнительным инструментом экосистемы является Tantor Data Integration - платформа, которую производитель связывает с задачами миграции и интеграции данных и построением единой платформы данных.
Информационная безопасность базы данных
СУБД хранит данные, которые часто относятся к наиболее важным активам организации. Поэтому защита должна строиться на нескольких уровнях.
Первый уровень - идентификация и аутентификация пользователей. Для приложений и администраторов желательно использовать отдельные учётные записи и не выдавать избыточные права.
Второй уровень - разграничение доступа. Пользователь, которому требуется чтение определённых таблиц, не должен автоматически получать возможность изменять структуру всей базы.
Третий уровень - защита сетевых соединений и административных интерфейсов. Доступ к серверу СУБД не следует без необходимости открывать из внешних или пользовательских сегментов.
Наконец, важны аудит и анализ журналов. Платформенный подход полезен тем, что централизованные средства управления могут дополнять встроенные механизмы самой СУБД и давать администратору общую картину.
Конкретные параметры безопасности Tantor зависят от редакции и версии продукта, поэтому для защищённых систем необходимо сверяться с актуальными руководствами и документацией производителя.
Мультитенантность и управление множеством баз
По мере роста предприятия число экземпляров СУБД увеличивается. Отдельные базы используются разработчиками, тестовыми средами, филиалами и промышленными приложениями.
Если все они отображаются в одном общем списке, управление становится неудобным. Платформа Tantor поддерживает мультитенантность - логическое разделение рабочих пространств для групп экземпляров СУБД.
Такой механизм можно использовать для разделения окружений или зон ответственности. Например, тестовые базы могут находиться в одном рабочем пространстве, промышленные - в другом.
Это не обязательно означает физическую изоляцию данных. Мультитенантность в данном контексте является прежде всего организационным механизмом управления. Реальный уровень изоляции определяется архитектурой серверов, сети, прав доступа и развертывания конкретных экземпляров.
Интеллектуальные функции платформы
В актуальном описании Платформы Tantor присутствует встроенный интеллектуальный помощник. Производитель указывает возможности документирования баз данных, генерации SQL-запросов на естественном языке, ответов на вопросы по работе с БД, мониторинга и обнаружения аномалий.
Такие функции могут использоваться как вспомогательный инструмент администратора или разработчика. Однако автоматически сгенерированный SQL необходимо проверять перед выполнением, особенно в промышленной базе.
Причина заключается в контексте. Запрос может быть синтаксически корректным, но создавать чрезмерную нагрузку или изменять больше данных, чем предполагалось. Поэтому интеллектуальные инструменты не отменяют стандартные процессы тестирования, контроля прав и резервного копирования.
Горизонтальное развитие платформы данных
В экосистеме Tantor существует не только классическая архитектура PostgreSQL. В документации производителя представлена Tantor Polar - СУБД корпоративного класса с архитектурой разделения вычислительного слоя и хранения данных. Для неё заявлены горизонтальное масштабирование и возможность работы с транзакционными и аналитическими нагрузками в одном кластере при сохранении совместимости с экосистемой PostgreSQL.
Кроме программных решений, в линейке присутствует Tantor XData - программно-аппаратная машина баз данных, ориентированная на высоконагруженные сценарии. Производитель рассматривает её как вариант для систем, где возможностей традиционной конфигурации СУБД и серверов становится недостаточно.
Эти решения показывают, что понятие платформы данных может охватывать несколько архитектурных уровней - от отдельной PostgreSQL-совместимой СУБД до распределённых и программно-аппаратных комплексов.
Как оценивать Tantor перед внедрением
Выбор корпоративной СУБД следует начинать с требований приложения, а не с перечня функций продукта. Необходимо определить ожидаемый объём данных, количество пользователей, тип запросов, требования к времени восстановления и допустимому простою.
Затем оценивается совместимость. Важно составить список расширений PostgreSQL, клиентских драйверов, систем интеграции и инструментов резервного копирования.
Следующий этап - нагрузочное тестирование. Тест должен имитировать реальные операции приложения, а не только выполнять простые синтетические запросы.
После этого проверяется отказоустойчивость: остановка узла, потеря сетевого соединения и процедуры восстановления из резервной копии.
Наконец, оценивается эксплуатационная сторона: насколько удобно администратору наблюдать за системой, анализировать запросы и журналы и управлять несколькими экземплярами. Именно здесь становится значимой связка самой СУБД Tantor Postgres и централизованной Платформы Tantor.
Лицензирование и эксплуатационные расходы
Tantor Postgres является коммерческим продуктом, поэтому при планировании инфраструктуры необходимо учитывать правила лицензирования наряду с серверными ресурсами и сопровождением.
В опубликованной политике Tantor указано лицензирование ряда редакций по физическим или виртуальным ядрам сервера. Для конкретных редакций предусмотрены собственные условия и минимальное количество лицензий. Условия способны изменяться, поэтому расчёт проекта следует выполнять по актуальной политике производителя, а не по ранее подготовленным спецификациям.
Стоимость владения СУБД при этом состоит не только из лицензии. В неё входят оборудование, системы хранения, резервное копирование, мониторинг, работа администраторов, обучение специалистов и время на миграцию.
Платформенные инструменты могут уменьшать часть операционных затрат за счёт централизации, но этот эффект необходимо оценивать на конкретной инфраструктуре.
Заключение
Платформенная СУБД - это подход, при котором работа с корпоративными данными не ограничивается хранением таблиц и выполнением SQL-запросов. В единую архитектуру включаются мониторинг, администрирование, анализ производительности, высокая доступность, резервное копирование и инструменты управления большим количеством экземпляров.
В экосистеме Tantor ядром такого подхода является семейство Tantor Postgres, созданное на базе PostgreSQL. Разные редакции предназначены для базовых, высоконагруженных, ориентированных на "1С" и защищённых сценариев. Дополнительный административный слой предоставляет Платформа Tantor, объединяющая мониторинг, управление экземплярами, анализ логов и другие эксплуатационные инструменты.
Использование PostgreSQL в качестве технологической основы позволяет сохранить знакомую реляционную модель, SQL и значительную часть существующей экосистемы. При этом переход на Tantor всё равно требует проверки совместимости приложений, расширений и конкретных версий программного обеспечения.
Практический результат внедрения определяется не названием СУБД, а качеством архитектуры. Производительность зависит от запросов, индексов, серверных ресурсов и характера нагрузки. Отказоустойчивость требует корректной репликации и проверки переключений. Защита данных зависит от разграничения прав и сетевой архитектуры, а возможность восстановления - от исправных и регулярно проверяемых резервных копий.
Поэтому Tantor целесообразно рассматривать не как изолированный сервер баз данных, а как набор компонентов для формирования корпоративной платформы управления данными. При таком подходе сама СУБД отвечает за надёжное хранение и обработку информации, а платформенные инструменты помогают администраторам наблюдать за состоянием систем, анализировать проблемы и централизованно сопровождать растущий парк баз данных.
