Базы данных *

Компания «РЕД СОФТ» заявила об обновление СУБД Ред База Данных 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 вручную.

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

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

В продолжении темы - "время отклика СУБД" https://habr.com/ru/posts/827054/

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

Допустим имеется OLTP нагрузка на СУБД - большое количество коротких запросов. В результате, имеем некоторое значение метрики "Среднее время отклика" = sum(total_exec_time) / sum(calls).

И вот , ситуация изменилась - запросов OLTP стало меньше , но появились аналитические/долгие запросы .

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

Является ли данная ситуация алертом для создания инцидента о деградации производительности СУБД ?

Конечно же - нет.

Более того - в этом случае резко увеличится количество обрабатываемых блоков разделяемой области.

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

P.S. Использование данной метрики оправдано только в одном сценарии - нагрузочное тестирование инфраструктуры при обязательном условии постоянства нагрузки на СУБД.

На днях опубликовал на GitHub свой скрипт 2013 года, который наполнял с ИБП Ippon Smart Winner 750 базу данных IBM DB2 данными по напряжению сети (за каждую секунду в течение года, по результатам наблюдений скорректировал уставки на реле напряжения, их безопасность для техники подтвердилась при отгорании нуля), обновлял статус моего DynDNS клиента по данным с роутера, запускал и останавливал виртуальную машину VMware Player (там у меня крутилась openSUSE с сайтом на Apache/Django) по расписанию и когда в планировщике BeholdTV была запланирована запись кабельного телевидения (это было необходимо, поскольку видео захватывалось в .asf/x264 - crf18/AC3 без использования графического ускорения и на всё ресурсов не хватало), следил за качеством ADSL линии. А сегодня дополнил ещё рядом скриптов: в 2014 перенёс сайт на Raspberri Pi (Arch Linux ARM) и там стал захватывать IPTV видео. Про захват у меня на Дзене можно почитать, а скрипы создания оглавления и некоторого контроля версии файлов (WSH/JS) опубликовал на GitHub здесь же. Также скрипты по установке времени и некоторой оптимизации скорости отклика сайта, мониторинга доступности посредством Online Domain Tools. Ещё дополнил своими Windows скриптами по работе с СУБД IBM DB2 Express-C и её оптимизации по книге "Best practices Tuning and monitoring database system performance" (она тоже выложена в соответствии с лицензией). Изначально не включил библиотеку RGraph для построения графиков, теперь выложил под лицензией MIT 2013 года.

О мониторинге СУБД.

Классическая метрика -"Время отклика СУБД" - в реальной жизни бесполезна.

Причина - подверженность ошибке 1-го и 2-го рода.

1) Во время аварии отклик СУБД может не только не расти, но даже уменьшаться.

2) Рост времени отклика может быть вызван снижением нагрузки на СУБД.

На днях вышел из строя ИБП. Переключился на стабилизатор. Было уже. До техники APC стоял ИБП Ippon Smart Winner 750. Мониторил напряжение. Сохранял в базе данных SQL сервера IBM DB2 Express-C 10.5 данные за каждую секунду и хранил в течение года. Это помогло выставить уставки на реле напряжения и нормально пережить несколько отгораний нуля без потерь для техники. Скрипты соответствующие опубликовал сегодня на GitHub у себя. При работе от стабилизатора приходилось потом чинить неоднократно SQL базу данных, благо у меня было настроено журналирование в "Архивном" режиме, а сама база данных периодически тестировалась на наличие повреждений. Сложнее с остальной частью данных на компьютере: в NTFS принято частичное журналирование и внезапное отключение ведёт к необходимости решать, восстанавливать ли из бэкапа или соглашаться с тем, что возможно какие-то повреждения будут не сразу обнаружены и могут вызвать проблемы с дальнейшим ремонтом. Чуть раньше такой же пост на Дзене у себя опубликовал.

Утилита pgpro_pwr имеет одну очень серьезную проблему - жестко установленное расписание сбора снимков с помощью take_sample.

Чтобы получить выборки со всех включённых серверов, вызовите функцию take_sample(). Обычно достаточно получать одну-две выборки в час. Для выполнения этой функции по расписанию можно воспользоваться планировщиком cron или подобным.

Последствия:

1)Невозможно собрать статистику производительности и состояния СУБД во время инцидента производительности . Например, если снимки собираются по рекомендации, указанной в документации - каждые полчаса , то практически нельзя ничего сказать о состоянии СУБД в течении 5-10 минут, в которые было зафиксировано снижение производительности в середине 30-ти минутного промежутка.

2) Ожидания в разделе "Top waits" не коррелированы с показателями производительности СУБД. Отчет показывает ожидания отсортированные по времени. И только за весь период снимка. Установить, какое именно ожидание/ожидания (и следовательно запрос/запросы) повлияло/повлияли на деградацию производительности СУБД во время инцидента - практически невозможно.

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

• 11:10 - 13:20 : Нисходящий тренд (снижение производительности )

• 13:30 - 15:40 : Восходящий тренд ( рост производительности )

Казалось бы, в период 11:10-13:20 - инцидент деградации производительности.

НО.

Корреляционный анализ событий ожиданий и показателей производительности показал – корреляция между событиями ожидания и изменением производительности в период 11:10 – 13:20 - отсутствует.

Вероятнее всего, из данного факта следуют следующие выводы:

1. Аномалии СУБД в период 11:10 - 13:20 – отсутствуют

2. Снижение производительности СУБД вызвано внешними причинами (снижение количества подключений, изменение характера запросов, снижением числа запросов и т.д. и т.п. ) .  Т.е. причинами, находящимися вне зоны ответственности DBA.

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

1) Статистика производительности СУБД- скользящие средние , стандартное отклонение , дисперсия : полезно для оценки текущего состояния и подготовки baselines и оповещений по проблемам производительности.

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

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

4)Быстрые/медленные скользящие средние, тренды, свечи, уровни поддержки - это просто красиво :-) Манагерам нравятся красивые картинки.

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

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

DuckDB поддерживает расширенный диалект языка SQL, включающий дополнительные возможности для обработки очень сложных и длительно выполняемых запросов. Например, возможно использование сложных типов (массивы, структуры, объединения), а также выполнение произвольных и вложенных коррелирующих подзапросов. Поддерживается одновременное выполнение нескольких запросов, выполнение запросов напрямую из файлов в формате CSV и Parquet. Доступна поддержка импорта из СУБД PostgreSQL.

Источник: OpenNET.

Мысли вслух - DBA ремесло или наука ?

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

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

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

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

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

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

P.S.Пример из жизни - имеется пул соединений к СУБД - как определить, что характер нагрузки изменился ?

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

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

2. Количество соединений с конкретного ip и показателем производительности СУБД

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

IO ControlFileSyncUpdate -0,155750768

Client ClientWrite -0,132699875

LWLock XactSLRU -0,123296926

...

Отрицательная корреляция между количеством соединений с конкретного ip и показателем производительности СУБД - умеренная:

XX.XXX.XXX.1 -0,43280346

XX.XXX.XXX.2 -0,41262827

XX.XXX.XXX.3 -0,409033529

XX.XXX.XXX.4 -0,388472

XX.XXX.XXX.4 -0,376145747

...

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

SQL vs NoSQL: как выбрать архитектуру БД для мобильного приложения

SQL (Structured Query Language) — это язык запросов, которые мы используем для работы с реляционными базами данных. У таких БД жесткая структура в виде таблиц. Вся информация там хранится в столбцах и строках. Структурированность — одно из главных преимуществ SQL баз данных.

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

Чтобы выбрать между SQL и NoSQL, нужно исходить из задач бизнеса.

• Если вы делаете маленькое приложение на узкую аудиторию или MVP, можно смело выбирать NoSQL. Такие базы быстрые, с ними проще работать, они легко масштабируются. А если проект растет как на дрожжах — NoSQL можно быстро переписать на SQL.

• Если вы делаете средний по объему проект, лучше SQL. Хотя, если очень хочется, можно и NoSQL. Но тут есть особенности: выбирайте NoSQL, только если у вас есть налаженные ивенты, налаженная имплементация баз данных и опыт работы с NoSQL.

• Если вы делаете энтерпрайз, лучше выбрать SQL. Представим, что в каком-то крупном маркетплейсе 10 тысяч человек оплатили покупки, но не получили товары, потому что транзакция данных прошла некорректно. Цена ошибки тут слишком высока — поэтому SQL.

Больше подробностей — в нашем блоге.