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

В текущей статье, рассмотрим темы - n+1, пагинация и индексы. Приятного чтения!

Описание приложения

Рассматриваемый проект - это веб-журнал посещений различных мест людьми с возможностью выгрузки и загрузки журнала в формате XML. Пользователь может загрузить журнал посещений в формате XML через форму на странице /upload, и на основе информации из файла будет заполнена база данных. Вся информация о посещениях будет отображаться на главной странице /index. Экспорт из системы осуществляется через команду, которая преобразует информацию из системы в формат XML и выгружает ее в файл (data.xml).

Привет Хабр! Последняя статья про инструменты для профилирования php датируется аж  2018 годом. Но все перечисленные решения разработаны много лет назад и имеют недостатки: древний интерфейс btp (аналог pinba), оверхед xhprof и необходимость ручного запуска phpspy на stage.

Я тимлид в рекомендательном сервисе Zoon и перед моей командой стояла цель найти инструменты, которые профилируют весь код на проде 24/7 и хранят данные. Инструменты, с которыми могут работать рядовые разработчики, без доступа к проду. Инструменты, которые позволяют находить "бутылочные горлышки" за 30 секунд.

В конце 2021 года показался свет в конце туннеля, в виде системы на основе семплирующего eBFP профайлера: prodfiler. 

С какими трудностями мы столкнулись при настройке и что вышло в итоге - под катом.

Привет, PHP-шники!

Вам знакомо то чувство, когда ваш PHP-код отрабатывает за дофига миллисекунд, а иногда и секунд, и вы не можете понять, в чём дело и где тот говнокод, который я (или не я, а мой коллега 😵‍💫) когда-то написал? В этой статье хочу немного рассказать на примере профайлинга PHP-кода, как перестать гадать и начать выявлять боттлнеки, которые всё тормозят. Короче, помочь поискать говнокод.

Swoole — высокопроизводительной асинхронный и многопоточный фреймворк для PHP. Он отличается от традиционной модели PHP-FPM, предлагая асинхронный ввод-вывод и корутины, а также возможность работать с веб-сокетами и различными сетевыми протоколами непосредственно в PHP.

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

Какие тренды последних лет усиливаются в PostgreSQL прямо сейчас? Как не устроить highload на ровном месте? Где почитать про мифы и реальность СУБД в облаках? Об этом и многом другом мы поговорили с Николаем Самохваловым. 

Николай — член программного комитета конференции HighLoad++, куратор секции Базы данных, а также основатель Postgres.ai и #RuPostgres.

Осенью 2023 года вышла Alpha-версия Percona Everest — нового продукта от компании Percona. Это cloud-native database platform — инструмент с графическим интерфейсом для управления кластерами баз данных, развёрнутыми в Kubernetes.

22 февраля 2024 года Percona Everest перешла в состояние Beta. Обновлённый продукт сильно отличается от первой версии — разработчики проделали большой объем работы. В сегодняшней статье разберём, как выглядит Beta-версия Percona Everest и как её установить. Также рассмотрим, чего не хватает инструменту, на наш взгляд, на текущий момент.

За короткое время Prometheus стал одним из самых популярных средств для мониторинга. Благодаря, в том числе, и высокой скорости своей работы. Его локальное хранилище отлично подходит для краткосрочного хранения метрик и работы с ними. Иногда хочется хранить метрики распределённо месяцы и годы, автоматически разрежая старые данные, но не меняя интерфейса работы с ними.

Как раз об этом расшифровка доклада Алексей Палажченко на RootConf 2018. В докладе: Prometheus, Local Storage TSDB, Remote Storage Prometheus, PromQL, TSDB, Сlickhouse, PromHouse, немного InfluxDB.

Кому интересно, прошу под кат.

Во второй части статьи про bitrix кластер мы будет рассматривать настройку percona xtradb cluster mysql 5.7, настройка арбитра, настройка удобного dashboard.
Если вы пропустили предыдущие части: Первая часть.

Существует множество проприетарных сервисов мониторинга БД, но есть отличная альтернатива с открытым исходным кодом — Percona Monitoring and Management (PMM). Я подробно расскажу, как настроить мониторинг с его помощью.

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

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

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

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

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

Одним из лидеров направления СУБД является PostgreSQL и ее различные ответвления, о некоторых из которых мы рассмотрим подробнее.

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

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

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

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

Для пагинации страниц используют смещение (OFFSET) и курсорную пагинацию (по ID), как более быструю. Тем не менее есть ещё один малоизвестный вид пагинации по меткам страниц (MARKS). Она является разновидностью курсорной пагинации, но использует не идентификатор, а ряд полей перечисленных в ORDER BY SQL-запроса.

DISCLAIMER: посыл этой статьи не в том, что «PostgreSQL — гавно, не используйте PostgreSQL». Посыл в следующем: «Может быть я чего-то не понимаю в этой жизни? Пожалуйста, объясните, может быть я изменю своё мнение!»

Это вторая часть моих копаний во внутренностях MySQL. В первой части [habr] были затронуты запись страниц данных на диск (с промежуточной записью в DoubleWrite buffer) и запись бинлогов (с батчингом в виде group commit). В этой части я расскажу про redo log и как все части MySQL координируются для достижения надежной работы.

Разработчики предъявляют высокие требования к базам данных: максимальная надежность (ничего из того, что было записано не должно быть утеряно ни при каких обстоятельствах), и, одновременно, максимальная производительность при различных видах нагрузки (Запись/Чтение или OLTP/OLAP). Достичь этих требований может быть не просто. Давайте попробуем разобраться, как это делает MySQL.

Размышляя о базе данных, легко представить таблицу базы данных как HashMap/BinaryTree, отображающие первичный ключ (primary key) в структурированные записи с данными. Такое хранилище может работать in memory. Но, как только мы захотим записать данные на диск, придется использовать какие-то алгоритмы во внешней памяти. Просто положить наш HashMap на диск не получится, потому что память и диски слишком разные: чтение/запись диска производится блоками, latency диска больше чем у RAM, а еще нельзя будет воспользоваться обычными указателями и аллокаторами памяти - все это придется заменить самостоятельно.

Один из важнейших аспектов, за которым должен следить каждый администратор баз данных PostgreSQL — процесс поддержания «здоровья» базы данных vacuum / autovacuum, удаляющий из памяти неактуальные версии табличных строк и сбрасывающий счётчик транзакций.

В этой статье я систематизировал особенности vacuum / autovacuum, с которыми сталкиваются администраторы MPP-РСУБД.