Как стать автором
Обновить
116.75

Администрирование баз данных *

Все об администрировании БД

Сначала показывать
Порог рейтинга

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

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

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

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

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

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

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

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

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

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

Теги:
Всего голосов 3: ↑1 и ↓20
Комментарии0

На днях опубликовал на 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: ↑1 и ↓0+3
Комментарии0

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

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

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

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

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

Теги:
Всего голосов 2: ↑1 и ↓1+2
Комментарии6

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

Теги:
Всего голосов 1: ↑1 и ↓0+1
Комментарии0

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

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

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

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

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

Теги:
Всего голосов 1: ↑1 и ↓0+3
Комментарии0

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

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

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

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

НО.

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

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

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

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

Теги:
Всего голосов 4: ↑1 и ↓30
Комментарии0

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

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

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

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

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

Теги:
Всего голосов 5: ↑2 и ↓3+3
Комментарии2

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

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

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

Источник: OpenNET.

Теги:
Всего голосов 3: ↑3 и ↓0+6
Комментарии0

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

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

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

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

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

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

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

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

Теги:
Всего голосов 3: ↑3 и ↓0+5
Комментарии0

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

  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

...

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

Теги:
Всего голосов 1: ↑1 и ↓0+3
Комментарии0

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

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

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

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

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

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

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

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

Теги:
Всего голосов 17: ↑10 и ↓7+3
Комментарии3

ГАС Правосудие взломали. В Багдаде всё спокойно.

На моей практике возникла весьма интересная ситуация, связанная с тем, как дело в районном суде могут отдать нужному судье, а затем просто "потерять" из статистики и учёта в апелляции и кассации. И всё это связано с работой в АИС, ГАС или тем, что объединено под названием ГАС "Правосудие".

И так. Решив всё же описать ситуацию, я с огромной долей вероятности предполагаю, что подобные технические манипуляции с ГАС Правосудие, АМИРС, МРД и прочими многочисленными и таинственными составляющими электронного правосудия в России, позволяют успешно "решать вопросы" по заказу (по звонку или как там ещё было когда-то принято).

Связано это с уникальным идентификатором дела (УИД), который был введён в 2019 для привязки всех производств к единому номеру, с целью контроля и учёта.

В районном суде делу в 2021-м году был присвоен "УИД 0". Дело с номером "2-...". Модулем автораспределения (МРД) не пользовались. Протокола распределения нет. Клиент не заметил этого, прошёл апелляцию и кассацию (безуспешно и очень удивительно, что там не заметили нарушение).

Но! Самое интересное. В ВС РФ (Верховный Суд Российской Федерации) жалобе присвоили УИД от другого дела, не имеющий к нашему делу никакого отношения. Как?

Видимо это нормальная практика, когда Верховный Суд РФ, не имея возможности просто проставить "0" в системе в поле УИД, присваивает производству какой-то левый номер?

Сталкивались ли вы с такими казусами, и есть ли в таких трюках состав 274 УК РФ?

Теги:
Всего голосов 1: ↑1 и ↓0+3
Комментарии1

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

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

  • Количество соединений

  • Утилизация CPU

  • Утилизация RAM

  • Утилизация I/O

  • Количество ожиданий СУБД

  • Показатели CPU (iowait и т.п)

  • Показатель Cache Hit Ratio

  • Объем обработанных блоков shared_buffer

  • Что-то еще из огромного списка метрик

Теги:
Всего голосов 3: ↑2 и ↓1+3
Комментарии7

Ближайшие события

Google Firebase сдался и добавил в свои сервисы SQL базу данных (облачную PostgreSQL) в форме Firebase Data Connect.

Пока в виде preview сервис можно попробовать бесплатно. Потом собираются брать плату и за саму базу, и за API доступа к ней.

Вряд ли Google с такими политиками сможет конкурировать с Supabase.На данный момент это две основные площадки, с которыми фронтендер или мобильный разработчик может без излишних усилий сделать удобный облачный бэкенд, как без логики (просто CRUD доступ), так и с ней (Functions), и оставаясь в рамках стандартов (не сильно привязываясь к проприетарным решениям сервисов).

Теги:
Всего голосов 1: ↑1 и ↓0+3
Комментарии0

Всем привет! Мы продолжаем обзор Redis — системы хранения данных в виде структур. 

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

Если суперкратко:

  • Репликация в Redis ассинхронна. 

  • Репликация не блокируется на стороне мастера. 

  • Репликация (почти) не блокируется на стороне слейвов. 

  • У мастера может быть любое количество реплик.

  • Каждый слейв может выступать мастером для другого инстанса.

А ещё в конце вас ждёт приятный бонус в виде разбора атаки на Redis через H2Miner, из-за которой можно полностью потерять данные на инстансе Redis

Нажмите сюда, что начать читать.

Теги:
Всего голосов 4: ↑4 и ↓0+5
Комментарии0

Команда проекта MariaDB сообщила, что MariaDB Server 11.4 будет выпускаться с долгосрочной поддержкой (LTS).

В начале февраля разработчики объявили, что корректируют модель выпуска MariaDB Server. В рамках этого мероприятия они запланировали выпуск в рамках LTS MariaDB Server 11.7, которая планируется к выпуску в январе 2025 года.

