Машина баз данных Tantor XData: архитектура, назначение и особенности применения

В крупных информационных системах производительность базы данных зависит не только от самой СУБД. На скорость обработки запросов одновременно влияют процессоры, оперативная память, система хранения, сетевые интерфейсы, резервное копирование, программные настройки и организация отказоустойчивости. Если эти компоненты проектируются независимо друг от друга, даже мощное оборудование не всегда обеспечивает предсказуемый результат под высокой нагрузкой.

Один из подходов к решению этой задачи - машина баз данных, то есть заранее спроектированный программно-аппаратный комплекс, в котором серверы, хранилище, сеть и программное обеспечение оптимизируются как единая система. К этому классу относится российская линейка Tantor XData. В документации разработчика Tantor XData определяется как программно-аппаратный комплекс для обработки и хранения данных и работы СУБД Tantor в высоконагруженных системах.

В 2026 году линейка включает как решения второго поколения, так и Tantor XData Gen3. Новое поколение развивает архитектуру в сторону независимого масштабирования вычислений и хранения, горизонтального масштабирования и одновременной обработки транзакционных и аналитических нагрузок.

Что такое машина баз данных

Обычную серверную инфраструктуру базы данных организация часто собирает из отдельных компонентов. Сначала выбирается сервер, затем система хранения, сетевое оборудование, операционная система, СУБД и программные средства резервирования. После этого специалисты проводят настройку и пытаются добиться требуемой производительности.

Машина баз данных tantor xdata использует другой принцип. Аппаратные и программные компоненты рассматриваются как части единого комплекса. Производитель заранее определяет архитектуру, варианты конфигурации, сетевое взаимодействие, механизмы управления и способы масштабирования.

Такой подход не означает появления принципиально нового вида базы данных. С прикладной точки зрения приложения продолжают обращаться к СУБД и выполнять SQL-запросы. Различие заключается прежде всего в инфраструктуре, на которой эта СУБД работает.

Tantor XData предназначена именно для такого сценария. В её составе объединяются вычислительные мощности, подсистема хранения, сеть и программные средства управления. В качестве СУБД используются решения семейства Tantor Postgres.

Для каких задач предназначена Tantor XData

Основная область применения машины баз данных - системы, где нагрузка или требования к доступности становятся слишком значительными для простого одиночного сервера.

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

Разработчик в числе сценариев применения XData указывает промышленность и IoT, обработку информации от датчиков, предиктивную аналитику, логистику, анализ событий информационной безопасности, рекомендательные системы, управление запасами и анализ поведения клиентов.

При этом наличие специализированного программно-аппаратного комплекса само по себе не гарантирует, что любое приложение станет работать быстрее. Реальный результат зависит от структуры базы, SQL-запросов, количества соединений, характера чтения и записи и особенностей прикладной системы.

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

СУБД и аппаратная платформа

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

Tantor XData строится как комплекс из нескольких взаимосвязанных подсистем. Вычислительные узлы выполняют процессы СУБД, система хранения отвечает за размещение информации, высокоскоростная сеть связывает элементы комплекса, а управляющее программное обеспечение координирует их работу.

Во втором поколении представлены разные аппаратные варианты. В документации, например, для XData 2A указываются серверы с двумя Intel Xeon Scalable второго поколения и объёмом оперативной памяти до 4 ТБ, а для XData 2Y - процессоры Intel Xeon Scalable третьего поколения и до 8 ТБ памяти на соответствующую конфигурацию.

Отдельный вариант XData 2B построен на российской аппаратной платформе с процессорами Baikal-S и архитектурой ARM64. Программный комплекс XData Software при этом унифицирован для поддерживаемых аппаратных архитектур.

Конкретные характеристики следует проверять для выбранной модели и поколения, поскольку линейка развивается.

Производительность OLTP

Одно из основных применений корпоративных СУБД - OLTP, или обработка большого количества сравнительно небольших транзакций.

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

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

