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

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

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

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

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

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

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

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

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

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

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

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

В материалах разработчика среди возможных сценариев применения XData называются промышленность и IoT, анализ телеметрии, логистика, кибербезопасность, розничная торговля, телекоммуникации и финансовые системы. В числе типовых задач также указаны высоконагруженные системы "1С:ERP", консолидация баз данных и построение DBaaS в частном облаке.

Связь Tantor XData и СУБД Tantor Postgres

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

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

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

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

Архитектура предыдущего поколения XData

В документации и продуктовой линейке Tantor представлены несколько аппаратных вариантов второго поколения XData. Среди них Tantor XData 2A на оборудовании Aquarius, XData 2Y на серверах YADRO и XData 2B на оборудовании "Элпитех".

Эти конфигурации отличаются вычислительной платформой и максимальными параметрами. Например, документация для XData 2Y указывает процессоры Intel Xeon Scalable третьего поколения и до 8 ТБ оперативной памяти для соответствующей конфигурации. Для XData 2B используются российские процессоры Baikal-S на архитектуре ARM Cortex-A75.

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

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

Tantor XData Gen3 и разделение вычислений и хранения

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

Упрощенная схема XData Gen3 включает два вычислительных узла, коммутаторы RDMA и три узла хранения. При этом вычислительную и дисковую части можно масштабировать отдельно.

Такой принцип называют разделением Compute и Storage. Он позволяет увеличивать именно тот ресурс, которого не хватает системе. Например, если база имеет достаточный объем хранения, но процессоры перегружены сложными запросами, можно наращивать вычислительную часть. Если узким местом становится объем или производительность хранения, расширяется соответствующая подсистема.

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

RDMA и высокоскоростная сеть

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

В XData Gen3 для связи вычислительных и дисковых узлов применяется RDMA. Разработчик указывает поддержку RoCEv2 или InfiniBand и выделенные высокоскоростные каналы.

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

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

Масштабирование базы данных

Масштабирование высоконагруженной СУБД может выполняться вертикально и горизонтально.

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

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

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

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

Отказоустойчивость как часть комплекса

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

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

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

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

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

Резервное копирование и восстановление

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

В документации XData среди функциональных возможностей комплекса отмечается быстрое резервное копирование, управление архивированием журналов и встроенные средства восстановления. В актуальной документации приводится показатель до 10 ТБ/ч для описываемой программной версии, тогда как продуктовые материалы отдельных аппаратных конфигураций указывают более высокие показатели, вплоть до 35 ТБ/ч.

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

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

Управление через Tantor Appliance Manager

Управление комплексом выполняется не только средствами самой СУБД. В XData предусмотрен отдельный уровень оркестрации Tantor Appliance Manager, сокращенно TAM.

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

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

Администратору при этом необходимо контролировать не только работу конкретной СУБД, но и распределение процессоров, памяти и хранилища между сервисами.

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

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

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

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

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

DBaaS и частное облако

Tantor XData может использоваться не только как инфраструктура для заранее определенного набора баз. Разработчик также рассматривает сценарий Database as a Service - предоставление СУБД как внутреннего сервиса.

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

Для XData заявлена API-интеграция со средствами автоматизации частного облака и возможность динамического масштабирования сервисов баз данных.

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

Tantor XData и высоконагруженные системы "1С"

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

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

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

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

Вариант на российской элементной базе

Отдельное место в линейке занимает Tantor XData 2B. В этой конфигурации используются серверы "Элпитех" на российских процессорах Baikal-S. Документация указывает 48 ядер ARM Cortex-A75 на процессор и объем памяти до 1,5 ТБ для соответствующей аппаратной конфигурации.

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

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

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

Информационная безопасность

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

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

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

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

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

Чем XData отличается от обычного мощного сервера

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

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

Основное отличие XData заключается в комплексном подходе. Вычисления, хранение, высокоскоростная сеть, отказоустойчивость, резервное копирование и управление ресурсами рассматриваются как части одной платформы. В Gen3 к этому добавляется более выраженное разделение Compute и Storage.

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

Как оценивать Tantor XData перед внедрением

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

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

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

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

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

Когда специализированная машина баз данных оправдана

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

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

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

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

Заключение

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

В линейке существуют различные аппаратные конфигурации, включая XData 2A, 2Y и вариант 2B на российских процессорах Baikal-S. В 2026 году развитие продукта продолжилось в виде XData Gen3, архитектура которой использует разделение вычислительного и дискового уровней и высокоскоростную сеть RDMA.

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

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

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