«Чтобы наши текущие функции раньше стали широко использоваться, мы решили добавить MariaDB Server 11.4 в LTS, чтобы удовлетворить потребности пользователей MariaDB 11, ожидающих полных пяти лет исправлений ошибок в выпуске с заблокированным набором функций», — пояснили разработчики проекта.

Теги:
Всего голосов 6: ↑6 и ↓0+6
Комментарии0

Скидка 20% на комплект сервисов

Managed Kubernetes, облачные базы данных и объектное хранилище S3.

Запускайте и развивайте веб-проекты любой сложности с помощью отказоустойчивых и масштабируемых сервисов Selectel. До 30 июня подключите три сервиса: Managed Kubernetes, облачные базы данных и объектное хранилище S3 — и пользуйтесь ими со скидкой 20%.

Оплачивайте Managed Kubernetes, базы данных и хранилище по модели pay-as-you-go. Скидка действует в течение всего времени, пока вы используете комплект сервисов.

Как получить скидку?

1️⃣Зарегистрируйтесь в панели управления.

2️⃣Подключите Managed Kubernetes, облачные базы данных и объектное хранилище в подходящих вам конфигурациях.

3️⃣Оставьте заявку в тикет-системе. Напишите, что участвуете в этой акции, и укажите примерную сумму, которую планируете тратить на каждый сервис

4️⃣Дождитесь ответа от поддержки и пользуйтесь сервисами с ежемесячной скидкой 20%.

Подключайте сервисы со скидкой →

Теги:
Всего голосов 2: ↑2 и ↓0+2
Комментарии0

Состоялся релиз мажорной версии открытого масштабируемого решения для кластеризации баз данных MySQL — Vitess 19. Исходный код проекта опубликован на GitHub под лицензией Apache License 2.0.

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

Изменения и дополнения в Vitess 19:

  • прекращение поддержки MySQL 5.7. Разработчики советуют пользователям выполнить обновление до MySQL 8.0, используя Vitess 18, прежде чем переходить на Vitess 19. Однако Vitess 19 по-прежнему будет поддерживать импорт из MySQL 5.7;

  • добавлены новые метрики для консолидации потоков и версия сборки в /debug/vars, чтобы обеспечить более глубокое понимание и отслеживаемость;

  • улучшена совместимость запросов, реализована поддержка операций удаления из нескольких таблиц, новый запрос SHOW VSCHEMA KEYSPACES и несколько других улучшений синтаксиса SQL, которые расширяют совместимость Vitess с MySQL;

  • поддержка отсрочки попыток переключения в случае блокировки. Поддержка принудительного отключения;

  • улучшение процесса инкрементного резервного копирования: поддержка имён резервных копий и пустых резервных копий.

«Следуя тенденции последних трёх лет, новая версия Vitess быстрее предыдущей во всех тестах, которые мы отслеживаем в Arewefastyet. Мы исправили несколько проблем с производительностью, доработали интерфейс и код», — пояснили разработчики, порекомендовав изучить документацию проекта и список исправлений.

Теги:
Всего голосов 3: ↑3 и ↓0+3
Комментарии0

Сегодня DataBanksy побывал на онлайн мероприятии ребят из Analytics Workspace. По сути это компания из портфеля проектов Барс, там же, кстати, и альфа BI. Цель онлайн встречи - подвести итоги хакатона и рассказать о своей дорожной карте. В жюри позвали ребят из тусовки Russian BI Chat.

Если сделать короткое заключение, то:

  1. Дорожная карта есть, она краткосрочная. Все, что в долгосроке находится под грифом секретно со слов вендора.

  2. Идут в сторону self service. Под капотом апач линейка. Пытаются решить проблему с гибкими фильтрами, это кстати в качестве большого минуса отметил и клиент-спикер. Фильтры - это задача #1, исходя из объема информации от вендора. Интересно, смогут ли победить болезнь…

  3. Будут добавлять новые виджеты, делать дашборды под разные экраны (автоматом не масштабируется сейчас), пользовательские представления и другое.

  4. Отдельно рассказали о развитии ETL. Третий вендор который осознал, что нужно делать коннектор к Qvd, формат внутренней хранилки Qlik Sense. Понравилась идея с ETL Store, где можно делать свои блоки и делиться ими. Интересно будет посмотреть на работу отладчика с автоматическим поиском ошибок и выдачей рекомендаций.

  5. Не очень выглядел пассаж про работу со 150 млрд записей в неком ритейлере под нагрузочные тесты, как единственный вендор в РФ с такими метриками. Если речь шла про некий direct query, то так и говорите об этом. Дашборд на 150 млрд записей на одной ноде представить не можем!

  6. Пицца dashboard win!

Добавили AW к себе в поле зрения.

Теги:
Рейтинг0
Комментарии0

​​Увеличили производительность облачных баз данных ?

Чтобы вы могли выжать максимум из облачных баз данных, мы прокачали их еще сильнее, а именно: 

? увеличили параметры IOPS в 3,5 раза (до 90 000 IOPS).

? и пропускной способности — в 2,5 раза (до 1 000 МБ/c на нашем железе).

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

Нужно еще больше?
По запросу через тикет можем увеличить: 

? IOPS — до 120 000.

? пропускную способность — до 1 200 МБ/с.

Создайте облачную базу данных в Selectel, чтобы получить быстро работающее приложение даже в периоды максимальной нагрузки ➡️

Теги:
Всего голосов 5: ↑5 и ↓0+5
Комментарии0