Для XData Gen2 производитель приводит показатели до 120 тысяч транзакций в секунду для определённых конфигураций. Для XData 2A в документации указан показатель до 85 тысяч TPS, а для XData 2Y - до 120 тысяч TPS.

Эти значения нельзя напрямую переносить на любую прикладную систему. TPS зависит от сложности самой транзакции, размера данных, индексов, числа таблиц и других факторов. Поэтому они характеризуют возможности тестируемой конфигурации, а не гарантированную скорость произвольного бизнес-приложения.

Аналитические нагрузки

Транзакционные и аналитические запросы имеют разные свойства.

OLTP обычно работает с небольшими наборами строк и требует быстрых операций записи и чтения. Аналитический запрос, наоборот, способен просматривать миллионы записей, выполнять агрегации и объединять большие таблицы.

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

Для XData Gen2 разработчик заявляет оптимизации аналитических операций, включая колоночное хранение для соответствующих сценариев. На продуктовой странице также указывается ускорение аналитических операций в определённых тестах.

В XData Gen3 архитектура развивается в направлении HTAP - Hybrid Transactional/Analytical Processing. Производитель описывает Gen3 как систему, способную выполнять транзакционные и аналитические запросы одновременно на одном наборе данных.

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

Архитектура Tantor XData Gen3

Третье поколение заметно отличается от классического подхода, где вычислительные и дисковые ресурсы масштабируются преимущественно вместе.

В упрощённой конфигурации XData Gen3 разработчик описывает два вычислительных узла, высокоскоростные RDMA-коммутаторы и три узла хранения. Дополнительно могут использоваться узлы управления и прокси в отказоустойчивом режиме.

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

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

В Gen3 также заявлена совместимость с PostgreSQL и развитие распределённой архитектуры на основе технологий Tantor, включая СУБД Tantor Polar.

Высокоскоростная сеть

В распределённой машине баз данных сеть становится одним из критичных компонентов.

Если вычислительный узел постоянно обращается к удалённой системе хранения, даже небольшая задержка может существенно повлиять на SQL-запросы. Обычная корпоративная Ethernet-сеть не всегда проектируется для такой интенсивности взаимодействия.

В XData Gen3 между вычислительными узлами и хранилищем применяется высокоскоростная RDMA-инфраструктура.

RDMA позволяет организовывать высокопроизводительный обмен данными с меньшими накладными расходами на обработку сетевых операций по сравнению с традиционными схемами передачи.

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

Система хранения данных

Для базы данных дисковая подсистема часто не менее важна, чем процессор.

Даже если SQL-запрос эффективно распараллеливается, сервер может ожидать чтения блоков с накопителей. При большом числе параллельных операций это ожидание превращается в ограничение производительности.

В XData подсистема хранения является отдельным элементом общей архитектуры, рассчитанным на взаимодействие с СУБД. Разработчик также заявляет оптимизацию хранения для vector index и сценариев AI Vector Search в актуальной линейке XData Gen2.

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

При этом применение XData не делает векторный поиск обязательным: это один из поддерживаемых сценариев наряду с обычными реляционными нагрузками.

Резервное копирование

Чем больше объём базы, тем сложнее выполнить резервное копирование в допустимое время.

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

Для определённых конфигураций Tantor XData Gen2 производитель указывает скорость резервного копирования до 35 ТБ в час.

Это характеристика конкретной архитектуры и условий работы, а не универсальная скорость для любой базы.

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

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

Масштабирование без остановки сервисов

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

В материалах XData Gen2 разработчик указывает возможность увеличения вычислительных ресурсов, памяти и хранения без остановки рабочих процессов в предусмотренных архитектурой сценариях.

XData 2Y, например, допускает масштабирование до 18 вычислительных серверов, что в опубликованной конфигурации соответствует суммарно до 1152 ядер и 144 ТБ оперативной памяти.

Gen3 меняет сам принцип масштабирования, позволяя отдельно развивать вычислительные узлы и узлы хранения.

