Базы данных *

Вышла новая версия Ред Эксперт 2024.10. В обновлении внесены улучшения и исправления, обеспечивающие более удобное взаимодействие с системой.

Основные изменения:

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

• 24 исправления ошибок: устранены проблемы с SQL выражениями, генерацией запросов и улучшена работа с подключениями;

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

Ознакомиться с полным списком обновлений сайте или GitHub.

Чем дольше копаю тему статистического анализа производительности СУБД, тем больше удивляюсь - почему никто не занимался/не занимается использованием математических методов в DBA ? Статей и материалов практически - нет. По performance engineering - можно найти, по DBA в общем то тишина.

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

Это же так просто и в общем то лежит на поверхности - сделал изменение , собери статистику влияния и оцени характер полученных результатов по совокупности опытов. Нужно подчеркнуть - не картинки, не "кажется" , "наверное" , "скорее всего", "может быть" , а цифры. И цифры взятые не с потолка , а рассчитанные математически. И даже не надо ничего нового придумывать и изобретать - медиана, мода , стандартное отклонение , дисперсия , корреляция - 3й курс КАИ, если не ошибаюсь. Вполне достаточно , для получения объективных результатов анализа, а не гаданий и шаманских танцев с бубнами.

Почему DBA не используют математику ? Риторический вопрос ....

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

1. Пиксы запустили Цифровой триатлон. Каждую неделю идет трек по одной из платформ. На этой неделе экватор по PIX BI. Много экспертов, много мнений, весь контент очень сильно связан с ex Qlik тусовкой. Клиенты, эксперты, организаторы - все когда то занимались, внедряли, обучали Qlik. Такое импортозамещение даже получается. https://triathlon.pix.ru Информацию кидают в группу в телеге: https://t.me/BI_PIX_Chat Плюс компания анонсировала БЕСПЛАТНУЮ персональную редакцию своей платформы. Надеемся это не разводняк! 

2. Коллеги из Глобайт привезли Азиатский вариант марафона. Ретрит по теме Fine Bi. Вся информационная поддержка идет в группе https://t.me/FineBIChat в разбивке по темам. Много интересного, новые фичи, опыт клиентов. Классика марафонов от Дата Йога.

3. AW запустили на наш взгляд тяжелую, но очень интересную историю для конкретной группы продвинутых аналитиков. Все подробности в группе https://t.me/awcommunity такой марафон, который перетекает в хакатон и заканчивается собственной конференцией в Москве. 

Отличная возможность попробовать три разных блюда, не выходя из дома! Вперед к новым знаниям!

Вышло обновление СУБД Ред База Данных от компании «РЕД СОФТ». Обновление касается рекомендованной сертифицированной версии. СУБД Ред База Данных (Red Database) — это российская промышленная система управления базами данных с открытым кодом, ядром которой выступает СУБД с открытым кодом Firebird.

В список исправлений СУБД Ред База Данных 3.0.17 вошли:

• повреждение памяти в сетевой части сервера;

• создание базы данных в последних версиях 3.X и 5.X медленнее чем в предыдущих релизах;

• неправильная проверка зависимостей при alter column;

• возможность обработки больших (32k+) сообщений в tracemgr;

• ошибка при объявлении процедур внутри процедуры без SET TERM;

• перечитывание конфигурации трейса для сервисов;

• запись ошибки агрегатного трейса в лог, если это возможно;

• запись в логе об остановке сервера при завершении rdbtracemgr;

• редкое падение при завершении rdbtracemgr.

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

5 сентября вышло обновление мультиплатформенного менеджера СУБД Ред База Данных и Firebird от компании «РЕД СОФТ» под названием Ред Эксперт. В обновлении Ред Эксперт 2024.09 исправили ошибки и повысили стабильность работы программы. Всего было внесено 13 улучшений, 31 исправление и 10 нововведений.

Вышло обновление мультиплатформенного менеджера СУБД Ред База Данных и Firebird от компании «РЕД СОФТ» под названием Ред Эксперт. В обновлении Ред Эксперт 2024.09 исправили ошибки и повысили стабильность работы программы. Всего было внесено 13 улучшений, 31 исправление и 10 нововведений.

Среди нововведений были добавлены:

• библиотеки fbclient для RedDatabase с версиями 3, 4 и 5;

• уведомление об ограничении количества возвращаемых записей;

• проверка корректности пути к файлу перед экспортом данных таблицы;

• возможность удаления данных из таблиц мониторинга (MON$...);

• индикаторы подключенных баз данных в поле выбора соединения;

• отображение номеров строк по умолчанию в таблице набора результатов.

Также были внесены следующие улучшения:

• панель инструментов редактора ER‑диаграмм;

