На этой неделе прошла конференция FireBird Conf, которая собрала разработчиков СУБД и прикладного программного обеспечения, администраторов и других специалистов, занимающихся разработкой и поддержкой баз данных. Участники обсудили последние обновления РЕД Базы данных, прорывные изменения в механизмах репликации и будущее Firebird 6.0, а также недостатки и преимущества актуальных СУБД рынка.
Дмитрий Еманов, архитектор СУБД РЕД Базы данных РЕД СОФТ team leader Firebird, сообщил, что в апреле текущего года вышел релиз Ред Базы данных 5.0.5, содержащий важные исправления в работе с JSON, оптимизатором запросов и репликацией. Поддержка старых версий осуществляется по определенному графику: с выходом новой версии прекращается поддержка релиза, выпущенного двумя версиями ранее.
На данный момент ведется разработка Firebird 6.0, которая уже вышла на завершающую стадию. Среди наиболее значимых нововведений – общий кэш метаданных для архитектуры суперсервера, значительно улучшающий производительность при работе с множеством подключений. Поддержка SQL-схем реализована с минимальным влиянием на существующий код. Разработчики отмечают, что для пользователей, не использующих схемы, ничего не изменится. Табличные пространства, портированные из Ред Базы данных 5.0, получили доработанную поддержку в утилитах резервного копирования. JSON-функции теперь соответствуют SQL-стандарту, с планами перехода на нативное хранение JSON вместо BLOB. Особый интерес представляет реализация гетерогенных запросов, позволяющих объединять данные из разных источников через JDBC-драйверы.
В Ред Базы данных 6.0 основной акцент сделан на трех ключевых направлениях. Первое – поддержка геометрических данных со стандартами OpenGIS и SQL/MM, включая типы GEOMETRY/GEOGRAPHY и все основные примитивы. Второе – реализация партиционирования с поддержкой диапазонного разделения и различных типов индексов. Третье – внедрение асинхронного ввода-вывода на базе современных технологий, показавшее на тестах двукратное ускорение операций. Особое внимание уделяется оптимизатору запросов – добавлена оценка стоимости для различных алгоритмов соединения, реализована сквозная оценка кардинальности, появились первые методы трансформации запросов. Однако разработчики признают существующие ограничения, такие как упрощенный учет селективности сложных условий и отсутствие гистограмм распределения значений.
Технические улучшения коснулись и работы с диском. Активно тестируются решения по многоблочному чтению и префектингу страниц, которые должны снизить нагрузку на подсистему ввода-вывода.
Артем Смирнов, заместитель начальника отдела разработки СУБД РЕД Базы данных РЕД СОФТ, рассказал, что РБД прошла путь от простых монолитных решений к сложным распределенным системам. Начальные реализации репликации на версии 2.6 отличались простотой и монолитностью архитектуры, предлагая два базовых типа репликации. Синхронная репликация работала по принципу «всё или ничего» – данные записывались на основной сервер и реплику одновременно, что гарантировало полную консистентность, но существенно снижало производительность, поскольку система ожидала подтверждения от всех узлов. Асинхронная репликация позволяла увеличить пропускную способность за счет определенной задержки в синхронизации – данные сначала фиксировались на основном сервере, затем передавались на реплики. Это создавало риск потери данных при сбоях, но обеспечивало высокую производительность под нагрузкой. Ранние версии были встроены непосредственно в ядро системы, что делало их быстрыми, но крайне негибкими. Архитектура передавала не физические блоки данных, а логические операции изменения, что позволяло экономить сетевой трафик, но усложняло восстановление после сбоев.
Следующее поколение РБД 3.0 совершило качественный скачок, представив полноценные кластерные решения. Среди ключевых инноваций этого периода – децентрализованная архитектура, где каждый узел превратился в самостоятельную единицу, что устранило единые точки отказа. Система начала использовать распределенное KV-хранилище для управления состоянием кластера, позволяя реализовать интеллектуальное управление ролями узлов. Теперь система могла автоматически перераспределять роли «ведущий – реплика» при сбоях без вмешательства администратора. Важным достижением стало использование распределенных блокировок при смене ролей узлов, позволившее создать самоорганизующуюся систему, где узлы могли координироваться без центрального «дирижера». Вынос журналов репликации в отдельное хранилище уменьшил критическую зависимость от общего диска – традиционного источника проблем в ранних кластерных решениях.
Современная версии РБД 5.0 довела механизмы репликации до нового уровня, решив многие исторические проблемы. Гибридный режим репликации сочетает преимущества синхронного и асинхронного подходов – система пытается сначала выполнить синхронную репликацию для критически важных данных, а при невозможности автоматически переключается на асинхронный режим, не блокируя работу. Интеллектуальная система синхронизации научилась определять отстающие узлы и выбирать оптимальную стратегию их восстановления, минимизируя время простоя. Децентрализованное хранение журналов, когда реплики сами генерируют журналы изменений, полностью устранило необходимость в рискованных общих дисках. Совершенствование механизмов восстановления незавершенных транзакций позволяет «спасать» данные даже после аварийного завершения работы ведущего сервера за счет анализа журналов на всех узлах. Особенно важным стало внедрение системы позиционирования данных, которая точно определяет, какие изменения уже были реплицированы, а какие нет, решив классическую проблему «разорванных транзакций», когда после сбоя было невозможно точно определить, какие данные считать достоверными.
На конференции также обсуждалась тема миграции между СУБД FireBird и PostgreSQL. Однако, как показывает практика, это принципиально разные решения, каждое со своими областями превосходства. Firebird демонстрирует преимущества в высоконагруженных транзакционных системах с тысячами простых запросов в секунду благодаря монолитной архитектуре и минимальным накладным расходам. В сценариях с короткими SELECT/INSERT-запросами Firebird обрабатывает на 15–20% больше операций в секунду на том же «железе». Кроме того, он отличается простотой обслуживания (резервное копирование одной командой gbak) и скромными требованиями к ресурсам. В то же время оптимизатор PostgreSQL справляется с многотабличными соединениями на 25–30% эффективнее, а поддержка JSONB, оконных функций и богатая экосистема расширений делают его универсальным выбором для сложных проектов. Однако за эту универсальность приходится платить повышенными требованиями к ресурсам и более сложным администрированием. Как отметил Александр Шапошников, инженер данных «Цифромед Лаб», «PostgreSQL – замечательная СУБД, но она отличается от Firebird».
Конференция продемонстрировала значительный прогресс в развитии СУБД Firebird и РЕД Базы данных. Представленные технологические усовершенствования свидетельствуют о последовательной работе специалистов над повышением конкурентоспособности продуктов. Будет интересно понаблюдать за последующими релизами и отзывами пользователей.
- ВКонтакте
- Telegram