Однако возможность технически добавить ресурсы ещё не означает, что приложение автоматически начнёт эффективно их использовать. SQL-запросы, соединения и модель данных тоже должны позволять масштабироваться.

Высокая доступность

Для критичной корпоративной базы простой даже на несколько минут может влиять на множество связанных приложений.

Поэтому машина баз данных должна учитывать отказ отдельных компонентов.

Tantor XData проектируется как отказоустойчивый программно-аппаратный комплекс. В официальных материалах высокая доступность указывается в числе базовых характеристик линейки.

При этом отказоустойчивость необходимо рассматривать на нескольких уровнях. Возможна проблема вычислительного узла, диска, сетевого интерфейса, коммутатора или программного процесса.

Архитектура должна обеспечивать либо резервирование соответствующего элемента, либо понятную процедуру восстановления.

Отдельно необходимо продумывать защиту от аварии целой площадки. Наличие отказоустойчивого комплекса внутри одного ЦОД не заменяет географическое резервирование, если бизнес требует продолжить работу после недоступности всего дата-центра.

Консолидация баз данных

В крупной организации нередко существует множество отдельных СУБД. Исторически для каждого приложения мог выделяться собственный сервер.

В результате часть серверов работает почти без нагрузки, а другая часть испытывает дефицит ресурсов.

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

Для XData разработчик прямо описывает сценарий консолидации БД разных размеров с заданными параметрами доступности и производительности.

Преимущество консолидации заключается в более гибком распределении ресурсов, но появляется и риск взаимного влияния нагрузок.

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

В документации XData вычислительная подсистема предусматривает механизмы размещения сервисов БД и их изоляции по ресурсам.

Управление и оркестрация

При большом количестве узлов ручное администрирование каждой части комплекса становится сложным.

Поэтому XData включает собственные механизмы управления.

В документации описан Tantor Appliance Manager - подсистема оркестрации, которая используется для управления ресурсами и экземплярами в инфраструктуре XData.

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

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

Мониторинг базы и оборудования

Для промышленной СУБД недостаточно знать только факт её доступности.

Администратору необходимо видеть нагрузку, соединения, состояние дисков, использование памяти, производительность SQL-запросов и состояние аппаратных компонентов.

В XData применяется интеграция с инструментами экосистемы Tantor для администрирования и мониторинга. В материалах по XData 2Y разработчик указывает встроенную платформу администрирования и мониторинга вместе с СУБД Tantor Postgres.

В Gen3 инструменты управления и мониторинга также выделяются как часть общей архитектуры.

Централизованный мониторинг особенно важен при консолидации нескольких баз, потому что проблема одного узла может одновременно отражаться на нескольких сервисах.

Использование с системами "1С"

Отдельный сценарий XData связан с корпоративными системами на платформе "1С".

В материалах разработчика машины баз данных рассматриваются в том числе как инфраструктура для 1С и других критичных бизнес-приложений.

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

Поэтому тестировать машину баз данных желательно совместно со всем прикладным контуром.

Если SQL-сервер ускорился в два раза, это ещё не означает двукратное ускорение пользовательского интерфейса, поскольку часть времени может уходить на другие компоненты.

Vector Search и современные задачи обработки данных

Развитие корпоративных AI-систем привело к появлению нового типа нагрузки - поиску по многомерным векторам.

Текст, изображение или другой объект преобразуется ML-моделью в числовой вектор. После этого система ищет наиболее близкие по значению векторы.

Так работает значительная часть современных систем семантического поиска и RAG-архитектур.

В актуальном описании XData Gen2 разработчик отдельно указывает оптимизацию Storage для vector index и сценария AI Vector Search.

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

При этом сложные AI-системы обычно включают дополнительные компоненты: модели эмбеддингов, сервисы инференса и прикладную логику. Машина баз данных отвечает только за соответствующий уровень хранения и поиска.

Совместимость с PostgreSQL

Одним из важных свойств семейства Tantor является связь с экосистемой PostgreSQL.

