Базы данных *

Друзья! У Петра вышло продолжение серии обзорных статей про 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Состоялся релиз мажорной версии открытого масштабируемого решения для кластеризации баз данных 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. Мы исправили несколько проблем с производительностью, доработали интерфейс и код», — пояснили разработчики, порекомендовав изучить документацию проекта и список исправлений.

Сегодня 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 к себе в поле зрения.