• обновлен список баз данных для драйверов JDBC;

• обновлены драйверы Jaybird до версий 4.0.30 и 5.0.18;

• обновлены версии пакетов Java Native Access и Java Native Access Platform и так далее.

Кроме того, были исправлено:

• генерация ER‑диаграмм;

• загрузка ER‑диаграммы из файла;

• NPE при открытии панели «Редактирование функции»;

• выполнение SQL‑скриптов с параметрами;

• выполнение SQL‑скриптов без оператора «SET TERM»;

• активность инструментов OO API в инструменте «Генератор тестовых данных»;

• генерация SQL‑запросов для удаления UDF;

• генерация SQL‑запросов для процедур и функций и многое другое.

Полный список доступен всех изменений можно найти на сайте СУБД РЕД База Данных и на GitHub.

Компании «РЕД СОФТ» и «Анлим‑Софт» провели тестирование совместимости продуктов из своих экосистем. В рамках тестирования система сбора данных с досмотровых комплексов «АРГОС» показала, что стабильно работает с СУБД Ред База Данных, передавая поступающую информацию для обработки, хранения и классификации.

Система «АРГОС» осуществляет сбор и обработку информации со всех типов досмотровых комплексов. Решение позволяет консолидировано собирать и хранить информацию о триггерных событиях (срабатываниях), обрабатывать их и связывать с фото и видеофрагментами для более быстрой идентификации потенциального нарушителя. Система прошла обязательную сертификацию в рамках Постановления Правительства № 969 от 26.09.2016 «Об утверждении требований к функциональным свойствам технических средств обеспечения транспортной безопасности и Правил обязательной сертификации технических средств обеспечения транспортной безопасности».

СУБД Ред База Данных обеспечивает стабильную и наглядную работу с данными, поступающими от системы «АРГОС». Безопасность СУБД от компании «РЕД СОФТ» подтверждена сертификатом соответствия № 2729 ФСТЭК России: решение полностью соответствует новым Требованиям по безопасности информации к системам управления базами данных, утвержденных приказом ФСТЭК России № 64 от 14 апреля 2023г., по 4 классу защиты. Решение можно применять в инфраструктурах с повышенными требованиями к информационной безопасности, а также использовать для хранения и обработки персональных данных.

Обновился драйвер поддержки Django 5.0 для Firebird и СУБД Ред База Данных. Теперь пользователям СУБД Ред База Данных и Firebird доступен фреймворк Django 5.0. Это актуальная версия фреймворка, важными особенностями которой являются:

• поддержка Python 3.10, 3.11, и 3.12;

• возможность указывать вычисляемые значения по умолчанию, используя свойство db_default для Field;

• поддержка функции GeneratedField для генерации данных в полях базы;

• возможность использования асинхронных методов как для Client, так и для AsyncClient.

Список изменений для драйвера django‑firebird:

• добавлена поддержка Django 5.0;

• добавлена поддержка частичных индексов;

• добавлена поддержка оконных функций;

• добавлена поддержка TIME WITH TIME ZONE и TIMESTAMP WITH TIME ZONE для TimeField и DateTimeField;

• добавлена поддержка массовой вставки данных (bulk insert);

• обновлен firebird‑driver до версии 1.10.4.

Полный список изменений можно посмотреть на GitHub проекта.

Группа компаний «Гарда» и «РЕД СОФТ» подтвердили совместимость обновленных версий СУБД Ред База Данных и «Гарда DBF». Система «Гарда DBF» стабильно контролирует запросы к системе управления базами данных от «РЕД СОФТ» и защищает чувствительную информацию.

Совместное внедрение СУБД Ред База Данных и «Гарда DBF» поможет компаниям не только выполнять требования регуляторов по защите данных, но и своевременно пресекать возможные утечки по вине недобросовестных сотрудников.

«Гарда DBF» (ранее «Гарда БД») — система для обеспечения безопасности СУБД и независимого аудита операций с базами данных и бизнес‑приложениями. Предназначена для защиты от утечек уничтожения, изменения, копирования информации и несанкционированного ее распространения. «Гарда DBF» ведёт непрерывный мониторинг обращений к ресурсам и в режиме реального времени выявляет подозрительные операции. Зарегистрирована в Едином реестре отечественного ПО. Сертифицирована ФСТЭК России по классу НДВ-4.

СУБД Ред База Данных — промышленная российская система управления базами данных. Команда РЕД СОФТ самостоятельно и независимо развивает продукт и оказывает высококвалифицированную техническую поддержку. Поддержка оказывается на всех уровнях: от настройки, сопровождения и аудита до внесения самых сложных изменений в код СУБД.

В развитии темы

Нагрузочное тестирование СУБД в облачной среде — часть 2. Итоги и результат https://habr.com/p/837462/