Для XData Gen3 разработчик заявляет сохранение совместимости с PostgreSQL, включая бизнес-приложения и расширения, рассчитанные на эту экосистему.

Это имеет значение при миграции существующих систем: организация может использовать знакомый SQL, драйверы и инструменты PostgreSQL вместо полной переработки прикладного слоя под проприетарный интерфейс другой СУБД.

Однако совместимость всё равно необходимо проверять в конкретном проекте.

Приложение может использовать редкое расширение PostgreSQL, нестандартные процедуры, специфические параметры оптимизатора или особенности определённой версии. Поэтому перед миграцией требуется функциональный аудит.

Миграция на машину баз данных

Перенос базы на XData логично разделять на несколько этапов.

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

Затем необходимо определить, какая конфигурация XData соответствует предполагаемой нагрузке.

После этого создаётся тестовая среда и переносится копия базы.

На следующем этапе выполняются функциональные проверки и нагрузочные испытания.

Особое внимание стоит уделить SQL-запросам, которые формируют значительную часть нагрузки. Иногда переход на новую инфраструктуру выявляет запросы, которые раньше были скрыты общей медленной производительностью.

Только после завершения тестирования следует планировать промышленный перенос и сценарий возврата на прежнюю инфраструктуру на случай непредвиденной проблемы.

Что учитывать при выборе конфигурации

Выбирать машину баз данных только по максимальному количеству TPS нецелесообразно.

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

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

Аналитическая система предъявляет другие требования, чем транзакционная.

Для XData Gen2 разработчик предлагает несколько аппаратных конфигураций для различных сценариев нагрузки, а Gen3 дополнительно позволяет отдельно масштабировать вычислительную и дисковую подсистемы.

Поэтому подбор оборудования следует проводить на основании профиля существующей нагрузки, а не только числа пользователей.

Ограничения подхода

Машина баз данных упрощает проектирование части инфраструктуры, но не устраняет необходимость профессионального администрирования.

SQL-запросы всё равно требуется оптимизировать. Неудачно созданный индекс или тяжёлое соединение таблиц может потреблять значительные ресурсы даже на производительной системе.

Необходимо выполнять резервное копирование и регулярно проверять возможность восстановления.

Следует устанавливать обновления, контролировать безопасность и наблюдать за ростом объёма данных.

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

Наконец, производительность в тестах производителя не заменяет испытания на конкретной корпоративной нагрузке. Два приложения с одинаковым количеством пользователей способны создавать совершенно разный профиль SQL-операций.

Заключение

Tantor XData - это семейство российских программно-аппаратных комплексов для работы баз данных под высокой нагрузкой. Его архитектура объединяет вычислительные узлы, систему хранения, сетевую инфраструктуру, СУБД Tantor Postgres и средства управления в единую платформу.

Второе поколение XData ориентировано на консолидацию баз, высокую транзакционную производительность, резервное копирование и масштабирование ресурсов. В линейке существуют разные аппаратные варианты, в том числе конфигурации на x86 и российская XData 2B на ARM64 с процессорами Baikal-S.

Tantor XData Gen3 развивает концепцию в направлении распределённой PostgreSQL-совместимой архитектуры. Вычислительные ресурсы и хранилище могут масштабироваться независимо, применяется высокоскоростная RDMA-сеть, а одной из ключевых задач становится одновременная обработка транзакционной и аналитической нагрузки в модели HTAP.

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

При этом XData не следует рассматривать как универсальное средство ускорения любой информационной системы. Итоговая производительность определяется архитектурой приложения, запросами, схемой данных и профилем нагрузки. Поэтому выбор поколения и конфигурации машины баз данных должен сопровождаться аудитом существующей СУБД, пилотным переносом и нагрузочным тестированием.

Такой подход позволяет оценить Tantor XData не по заявленным характеристикам отдельно взятого оборудования, а как целостную платформу хранения и обработки данных и определить, насколько её архитектура соответствует требованиям конкретной корпоративной информационной системы.