Текстовая версия беседы генерального директора «Тантор Лабс» Вадима Яценко с популяризатором российской электроники Максимом Горшениным о третьем поколении машин баз данных Tantor XData, об используемой в них архитектуре СУБД, о том, как удалось сделать настоящий HTAP без потери обратной совместимости с Postgres и о том, как подступиться к импортозамещению информационных систем, в которых позиции Oracle и других зарубежных вендоров наиболее сильны.
Максим Горшенин — Сегодня поговорим о базах данных, и я не просто так к этому вопросу подхожу. Есть хорошо мне знакомая машина баз данных (МБД) Tantor XData, которую разработала компания «Тантор Лабс». Второе поколение вышло на аппаратных платформах от Аквариуса, от YADRO, а еще на российском процессоре Baikal-S и серверах Элпитех. Сегодняшний повод встретиться — это новое, третье поколение, и насколько я уловил, в ней реализованы некие фундаментальные изменения. Поэтому я попросил Вадима Яценко, генерального директора компании «Тантор Лабс», подробнее обо всем рассказать. Вадим, правильно я понимаю, что имеет место сильный отход от второй генерации?
Вадим Яценко — Я бы сказал, это своего рода революция. Новая машина отличается от второго поколения значительно, она в принципе создана на другой аппаратной платформе. Другое решение с точки зрения сети, у нас используется RDMA, мы разделили подсиситемы вычислений (Compute) и хранения (Storage), и мы используем процессоры AMD. Все это очень в тренде машин баз данных. Одна широко всем известная компания, только не российская, также делает на похожих решениях свою МБД.
М.Г. — Как вы пришли к третьему поколению? Был какой-то запрос от тех, кто уже использует вашу Tantor XData?
В.Я. — Российские решения всегда с кем-то сравнивают. Есть западные решения, которые завоевали российский рынок в прошлом. Нас всегда сравнивали с Oracle Exadata, которая, безусловно, является эталоном среди МБД. Мы хотели приблизиться к этому решению и построить что-то близкое, но на нашей СУБД на основе PostgreSQL.
М.Г. — Что же требовало изменений?
В.Я. — В первую очередь — производительность. От нас требовали серьезный рост производительности по сравнению со вторым поколением. Также мы должны были решить вопрос горизонтального масштабирования, и в т.ч. вопрос независимого масштабирования подсистем вычислений и хранения. Это позволило бы устранять перекосы, когда, допустим, вычислительный ресурс уже исчерпан, но при этом блока хранения по объему и по пропускной способности еще достаточно, т.е. заказчику нужно было бы добавить только процессор, память. Так что новое поколение создавалось из наиболее чаемых ожиданий наших заказчиков и опыта внедрения МБД предыдущего поколения.
М.Г. — А будет ли вообще совместимость с предыдущим поколением? Что делать тем, кто уже его использует?
В.Я. — Само собой, с коммерческой точки зрения нам бы хотелось, чтобы у нас покупали только новые решения. Но мы сохраняем обратную совместимость, у нас есть возможность миграции, и в целом не будет нужно каждый раз покупать весь ПАК. Поэтому взаимозаменяемость есть, и есть обратная совместимость.
М.Г. — Про аппаратную часть поговорим чуть позже, нужно сперва разобраться в основе. А основа вся та же, от «Тантор Лабс», или что-то иное?
В.Я. — Да, от «Тантор Лабс», но по-хитрому. Это другая редакция СУБД, а точнее, совершенно другая СУБД, но 100% совместимая с PostgreSQL. Текущие наши редакции СУБД базируются на открытой версии PostgreSQL, а она имеет ряд известных архитектурных ограничений, которые в принципе не позволяют создать решение, которое мы предлагаем в третьем поколении МБД.
М.Г. — То есть заказчик к чему-то привык, поэтому и выставляет такие требования, а на Postgres это означает перелопатить вообще все?
В.Я. — Именно так. Заказчики привыкли к тому, что у них есть серьезные западные решения. Эти решения надо заменять. Часть заменили, но осталось много тяжелых систем, и чаще всего это core-системы. К ним до сих пор не могли адекватно подступиться, они продолжают работать, потому что заменить их на что-то российское на текущий момент очень сложно. Начинают придумывать, что-то делать, кто-то «нарезает» на несколько информационных систем, и под каждую создает собственную базу… Все осознают, что это тоже заключает в себе риски и проблемы. Это сложные проекты, поэтому заказчик хочет, условно говоря, взять старое и заменить на нечто плюс-минус похожее новое, но чтобы это все-таки это оставалось единой системой.
М.Г. — Но основой то у вас остался open-source?
В.Я. — Конечно, основа — open-source, даже более того — в целом это тот же PostgreSQL. Как говорится, если оно крякает как утка и выглядит как утка… Вот и в нашем случае то же. Сохранить полную совместимость с PostgreSQL — это и была самая сложная задача. То есть наша Tantor XData Gen3 ведет себя со стороны бизнес-приложений как PostgreSQL, все бизнес-приложения могут работать с МБД ровно так же, как они работают с open-source версией или даже с коммерческим форком. И вот эта задача фундаментально сложна, потому что решения, которые сейчас есть для масштабирования Postgres, предполагают частичную утрату совместимости с открытой версией, и это создает проблемы для бизнес-приложений.
М.Г. — Я правильно понимаю, что вы замахнулись побороться-потягаться с Oracle Exadata на основе открытых решений, и с вашими доработками это удалось?
В.Я. — Да, удалось. Мы даже сделали такое табличное сравнение: взяли технологии, которые использует Oracle, к примеру, Oracle RAC — это известная технология Real Application Clusters, — и сопоставили, что в этой части предлагаем мы. Мы не повторяем полностью Oracle RAC, однако тем не менее, у нас появилась своя распределенная файловая система, которая как раз позволяет разделить уровень хранения и уровень вычислений. И у нас появилась полноценная кластерная система, которая позволяет без репликации синхронизировать несколько инстансов СУБД. Это сложная технология, которая потребовала RDMA, потому что нам нужны низкие задержки. Здесь нужна реальная синергия аппаратной части с софтовой частью.
М.Г. — Ну да, нужно глубоко копать, создавая ПАК, где именно аппаратная часть — это часть программных функций. Хорошо, а вот если крупными мазками посмотреть, — насколько получилось? Может быть, есть какие-то минусы, может, чего-то не хватило еще по сравнению с Oracle, или наоборот, есть что-то, что вы превзошли?
В.Я. — Конечно же, в первую очередь, это не Oracle, это Postgres. Это надо понимать и с точки зрения эксплуатации, и с точки зрения ожиданий. Мы постарались сохранить все то, чем Postgres славится, сохранить простоту с точки зрения администрирования кластерных конфигураций. Для обычного администратора, который занимается повседневной эксплуатацией, нового будет мало.
С другой стороны, мы смогли построить настоящую HTAP-систему, то, за что ценили Oracle. Это гибридная система, которая позволяет выполнять и транзакционную нагрузку, и работать с аналитикой. Мы постарались сделать ровно то же самое. У нас настоящая гибридная HTAP-система. Мы внедрили отдельный планировщик на основе GPORCA, гринпламовского планировщика. Это позволило работать с аналитикой как в настоящей MPP-системе, и все внутри одной машины, на тех же самых данных. Одновременно мы можем работать и с транзакционной системой (транзакционной нагрузкой), и с аналитикой. Но в чем отличие? Например, мы на текущий момент сделали свое пассивное хранилище, но пока не научились его делать таким умным, как в Oracle, то есть смартсканы, вот это все. Мы пока еще работаем, скажем так, как обычная блочка, но мы движемся в этом направлении, есть наработки в том плане, чтобы сделать наш Storage более умным. Если смотреть на архитектуру, то у нас три сервера – это хранение, минимальная конфигурация. И три сервера – вычисление. У всех есть процессор, память, диски. Странно не эксплуатировать ресурсы процессора, оперативки, которых вполне хватает, чтобы сделать более умное хранение.
М.Г. — Ну хорошо, было второе поколение, теперь третье, есть понимание куда двигаться, а потестироваться у вас можно?
В.Я. — Конечно можно, мы как раз выходим на то, чтобы начать отдавать по запросу на тесты. Понятно, что мы ограничены в количестве оборудования, все-таки это тяжелая машина, а не виртуализированные какие-то объекты. Выдаем в штучном экземпляре. Хорошая новость в том, что мы работаем над тем, чтобы как раз в Astra Cloud появилась так называемая XScale. Название рабочее, т.е. пока еще это не продукт. По сути, это наша Tantor XData, только в формате уже виртуализованных, контейнеризованных баз данных. Само собой, производительность будет не такой, как на bare metal, но мы получим другие плюсы. А именно — по запросу можно будет автоматически делать масштабирование вычислительной части. Eсли у вас выросла нагрузка, например, в девять утра все пришли на работу, мы соответственно добавляем дополнительные вычислительные ресурсы автоматически. Вечером все уходят домой, нагрузки нет, можно спокойно выключить ноды, которые нам не нужны, и платить меньше.
М.Г. — Я читал у вас на Хабре статью, встретил название PolarDB. Что это такое?
В.Я. — PolarDB — это форк компании Alibaba. Они выложили все исходники в open source, они на гитхабе. Мы смотрели на него достаточно долго и, честно говоря, не решались, потому что отсутствала внятная документация. А та, которая была — это не документация, а скорее набор обрывочных знаний о том, что это такое вообще. Мы столкнулись с определенной спецификой китайской разработки, не в том плане, что она какая-то плохая, речь об отношении к open source. Как будто перекинули через забор и забыли.
М.Г. — Кому надо, тот разберется, что ли?
В.Я. — Да, вам надо — разберетесь. Соответственно, мы фактически год занимались R&D с реверс-инжинирингом, разбирались, как это работает. Были там и научные статьи о PolarDB, были материалы, и в китайском, и даже в англоязычном варианте, но невозможно было понять, о какой версии PolarDB идет речь, потому что PolarDB в Alibaba — это набор продуктов. Есть PolarDB-X, есть PolarDB для PostgreSQL, PolarDB для MySQL и так далее, у них целая экосистема. Когда читаешь научную статью, ты не понимаешь, о каком именно PolarDB идет речь и вообще, есть ли эта функциональность в той open-source ветке, которая выложена… Поэтому мы делали полный реверс-инжиниринг. А потом мы осознали, что то, что было выложено, — это точно не то, что работает в Alibaba Cloud. Вот совсем не то.
М.Г. — Классический Китай произошел.
В.Я. — Многие компоненты пришлось просто переписать. Есть вот распределенная файловая система PolarFS, ее переписали, потому что то, что выложено в open source, имеет изъяны, в том числе с точки зрения перфоманса.
М.Г. — Я общался со своим другом, он про мне рассказывал про DeepSeek. У них раcписано, как все работает, но в том, что они в open source выложили, вообще этого нет, все скрыто. То есть что-то описано по-китайски или по-английски, а вот как это реализовано — они скрывают. Просто как некий манифест выложили, что это вот так у нас работает, а сами внутренности никто не выкладывает.
В.Я. — Да, так и есть. Дальше мы столкнулись с тем, что выложенная максимальная open-source версия PolarDB базируется на PostgreSQL 11. На тот момент мы уже делали R&D и планировали, что сами будем «тащить» в новой версии Postgres весь старый багаж. И тут наши китайские товарищи сделали подарок — в прошлом году, по-моему, осенью, выложили пятнадцатую версию PolarDB, но она оказалась очень куцей, в ней не было тех энтерпрайзных вещей, которые нам были нужны. Ребята, засучив рукава, начали все, что нам было необходимо, тащить в пятнадцатую версию, и тащить еще все наши патчи, которые специфичны именно для Tantor Postgres. В результате мы получили собственный форк, сильно отличающийся от того, что есть в открытой версии. Этими наработками мы планируем делиться и выкладывать их в open-source. Идея в том, чтобы не просто создать коммерческий продукт в виде Tantor XData, а еще и поделиться с сообществом наработками. Мы готовы выкладывать в open source и делиться знаниями. А делиться там есть чем, там очень интересные решения, интересные подходы.
М.Г. — А почему вообще PolarDB выбрали?
В.Я. — Мы на самом деле смотрели на многие решения, у нас был выбор. Часть команды тянула нас в шардинг. Я к этому относился скептически, да чего греха таить, я и продавил, чтобы мы не занимались шардингом и взяли другой курс. Мы занялись Compute / Storage Separation, посмотрели на опыт Amazon — они были одними из первопроходцев со своей Amazon Aurora. Потом это сделал Google с AlloyDB. Недавно Amazon анонсировала свое решение HorizonDB. Databricks купила Neon за миллиард долларов. Все эти технологии строятся на том, чтобы сделать Postgres более подходящим для облака, для современных вычислений, для современного подхода к масштабированию.
Мы выбрали это направление, потому что оно позволило с определенными ограничениями, но решить проблему масштабирования. С PolarDB мы увидели, что чем больше мы «копали» эту СУБД, чем больше мы пытались разобраться в том, как все устроено, и разбирали каждую фичу, тем больше мы понимали, что китайцы не просто так эти фичи делали. Они же реально решали проблему, с которой мы тоже столкнулись. Чем больше мы погружались, тем больше понимали, что проблемы уже решены, и все, что нам нужно сделать, – это реверс-инжиниринг и файнтюнинг.
М.Г. — Приземлить на нашу реальность?
В.Я. — Да, приземлить на нашу реальность. Из интересного — нам удалось заставить работать Тантор Polar с 1С. То есть, мы можем взять нашу машину с Tantor Polar и запустить на ней 1С, со всеми нашими патчами 1С, со всеми оптимизациями. Немного забегая вперед, эта версия работает под 1С эффективнее, чем наша СУБД Tantor Postgres под 1С. То есть в целом у нас очень высокая совместимость с обычным Postgres.
М.Г. — А у нас PolarDB вообще насколько распространен в России?
В.Я. — Вообще не распространен. Когда мы этим начали заниматься, единственное, что я нашел в русскоязычном интернете, — это упоминание о том, что Alibaba объявила, что они выложили в open source свою версию PolarDB. В телеграм-чатах, где «сидят» специалисты по Postgres, я поискал упоминания PolarDB — и нашел только обсуждение этого факта. Всё! Российский сегмент про эту СУБД не знает ничего. Удивительно! Отправились читать китайские ресурсы. Я сам за эти два года много китайского напереводил на английский. На английский переводит нормально, а на русский иногда так себе. Было интересно: оказалось, что сами китайцы удивляются, почему Alibaba с PolarDB — номер один в Китае, а GaussDB и другие китайские решения идут ниже, но при этом за пределами Китая PolarDB вообще нигде не распространена. И получается, что для инженера непонятен порог входа — что это за продукт, как он устроен, как его запускать и масштабировать. Из-за отсутствия документации, материалов и понятного маркетинга в западном мире про эту СУБД просто никто не знает.
М.Г. — У меня тут же мысль появилась: раз вы это делаете, значит вы наверняка пишете документацию на русском. Проблемы, с которыми вы столкнулись с китайским подходом, вы решили. Логично тогда переводить ваши материалы на английский и распространять?
В.Я. — У нас документация на двух языках — русском и английском. Скоро начнем публиковать часть материалов. Сейчас их готовим, в том числе решаем, что именно выкладывать в open source.
Мы думали, как поступить: попытаться пойти в Alibaba и закоммитить изменения в основную ветку? Но изменений настолько много, что это выглядело бы странно — прийти и вывалить огромный кусок кода. Не факт, что они это приняли бы. Поэтому сейчас мы идем по стратегии: выложить как форк, а дальше посмотреть. Если со стороны Alibaba будет интерес — можно будет объединиться. Важно, чтобы документация точно соответствовала тому, как работает код. И у китайцев с этим есть сложности.
Другой важный момент: в системе очень много скрытых параметров — так называемых GUC’ов и конфигурационных переменных, которые управляют поведением системы, но нигде не описаны. Иногда приходилось буквально выковыривать их из исходного кода. Администратор БД не может их увидеть, нельзя просто проверить, включены они или нет. Даже наши DBA, которые сейчас занимаются тестированием, эксплуатацией, они иногда пытаются разобраться, просто прыгая по исходным кодам, потому что другой информации нет. Это огромная проблема, и мы ее решаем.
М.Г. — Ассемблер уровня PolarDB, я понял...
В.Я. — Да, вроде того. Но нужно отдать должное, китайцы — молодцы. Некоторые вещи сделаны там спорно, но, я где-то слышал, что в Китае распространен подход «good enough», в том числе с точки зрения кода. Мы же пытаемся заниматься перфекционизмом, у нас код должен быть красивый, перфоманс должен быть, и т.д. и т.п. В Китае скорее подход приемлемости. То есть если это решает задачу, то зачем наводить лишнюю красоту.
М.Г. — А если что-то вылезет, то потом поправим.
В.Я. — Потом поправим, да, и вот мы в том числе решали и эти проблемы. Для них приемлемо, а для нас надо напильником допиливать.
М.Г. — В автопроме тоже это видно. Ну хорошо, а если вы это все в open source выкладываете, значит, люди могут пойти попробовать сами, поставить, поковырять. Но если я беру open source, сам себе ставлю, на свои сервера заряжаю, зачем мне тут вы?
В.Я. — Да, пожалуйста, можно, конечно. Мы не планируем ограничивать как-то людей использовать это для себя, в плане того, кто что скачал, поставил, установил, запустил.
М.Г. — Это очень круто.
В.Я. — Но каков порог вхождения! Кстати, самое интересное я забыл сказать. PolarDB позволяет работать в двух режимах. Она работает как СУБД в режиме Shared Storage, когда у нас Compute и Storage разделены. Но мы можем запустить PolarDB и в режиме Compute / Storage Integration, и это будет как обычный Postgres. То есть мы можем устанавливать и работать с PolarDB как с обычным Postgres. В общем, мы как раз хотим популяризировать, хотим, чтобы в нашей стране большое количество людей обладало знаниями, как с этим работать. Если будут какие-то новые коммиты — это только приветствуется.
М.Г. — Это очень круто. Я привык, что обычно все как-то ограничивается компаниями. Ты же вначале же говорил, что очень жесткая завязка идет именно на аппаратную часть?
В.Я. — Да, идет жесткая завязка на аппаратную часть, используется RDMA. Есть в этом плане определенные ограничения, «любое» железо не установишь. Думаю, в этом тоже одна из причин, почему эта СУБД была не столь популярна, люди относились к ней скептически. Но у нас есть идеи, как сделать так, чтобы работало не только с RDMA в режиме Shared Storage. В целом, если человек хочет поработать в режиме Shared Storage с PolarDB и в целом получить какой-то перфоманс или гибкость управления, то наверное, он сможет купить себе пару коммутаторов с поддержкой RDMA и собрать это где-то у себя.
М.Г. — Слушай, если вы уберете требования с RDMA, то это полноценное уже отдельное направление. Это уже не форк.
В.Я. — Да, так что если выложим, то приглашаем в коммиты, которые позволят это делать.
М.Г. — Надо всем потрогать, пощупать, посмотреть, дать ответ, накатить, благо, документация имеется. А вот когда вы изучали, создавали, вы же, наверное, параллельно запустили работу по созданию аппаратной части? Там какие-то сложности? Я услышал про процессоры AMD.
В.Я. — Запустить PolarDB можно практически на любом процессоре, здесь ограничений нет. Это тот же самый Postgres, и скомпилировать можно под что угодно. Почему AMD? У AMD много линий PCI-express, которые по умолчанию уже идут в сервере. А учитывая, что у нас все под RDMA, — нам нужны разъемы под карточки, разъемы под наш программно-аппаратный ускоритель, который используется в хранилище. В целом, чтобы чувствовать себя комфортно, мы выбрали AMD. Кроме этого, в AMD много ядер, а это хорошо для блока вычислений. Но и на Intel все спокойно будет работать. Хотите на Intel — пожалуйста, без проблем.
По поводу операционных систем – китайцы собирают это все на open source операционных системах. У нас даже была шутка: ребята, когда первый раз собрали Tantor Polar на ОС Astra Linux, первое, что написали — это: «спешите видеть — аттракцион «Китайская СУБД на российской операционной системе». Это шутка, но понятно, что мы адаптировали СУБД в том числе для того, чтобы это работало на Astra Linux, в смысле работы с библиотеками, драйверами и всем-всем-всем.
Есть много задач на уровне хранения. Вообще, если говорить о нашем интеллектуальном вкладе, то очень много лежит именно в хранении. Правильно собрать, правильно нарезать количество линий, которые подключены к каждой вычислительной ноде, соблюсти баланс с точки зрения пропускной способности, сколько такое хранилище может обработать, как оно должно быть собрано… То есть Storage — это вообще отдельная технология, которую мы собирали и отдельно делали.
М.Г. — Это тоже будет в open-source?
В.Я. — Вот этого в open source не будет. Но есть хорошая новость — вы можете использовать любую блочку и любое SDS, любое аппаратное хранилище, которое поддерживает RDMA. Для примера — наш Storage из трех серверов на текущий момент выдает примерно шесть миллионов IOPS, это в базовой комплектации из восьми дисков в каждой железке. Понятно, что не всем столько нужно, мы можем как-то урезать, но все равно вышла очень производительная штука.
М.Г. — Tantor XData ведь изначально позиционируется для высоконагруженных систем, больших, мощных, это то что я себе в ИП пойду поставлю.
В.Я. — Конечно, если вам нужна база на 10 гигабайт, то Tantor XData — не ваш выбор, проще что-то в облаке купить.
М.Г. — Круто! А требуется ли сертификация? ФСТЭК, предположим?
В.Я. — Хороший вопрос. Требуется сертификация, если мы хотим использовать машину в КИИ, ЗОКИИ. Но как подходить к сертификации? Обычно требования заказчиков, которые мы получаем, — это наличие сертификатов на каждый компонент, который используется внутри нашей машины. Учитывая, что мы сделали из PolarDB реально свою редакцию с нашими патчами, в том числе по безопасности, сейчас мы как раз занимаемся сертификацией, мы в процессе подготовки документов для того, чтобы сертифицировать Tantor Polar по четвертому уровню доверия. Проблем с КИИ, ЗОКИИ быть не должно. Другие компоненты сертифицируются либо в рамках ОС, либо уже имеют нужные сертификаты.
М.Г. — Логично. Ты сказал, что хотите поработать со Storage и развивать систему дальше. Я так понимаю, третья генерация — это не финал, а живая система, которая будет развиваться?
В.Я. — Конечно. Архитектура Compute / Storage Separation, или еще говорят Disaggregated Compute & Storage, имеет огромный потенциал. Когда у нас была классическая модель с Postgres, возможности были ограничены — оптимизация, точечные патчи и так далее. Здесь же открывается огромное поле для развития, особенно на уровне хранения. Например, распределенная файловая система — PolarFS или наш форк Tantor PFS. Там есть такая вещь как device types — возможность использовать разные типы Storage. У Alibaba есть собственный облачный Storage, сильно оптимизированный под их задачи, но этого нет в open source, там есть только базовая блочка, которая ничего не знает о БД.
Соответственно, нам нужно развивать это направление — делать storage «умным», добавлять свои device types, чтобы понималась структура данных, работа БД и так далее. Это первая задача, вторая — мы переносим функциональность из старых версий PolarDB в новые версии, и это не просто перенос, а постоянная доработка, потому что Postgres сильно меняется. Сейчас портируемся на 17 версию, потом на 18. Версии, которые будем выкладывать в open source, будут актуальными.
Еще одно важное направление — аналитика. В Alibaba Cloud есть технология IMCI, это columnar-индексы поверх обычных таблиц, они нужны для эффективной работы с аналитическими запросами. В open source этого нет, поэтому приходится просто «закидывать» ресурсы. Чтобы сделать систему эффективнее, нам нужно внедрять подобные подходы. Задача HTAP-машины не в том, чтобы победить ClickHouse или DuckDB, а в том, чтобы на одном наборе данных эффективно выполнять и транзакционные, и аналитические нагрузки без копирования данных.
М.Г. — Тогда финальный вопрос — безопасность. Как с этим?
В.Я. — Во-первых, мы должны постоянно идти в ногу с новыми версиями Postgres, потому что там регулярно закрываются уязвимости (CVE). Сейчас требования ФСТЭК — устранять такие уязвимости очень быстро, вплоть до суток. Это накладывает жесткие ограничения. С другой стороны, мы ведем определенные наборы патчей и накладываем на open-source ветки в том числе. Это ускоряет разработку, в т.ч. внедрение функций безопасности, то есть то, что есть в сертифицированной версии СУБД Tantor Postgres, будет и в Tantor Polar. Плюс мы унаследовали часть механизмов безопасности из оригинального PolarDB — политики паролей, проверка логинов, шифрование (TDE) и так далее.
Мы идем в сертификацию, и в лабораторных условиях нас будут тщательно проверять. И я не вижу рисков с редакцией Tantor Polar — это не новая СУБД «с нуля», а развитие Postgres, знакомое специалистам.
М.Г. — То есть по сути — привычная система, но с новыми возможностями?
В.Я. — Верно. DBA, DevOps и разработчики, знакомые с Postgres, смогут быстро разобраться. Многое будет знакомо тем, кто работал с Greenplum — например, планировщик GPORCA и терминология. Еще раз, мы работаем над тем, чтобы выложить все в open-source, но хотим сделать это правильно, с документацией, а не просто «перекинуть через забор».
М.Г. — Лично для меня это базовая вещь. Для чего мы сейчас и беседуем — чтобы разобраться в новых технологиях, понять где мы сегодня и где будем завтра. А вы, как представитель одной из флагманских компаний, даете квалифицированный ответ: задачи уже можно решать на отечественных решениях. Есть поддержка, все нормально с безопасностью, и это не просто софт, а глубокая интеграция с железом. Плюс вы умеете работать с российским оборудованием — значит, и в эту сторону развитие будет. Правильно?
В.Я. — Да, конечно.
М.Г. — Тогда большое спасибо! Мне было очень интересно, надеюсь, и вам тоже.
Вадим Яценко — Я бы сказал, это своего рода революция. Новая машина отличается от второго поколения значительно, она в принципе создана на другой аппаратной платформе. Другое решение с точки зрения сети, у нас используется RDMA, мы разделили подсиситемы вычислений (Compute) и хранения (Storage), и мы используем процессоры AMD. Все это очень в тренде машин баз данных. Одна широко всем известная компания, только не российская, также делает на похожих решениях свою МБД.
М.Г. — Как вы пришли к третьему поколению? Был какой-то запрос от тех, кто уже использует вашу Tantor XData?
В.Я. — Российские решения всегда с кем-то сравнивают. Есть западные решения, которые завоевали российский рынок в прошлом. Нас всегда сравнивали с Oracle Exadata, которая, безусловно, является эталоном среди МБД. Мы хотели приблизиться к этому решению и построить что-то близкое, но на нашей СУБД на основе PostgreSQL.
М.Г. — Что же требовало изменений?
В.Я. — В первую очередь — производительность. От нас требовали серьезный рост производительности по сравнению со вторым поколением. Также мы должны были решить вопрос горизонтального масштабирования, и в т.ч. вопрос независимого масштабирования подсистем вычислений и хранения. Это позволило бы устранять перекосы, когда, допустим, вычислительный ресурс уже исчерпан, но при этом блока хранения по объему и по пропускной способности еще достаточно, т.е. заказчику нужно было бы добавить только процессор, память. Так что новое поколение создавалось из наиболее чаемых ожиданий наших заказчиков и опыта внедрения МБД предыдущего поколения.
М.Г. — А будет ли вообще совместимость с предыдущим поколением? Что делать тем, кто уже его использует?
В.Я. — Само собой, с коммерческой точки зрения нам бы хотелось, чтобы у нас покупали только новые решения. Но мы сохраняем обратную совместимость, у нас есть возможность миграции, и в целом не будет нужно каждый раз покупать весь ПАК. Поэтому взаимозаменяемость есть, и есть обратная совместимость.
М.Г. — Про аппаратную часть поговорим чуть позже, нужно сперва разобраться в основе. А основа вся та же, от «Тантор Лабс», или что-то иное?
В.Я. — Да, от «Тантор Лабс», но по-хитрому. Это другая редакция СУБД, а точнее, совершенно другая СУБД, но 100% совместимая с PostgreSQL. Текущие наши редакции СУБД базируются на открытой версии PostgreSQL, а она имеет ряд известных архитектурных ограничений, которые в принципе не позволяют создать решение, которое мы предлагаем в третьем поколении МБД.
М.Г. — То есть заказчик к чему-то привык, поэтому и выставляет такие требования, а на Postgres это означает перелопатить вообще все?
В.Я. — Именно так. Заказчики привыкли к тому, что у них есть серьезные западные решения. Эти решения надо заменять. Часть заменили, но осталось много тяжелых систем, и чаще всего это core-системы. К ним до сих пор не могли адекватно подступиться, они продолжают работать, потому что заменить их на что-то российское на текущий момент очень сложно. Начинают придумывать, что-то делать, кто-то «нарезает» на несколько информационных систем, и под каждую создает собственную базу… Все осознают, что это тоже заключает в себе риски и проблемы. Это сложные проекты, поэтому заказчик хочет, условно говоря, взять старое и заменить на нечто плюс-минус похожее новое, но чтобы это все-таки это оставалось единой системой.
М.Г. — Но основой то у вас остался open-source?
В.Я. — Конечно, основа — open-source, даже более того — в целом это тот же PostgreSQL. Как говорится, если оно крякает как утка и выглядит как утка… Вот и в нашем случае то же. Сохранить полную совместимость с PostgreSQL — это и была самая сложная задача. То есть наша Tantor XData Gen3 ведет себя со стороны бизнес-приложений как PostgreSQL, все бизнес-приложения могут работать с МБД ровно так же, как они работают с open-source версией или даже с коммерческим форком. И вот эта задача фундаментально сложна, потому что решения, которые сейчас есть для масштабирования Postgres, предполагают частичную утрату совместимости с открытой версией, и это создает проблемы для бизнес-приложений.
М.Г. — Я правильно понимаю, что вы замахнулись побороться-потягаться с Oracle Exadata на основе открытых решений, и с вашими доработками это удалось?
В.Я. — Да, удалось. Мы даже сделали такое табличное сравнение: взяли технологии, которые использует Oracle, к примеру, Oracle RAC — это известная технология Real Application Clusters, — и сопоставили, что в этой части предлагаем мы. Мы не повторяем полностью Oracle RAC, однако тем не менее, у нас появилась своя распределенная файловая система, которая как раз позволяет разделить уровень хранения и уровень вычислений. И у нас появилась полноценная кластерная система, которая позволяет без репликации синхронизировать несколько инстансов СУБД. Это сложная технология, которая потребовала RDMA, потому что нам нужны низкие задержки. Здесь нужна реальная синергия аппаратной части с софтовой частью.
М.Г. — Ну да, нужно глубоко копать, создавая ПАК, где именно аппаратная часть — это часть программных функций. Хорошо, а вот если крупными мазками посмотреть, — насколько получилось? Может быть, есть какие-то минусы, может, чего-то не хватило еще по сравнению с Oracle, или наоборот, есть что-то, что вы превзошли?
В.Я. — Конечно же, в первую очередь, это не Oracle, это Postgres. Это надо понимать и с точки зрения эксплуатации, и с точки зрения ожиданий. Мы постарались сохранить все то, чем Postgres славится, сохранить простоту с точки зрения администрирования кластерных конфигураций. Для обычного администратора, который занимается повседневной эксплуатацией, нового будет мало.
С другой стороны, мы смогли построить настоящую HTAP-систему, то, за что ценили Oracle. Это гибридная система, которая позволяет выполнять и транзакционную нагрузку, и работать с аналитикой. Мы постарались сделать ровно то же самое. У нас настоящая гибридная HTAP-система. Мы внедрили отдельный планировщик на основе GPORCA, гринпламовского планировщика. Это позволило работать с аналитикой как в настоящей MPP-системе, и все внутри одной машины, на тех же самых данных. Одновременно мы можем работать и с транзакционной системой (транзакционной нагрузкой), и с аналитикой. Но в чем отличие? Например, мы на текущий момент сделали свое пассивное хранилище, но пока не научились его делать таким умным, как в Oracle, то есть смартсканы, вот это все. Мы пока еще работаем, скажем так, как обычная блочка, но мы движемся в этом направлении, есть наработки в том плане, чтобы сделать наш Storage более умным. Если смотреть на архитектуру, то у нас три сервера – это хранение, минимальная конфигурация. И три сервера – вычисление. У всех есть процессор, память, диски. Странно не эксплуатировать ресурсы процессора, оперативки, которых вполне хватает, чтобы сделать более умное хранение.
М.Г. — Ну хорошо, было второе поколение, теперь третье, есть понимание куда двигаться, а потестироваться у вас можно?
В.Я. — Конечно можно, мы как раз выходим на то, чтобы начать отдавать по запросу на тесты. Понятно, что мы ограничены в количестве оборудования, все-таки это тяжелая машина, а не виртуализированные какие-то объекты. Выдаем в штучном экземпляре. Хорошая новость в том, что мы работаем над тем, чтобы как раз в Astra Cloud появилась так называемая XScale. Название рабочее, т.е. пока еще это не продукт. По сути, это наша Tantor XData, только в формате уже виртуализованных, контейнеризованных баз данных. Само собой, производительность будет не такой, как на bare metal, но мы получим другие плюсы. А именно — по запросу можно будет автоматически делать масштабирование вычислительной части. Eсли у вас выросла нагрузка, например, в девять утра все пришли на работу, мы соответственно добавляем дополнительные вычислительные ресурсы автоматически. Вечером все уходят домой, нагрузки нет, можно спокойно выключить ноды, которые нам не нужны, и платить меньше.
М.Г. — Я читал у вас на Хабре статью, встретил название PolarDB. Что это такое?
В.Я. — PolarDB — это форк компании Alibaba. Они выложили все исходники в open source, они на гитхабе. Мы смотрели на него достаточно долго и, честно говоря, не решались, потому что отсутствала внятная документация. А та, которая была — это не документация, а скорее набор обрывочных знаний о том, что это такое вообще. Мы столкнулись с определенной спецификой китайской разработки, не в том плане, что она какая-то плохая, речь об отношении к open source. Как будто перекинули через забор и забыли.
М.Г. — Кому надо, тот разберется, что ли?
В.Я. — Да, вам надо — разберетесь. Соответственно, мы фактически год занимались R&D с реверс-инжинирингом, разбирались, как это работает. Были там и научные статьи о PolarDB, были материалы, и в китайском, и даже в англоязычном варианте, но невозможно было понять, о какой версии PolarDB идет речь, потому что PolarDB в Alibaba — это набор продуктов. Есть PolarDB-X, есть PolarDB для PostgreSQL, PolarDB для MySQL и так далее, у них целая экосистема. Когда читаешь научную статью, ты не понимаешь, о каком именно PolarDB идет речь и вообще, есть ли эта функциональность в той open-source ветке, которая выложена… Поэтому мы делали полный реверс-инжиниринг. А потом мы осознали, что то, что было выложено, — это точно не то, что работает в Alibaba Cloud. Вот совсем не то.
М.Г. — Классический Китай произошел.
В.Я. — Многие компоненты пришлось просто переписать. Есть вот распределенная файловая система PolarFS, ее переписали, потому что то, что выложено в open source, имеет изъяны, в том числе с точки зрения перфоманса.
М.Г. — Я общался со своим другом, он про мне рассказывал про DeepSeek. У них раcписано, как все работает, но в том, что они в open source выложили, вообще этого нет, все скрыто. То есть что-то описано по-китайски или по-английски, а вот как это реализовано — они скрывают. Просто как некий манифест выложили, что это вот так у нас работает, а сами внутренности никто не выкладывает.
В.Я. — Да, так и есть. Дальше мы столкнулись с тем, что выложенная максимальная open-source версия PolarDB базируется на PostgreSQL 11. На тот момент мы уже делали R&D и планировали, что сами будем «тащить» в новой версии Postgres весь старый багаж. И тут наши китайские товарищи сделали подарок — в прошлом году, по-моему, осенью, выложили пятнадцатую версию PolarDB, но она оказалась очень куцей, в ней не было тех энтерпрайзных вещей, которые нам были нужны. Ребята, засучив рукава, начали все, что нам было необходимо, тащить в пятнадцатую версию, и тащить еще все наши патчи, которые специфичны именно для Tantor Postgres. В результате мы получили собственный форк, сильно отличающийся от того, что есть в открытой версии. Этими наработками мы планируем делиться и выкладывать их в open-source. Идея в том, чтобы не просто создать коммерческий продукт в виде Tantor XData, а еще и поделиться с сообществом наработками. Мы готовы выкладывать в open source и делиться знаниями. А делиться там есть чем, там очень интересные решения, интересные подходы.
М.Г. — А почему вообще PolarDB выбрали?
В.Я. — Мы на самом деле смотрели на многие решения, у нас был выбор. Часть команды тянула нас в шардинг. Я к этому относился скептически, да чего греха таить, я и продавил, чтобы мы не занимались шардингом и взяли другой курс. Мы занялись Compute / Storage Separation, посмотрели на опыт Amazon — они были одними из первопроходцев со своей Amazon Aurora. Потом это сделал Google с AlloyDB. Недавно Amazon анонсировала свое решение HorizonDB. Databricks купила Neon за миллиард долларов. Все эти технологии строятся на том, чтобы сделать Postgres более подходящим для облака, для современных вычислений, для современного подхода к масштабированию.
Мы выбрали это направление, потому что оно позволило с определенными ограничениями, но решить проблему масштабирования. С PolarDB мы увидели, что чем больше мы «копали» эту СУБД, чем больше мы пытались разобраться в том, как все устроено, и разбирали каждую фичу, тем больше мы понимали, что китайцы не просто так эти фичи делали. Они же реально решали проблему, с которой мы тоже столкнулись. Чем больше мы погружались, тем больше понимали, что проблемы уже решены, и все, что нам нужно сделать, – это реверс-инжиниринг и файнтюнинг.
М.Г. — Приземлить на нашу реальность?
В.Я. — Да, приземлить на нашу реальность. Из интересного — нам удалось заставить работать Тантор Polar с 1С. То есть, мы можем взять нашу машину с Tantor Polar и запустить на ней 1С, со всеми нашими патчами 1С, со всеми оптимизациями. Немного забегая вперед, эта версия работает под 1С эффективнее, чем наша СУБД Tantor Postgres под 1С. То есть в целом у нас очень высокая совместимость с обычным Postgres.
М.Г. — А у нас PolarDB вообще насколько распространен в России?
В.Я. — Вообще не распространен. Когда мы этим начали заниматься, единственное, что я нашел в русскоязычном интернете, — это упоминание о том, что Alibaba объявила, что они выложили в open source свою версию PolarDB. В телеграм-чатах, где «сидят» специалисты по Postgres, я поискал упоминания PolarDB — и нашел только обсуждение этого факта. Всё! Российский сегмент про эту СУБД не знает ничего. Удивительно! Отправились читать китайские ресурсы. Я сам за эти два года много китайского напереводил на английский. На английский переводит нормально, а на русский иногда так себе. Было интересно: оказалось, что сами китайцы удивляются, почему Alibaba с PolarDB — номер один в Китае, а GaussDB и другие китайские решения идут ниже, но при этом за пределами Китая PolarDB вообще нигде не распространена. И получается, что для инженера непонятен порог входа — что это за продукт, как он устроен, как его запускать и масштабировать. Из-за отсутствия документации, материалов и понятного маркетинга в западном мире про эту СУБД просто никто не знает.
М.Г. — У меня тут же мысль появилась: раз вы это делаете, значит вы наверняка пишете документацию на русском. Проблемы, с которыми вы столкнулись с китайским подходом, вы решили. Логично тогда переводить ваши материалы на английский и распространять?
В.Я. — У нас документация на двух языках — русском и английском. Скоро начнем публиковать часть материалов. Сейчас их готовим, в том числе решаем, что именно выкладывать в open source.
Мы думали, как поступить: попытаться пойти в Alibaba и закоммитить изменения в основную ветку? Но изменений настолько много, что это выглядело бы странно — прийти и вывалить огромный кусок кода. Не факт, что они это приняли бы. Поэтому сейчас мы идем по стратегии: выложить как форк, а дальше посмотреть. Если со стороны Alibaba будет интерес — можно будет объединиться. Важно, чтобы документация точно соответствовала тому, как работает код. И у китайцев с этим есть сложности.
Другой важный момент: в системе очень много скрытых параметров — так называемых GUC’ов и конфигурационных переменных, которые управляют поведением системы, но нигде не описаны. Иногда приходилось буквально выковыривать их из исходного кода. Администратор БД не может их увидеть, нельзя просто проверить, включены они или нет. Даже наши DBA, которые сейчас занимаются тестированием, эксплуатацией, они иногда пытаются разобраться, просто прыгая по исходным кодам, потому что другой информации нет. Это огромная проблема, и мы ее решаем.
М.Г. — Ассемблер уровня PolarDB, я понял...
В.Я. — Да, вроде того. Но нужно отдать должное, китайцы — молодцы. Некоторые вещи сделаны там спорно, но, я где-то слышал, что в Китае распространен подход «good enough», в том числе с точки зрения кода. Мы же пытаемся заниматься перфекционизмом, у нас код должен быть красивый, перфоманс должен быть, и т.д. и т.п. В Китае скорее подход приемлемости. То есть если это решает задачу, то зачем наводить лишнюю красоту.
М.Г. — А если что-то вылезет, то потом поправим.
В.Я. — Потом поправим, да, и вот мы в том числе решали и эти проблемы. Для них приемлемо, а для нас надо напильником допиливать.
М.Г. — В автопроме тоже это видно. Ну хорошо, а если вы это все в open source выкладываете, значит, люди могут пойти попробовать сами, поставить, поковырять. Но если я беру open source, сам себе ставлю, на свои сервера заряжаю, зачем мне тут вы?
В.Я. — Да, пожалуйста, можно, конечно. Мы не планируем ограничивать как-то людей использовать это для себя, в плане того, кто что скачал, поставил, установил, запустил.
М.Г. — Это очень круто.
В.Я. — Но каков порог вхождения! Кстати, самое интересное я забыл сказать. PolarDB позволяет работать в двух режимах. Она работает как СУБД в режиме Shared Storage, когда у нас Compute и Storage разделены. Но мы можем запустить PolarDB и в режиме Compute / Storage Integration, и это будет как обычный Postgres. То есть мы можем устанавливать и работать с PolarDB как с обычным Postgres. В общем, мы как раз хотим популяризировать, хотим, чтобы в нашей стране большое количество людей обладало знаниями, как с этим работать. Если будут какие-то новые коммиты — это только приветствуется.
М.Г. — Это очень круто. Я привык, что обычно все как-то ограничивается компаниями. Ты же вначале же говорил, что очень жесткая завязка идет именно на аппаратную часть?
В.Я. — Да, идет жесткая завязка на аппаратную часть, используется RDMA. Есть в этом плане определенные ограничения, «любое» железо не установишь. Думаю, в этом тоже одна из причин, почему эта СУБД была не столь популярна, люди относились к ней скептически. Но у нас есть идеи, как сделать так, чтобы работало не только с RDMA в режиме Shared Storage. В целом, если человек хочет поработать в режиме Shared Storage с PolarDB и в целом получить какой-то перфоманс или гибкость управления, то наверное, он сможет купить себе пару коммутаторов с поддержкой RDMA и собрать это где-то у себя.
М.Г. — Слушай, если вы уберете требования с RDMA, то это полноценное уже отдельное направление. Это уже не форк.
В.Я. — Да, так что если выложим, то приглашаем в коммиты, которые позволят это делать.
М.Г. — Надо всем потрогать, пощупать, посмотреть, дать ответ, накатить, благо, документация имеется. А вот когда вы изучали, создавали, вы же, наверное, параллельно запустили работу по созданию аппаратной части? Там какие-то сложности? Я услышал про процессоры AMD.
В.Я. — Запустить PolarDB можно практически на любом процессоре, здесь ограничений нет. Это тот же самый Postgres, и скомпилировать можно под что угодно. Почему AMD? У AMD много линий PCI-express, которые по умолчанию уже идут в сервере. А учитывая, что у нас все под RDMA, — нам нужны разъемы под карточки, разъемы под наш программно-аппаратный ускоритель, который используется в хранилище. В целом, чтобы чувствовать себя комфортно, мы выбрали AMD. Кроме этого, в AMD много ядер, а это хорошо для блока вычислений. Но и на Intel все спокойно будет работать. Хотите на Intel — пожалуйста, без проблем.
По поводу операционных систем – китайцы собирают это все на open source операционных системах. У нас даже была шутка: ребята, когда первый раз собрали Tantor Polar на ОС Astra Linux, первое, что написали — это: «спешите видеть — аттракцион «Китайская СУБД на российской операционной системе». Это шутка, но понятно, что мы адаптировали СУБД в том числе для того, чтобы это работало на Astra Linux, в смысле работы с библиотеками, драйверами и всем-всем-всем.
Есть много задач на уровне хранения. Вообще, если говорить о нашем интеллектуальном вкладе, то очень много лежит именно в хранении. Правильно собрать, правильно нарезать количество линий, которые подключены к каждой вычислительной ноде, соблюсти баланс с точки зрения пропускной способности, сколько такое хранилище может обработать, как оно должно быть собрано… То есть Storage — это вообще отдельная технология, которую мы собирали и отдельно делали.
М.Г. — Это тоже будет в open-source?
В.Я. — Вот этого в open source не будет. Но есть хорошая новость — вы можете использовать любую блочку и любое SDS, любое аппаратное хранилище, которое поддерживает RDMA. Для примера — наш Storage из трех серверов на текущий момент выдает примерно шесть миллионов IOPS, это в базовой комплектации из восьми дисков в каждой железке. Понятно, что не всем столько нужно, мы можем как-то урезать, но все равно вышла очень производительная штука.
М.Г. — Tantor XData ведь изначально позиционируется для высоконагруженных систем, больших, мощных, это то что я себе в ИП пойду поставлю.
В.Я. — Конечно, если вам нужна база на 10 гигабайт, то Tantor XData — не ваш выбор, проще что-то в облаке купить.
М.Г. — Круто! А требуется ли сертификация? ФСТЭК, предположим?
В.Я. — Хороший вопрос. Требуется сертификация, если мы хотим использовать машину в КИИ, ЗОКИИ. Но как подходить к сертификации? Обычно требования заказчиков, которые мы получаем, — это наличие сертификатов на каждый компонент, который используется внутри нашей машины. Учитывая, что мы сделали из PolarDB реально свою редакцию с нашими патчами, в том числе по безопасности, сейчас мы как раз занимаемся сертификацией, мы в процессе подготовки документов для того, чтобы сертифицировать Tantor Polar по четвертому уровню доверия. Проблем с КИИ, ЗОКИИ быть не должно. Другие компоненты сертифицируются либо в рамках ОС, либо уже имеют нужные сертификаты.
М.Г. — Логично. Ты сказал, что хотите поработать со Storage и развивать систему дальше. Я так понимаю, третья генерация — это не финал, а живая система, которая будет развиваться?
В.Я. — Конечно. Архитектура Compute / Storage Separation, или еще говорят Disaggregated Compute & Storage, имеет огромный потенциал. Когда у нас была классическая модель с Postgres, возможности были ограничены — оптимизация, точечные патчи и так далее. Здесь же открывается огромное поле для развития, особенно на уровне хранения. Например, распределенная файловая система — PolarFS или наш форк Tantor PFS. Там есть такая вещь как device types — возможность использовать разные типы Storage. У Alibaba есть собственный облачный Storage, сильно оптимизированный под их задачи, но этого нет в open source, там есть только базовая блочка, которая ничего не знает о БД.
Соответственно, нам нужно развивать это направление — делать storage «умным», добавлять свои device types, чтобы понималась структура данных, работа БД и так далее. Это первая задача, вторая — мы переносим функциональность из старых версий PolarDB в новые версии, и это не просто перенос, а постоянная доработка, потому что Postgres сильно меняется. Сейчас портируемся на 17 версию, потом на 18. Версии, которые будем выкладывать в open source, будут актуальными.
Еще одно важное направление — аналитика. В Alibaba Cloud есть технология IMCI, это columnar-индексы поверх обычных таблиц, они нужны для эффективной работы с аналитическими запросами. В open source этого нет, поэтому приходится просто «закидывать» ресурсы. Чтобы сделать систему эффективнее, нам нужно внедрять подобные подходы. Задача HTAP-машины не в том, чтобы победить ClickHouse или DuckDB, а в том, чтобы на одном наборе данных эффективно выполнять и транзакционные, и аналитические нагрузки без копирования данных.
М.Г. — Тогда финальный вопрос — безопасность. Как с этим?
В.Я. — Во-первых, мы должны постоянно идти в ногу с новыми версиями Postgres, потому что там регулярно закрываются уязвимости (CVE). Сейчас требования ФСТЭК — устранять такие уязвимости очень быстро, вплоть до суток. Это накладывает жесткие ограничения. С другой стороны, мы ведем определенные наборы патчей и накладываем на open-source ветки в том числе. Это ускоряет разработку, в т.ч. внедрение функций безопасности, то есть то, что есть в сертифицированной версии СУБД Tantor Postgres, будет и в Tantor Polar. Плюс мы унаследовали часть механизмов безопасности из оригинального PolarDB — политики паролей, проверка логинов, шифрование (TDE) и так далее.
Мы идем в сертификацию, и в лабораторных условиях нас будут тщательно проверять. И я не вижу рисков с редакцией Tantor Polar — это не новая СУБД «с нуля», а развитие Postgres, знакомое специалистам.
М.Г. — То есть по сути — привычная система, но с новыми возможностями?
В.Я. — Верно. DBA, DevOps и разработчики, знакомые с Postgres, смогут быстро разобраться. Многое будет знакомо тем, кто работал с Greenplum — например, планировщик GPORCA и терминология. Еще раз, мы работаем над тем, чтобы выложить все в open-source, но хотим сделать это правильно, с документацией, а не просто «перекинуть через забор».
М.Г. — Лично для меня это базовая вещь. Для чего мы сейчас и беседуем — чтобы разобраться в новых технологиях, понять где мы сегодня и где будем завтра. А вы, как представитель одной из флагманских компаний, даете квалифицированный ответ: задачи уже можно решать на отечественных решениях. Есть поддержка, все нормально с безопасностью, и это не просто софт, а глубокая интеграция с железом. Плюс вы умеете работать с российским оборудованием — значит, и в эту сторону развитие будет. Правильно?
В.Я. — Да, конечно.
М.Г. — Тогда большое спасибо! Мне было очень интересно, надеюсь, и вам тоже.