Методика проведения нагрузочного тестирования .

Задача

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

Проблема

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

Гипотеза

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

Из гипотезы следует решение задачи:

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

2. Статистические результаты найденной выборки - будут решением задачи.

Дополнение по итогам анализа результатов проведенных экспериментов

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

Достаточно выполнение условия симметричность распределения: Медиана = Мода.

Полученные средние значения ( медиана/моде) производительности будут исходным набором данных.

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

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

Дополнение

Запускать нагрузку необходимо в течении суток.

19 сентября в московском офисе Ситидрайва пройдет очередной митап на тему «Уникальность работы с Kubernetes» – присоединяйся к нам!

Инженеры из команды Ситидрайва, OKKO и Positive Technologies расскажут об особенностях эксплуатации с использованием Kubernetes: только кейсы из практики и личный опыт. В завершение каждого доклада можно будет задать вопросы и пообщаться со спикерами в неформальной обстановке. А после мероприятия – подкрепиться закусками, погулять по офису и познакомиться друг с другом поближе.

Программа:

18:00-18:30 | Сбор в офисе Ситидрайва, знакомство и Welcome

18:30-19:00 | Доклад «Управление и мониторинг баз данных с помощью k8s»

Спикер: Анатолий Тимченко — Team Lead DBA в Ситидрайве.

19:10-19:40 | Доклад «Talos платформа для k8s в OKKO»

Спикер: Алексей Романов — Lead of Kubernetes в OKKO.

19:40-20:10 | Нетворкинг

20:10-20:40 | Доклад «Kubernetes: master внутри cluster-а»

Спикер: Максим Залысин — Head of DevOps в Positive technologies

20:45-21:15 | Доклад «Переезд монолита с ВМ в k8s»

Спикер: Александр Григоров — Заместитель технического директора по эксплуатации в Ситидрайве.

21:15-22:00 | Нетворкинг

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

Всем привет!

Завтра, 22 августа, приглашаем на вебинар, чтобы поговорить про Кафку и научиться разворачивать кластер на своём железе:

«Поднимаем Кафку, не опуская руки. Отказоустойчивый кластер на вашем ПК»

На вебинаре: 

• Расскажем про язык Кафки: топики, партиции, продюсеры-консьюмеры, кластер, ноды. 
• Рассмотрим принципы её работы: как работают очереди сообщений, сколько должно быть консьюмеров для эффективной вычитки, как повысить надёжность кластера с помощью репликации данных.
• И покажем, как развернуть кластер Кафки на своём ПК с 3 нодами, schema-registry и авторизацией.

Обычно в инструкциях кластер из 1 ноды, зукипера и 1 брокера, но это не наш путь. Будем работать с реальными исходными данными, а не на теоретических примерах!

На вебинаре пройдёт и традиционный розыгрыш — один из участников получит бесплатное место на курс «Apache Kafka для разработчиков».

Спикер — Василий Калугин, владелец корпоративного сервиса Apache Kafka в АО «ЭР-Телеком Холдинг». 

📌 22 августа в 14:00 мск
📌 Занять место на вебинаре — по ссылке. 

Компания «РЕД СОФТ» заявила об обновление СУБД Ред База Данных 3.0. В августе 2024 года специалисты компании активно работали над функционалом, повысили комфорт взаимодействия с СУБД и внесли 18 исправлений.

Среди нововведений СУБД Ред База Данных v3.0.16:

• Таймаут ожидания при завершении подключений через guardian увеличен до 30 минут;

• Новый параметр конфигурации «LDAPConnectionRetries»: количество попыток подключения к серверам из списка LDAPServer;

• Новая контекстная переменная «LDAP_SERVER» в пространстве «AUTHDATA»;

• Возможность изменять тип BLOB‑поля на другой тип BLOB, совместимый с ним;

• Поиск пользователя SYSDBA теперь выполняется только в БД безопасности (не в LDAP);

• Добавлен плагин агрегатного трейса;

• Возможность аудита базы, которая хранит данные о своих же пользователях (self‑security);

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

Полный список улучшений представлен на сайте.

19 августа СУБД Ред База Данных подтвердила соответствие новым требованиям по безопасности информации к системам управления базами данных ФСТЭК России.

Компания «РЕД СОФТ» успешно завершила сертификационных испытаний СУБД Ред База Данных. Сертификат соответствия ФСТЭК России №2729 продлен до 8 октября 2028 года для версий 3.0 и 5.0. Испытания показали, что СУБД Ред База Данных полностью соответствует требованиям по безопасности информации к СУБД, утвержденным приказом ФСТЭК России №64 от 14 апреля 2023 года., и предлагает пользователям 4 класс защиты. Сохранилось соответствие 4 уровню доверия, требования к которому зафиксированы в приказе ФСТЭК России №76 от 2 июня 2020 года.

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

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

• Значимых объектах критической информационной инфраструктуры (1 категория значимости);

• Государственных информационных системах (1 класс защищенности);

• Автоматизированных системах управления производственными и технологическими процессами (1 класс защищенности);

• Информационных системах персональных данных (1 уровень защищенности);

• Информационных системах общего пользования II класса.

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

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

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

Или проще говоря - нет никакой возможности предсказать производительность СУБД по детерминированным входным параметрам : количество соединений , QPS , TPS , etc.

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

Продолжаем улучшать наш инструмент анализа планов PostgreSQL explain.tensor.ru. Сегодня мы представляем новую подсказку-рекомендацию и расширенный вариант визуального представления хода выполнения (посмотреть пример):

Ловим кривые индексные условия

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

Зачастую оказывается, что виной тому передача в качестве параметра-массива для ключа индекса какого-то заведомо-ложного условия типа пустого массива (= ANY('{}'::integer[])) или NULL (= ANY(NULL::integer[])).

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

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

Ход выполнения запроса

Выполнение запроса - это проход дерева плана "снизу - вверх", но сам план при этом представляет из себя дерево "сверху - вниз". Неудобненько...

Помимо узлов самого плана, в полное время выполнения запроса входит плюсом еще и время планирования (Planning Time) и время передачи данных (Execution Time), которые могут составлять весьма солидную долю.

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

Закрытие темы "Гипотеза о связи относительного количества ожиданий СУБД и производительности СУБД "

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

Для проверки гипотезы была проведёна серия экспериментов по 3-м сценарям:

1) Базовая(эталонная) нагрузка.

2) Дополнительная нагрузка на CPU/RAM.

3) Очередь ожидания освобождения блокировки строк/таблиц.

Итог: Гипотеза не подтверждается экспериментальными данными : разница в соотношении между ожиданиями составляет ~3% , при деградации производительности ~34%.

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

Таким образом - изменение соотношения между ожиданиями СУБД не может являться индикатором деградации производительности.

Тема закрыта. Статья снята с публикации.

P.S. Однако, в ходе экспериментов, получен интересный побочный результат:

При использовании pgbench c параметром "--connect", отношение количества ожиданий влияющих на производительность, к количеству ожиданий не влияющих на производительность - существенно отличается (~38%).

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

О способе оценки производительности отдельного SQL запроса .

В дополнении к теме:

Размышления о мониторинге производительности отдельного SQL запроса

Для возможного варианта решения задачи:

https://habr.com/ru/posts/833162/

если производительность отдельного SQL запроса в настоящее время не мониторится.

Предположение.

Для того, чтобы оценить производительность отдельного SQL запроса необходимо и достаточно получить отношение стоимости запроса (EXPLAIN ANALYSE) к актуальному времени выполнения запроса .

Важное следствие и ограничение:

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

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

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

Разверните базу данных на выделенном облачном сервере ⚡️

Преимущества DBaaS на выделенном облачном сервере

• Максимальная производительность,

• Экономическая выгода,

• Быстрый запуск,

• Безопасность.

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

• Собрали конфигурации серверов с высокочастотным процессором Intel® Xeon® Gold 6240 в односокетной сборке с включенным Turbo Boost и Hyper-threading. 

• Используем специальные планки оперативной памяти ECC REG, рекомендуемые для СУБД.

• Для дополнительной отказоустойчивости добавили дисковую подсистему на сверхбыстрых NVMe SSD дисках компании Intel, собранных в RAID1.

• Оптимизировали настройки всех систем на сервере от BIOS до ОС.

Создайте базу данных →

К вопросу о важности определения понятия "производительность СУБД".

Пусть имеется некий запрос к СУБД, который важно мониторить с точки зрения эффективности и качества работы.

Сценарий 1: запрос выдает N1 строк и выполняется за время T1.

Сценарий 2: запрос выдает N2 строк и выполняется за время T2.

Вопрос: можно ли утверждать о инциденте в случае Сценария 2, если "T2 > T1 И N2 > N1" ?

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

Друзья! У Петра вышло продолжение серии обзорных статей про ClickHouse — open-source OLAP базу данных, ориентированную на колонки. В новой статье наш DevOps-инженер рассказывает про особенности репликации в этой СУБД.

Из этой части вы узнаете:

• как работают сервисы координации Zookeeper и ClickHouse Keeper;

• по какой причине может произойти падение репликации;

• почему не следует очищать Keeper вручную.

Чтобы вспомнить, о чём Пётр рассказывал в первой части — нажмите сюда.

А чтобы ознакомиться с новой частью — сюда.