Будучи активным пользователем хранилища данных (DWH) на разных ролях, я всегда находил определенные ограничения (и разочарования!) в связи с задержкой данных между нашим DWH и данными, которые находятся в онлайновых транзакционных (OLTP) базах данных. В зависимости от того, где я работал, задержка составляла от нескольких часов до суток (дней), причем более крупные компании, как правило, работали медленнее.
В этой статье мы разберём несколько аномальных случаев высокой нагрузки в СУБД PostgreSQL. Что это такое? Обычно PostgreSQL хорошо показывает себя под нагрузкой и оправдывает ожидания в отношении производительности — она остаётся высокой. Но при определённых профилях нагрузки СУБД может вести себя не так, как мы ожидаем. Это и есть аномалии, на которых мы сосредоточимся в данной статье (для тех, кто предпочитает видео, эта информация доступна в виде записи доклада на HighLoad++).
Наша компания помогает обслуживать мультитерабайтные базы данных в крупных проектах, поэтому мой рассказ об аномалиях основан на реальном опыте промышленной эксплуатации СУБД в Postgres Professional — порой мы сталкиваемся с тем, что СУБД ведёт себя не так, как мы ожидали.
Также в рамках статьи мы рассмотрим следующее:
Эта статья о том, как аналитик изучает основы SQL, какие допускает ошибки и как старается их исправить. В статье будет то, что помогает погрузиться в SQL впервые: схемы и примеры кода, понятия и определения, проблемы и решения. Статья рассчитана на аналитиков-новичков.
Предыстория: аналитик создает отчёты в BI для директора компании «ABC». Аналитик не умеет программировать и подключается к данным по инструкции. Директор требует срочно добавить в отчёт данные из 3 источников: SAP – объем выручки от продаж; HRLink – затраты на персонал; Битрикс – время обработки заявок.
Аналитик ставит задачу data инженеру на добавление новых данных в BI. Data инженер – единственный специалист по работе с данными в офисе из 400 человек. Он критически оценивает сроки выполнения задачи и объявляет: «Минимум – 2 недели». Такой срок директора не устраивает. Инженер предлагает аналитику альтернативное решение...
Приветствую!
В прошлой статье была исследована входная точка бэкэнда до главного цикла. В этой статье закончим ее обзор исследованием главного цикла.
Кроме нее будут рассмотрены:
— Модуль для работы с транзакциями.
— Исключения в С и их реализацию.
— Клиент‑серверный протокол.
Свободная система управления базами данных PostgreSQL не только предоставляет высокопроизводительный движок для выполнения запросов, но и может быть расширена с помощью расширений, которые могут добавлять новые типы данных (например, для ГИС‑расширений или астрономических координат), дополнительные типы индекса и возможности поиска (например, полнотекстовый поиск), сбор статистики, поддержку новых языков для встроенных функций и многое другое. Большой список существующих расширений может быть найден по этой ссылке. В этой статье мы рассмотрим один из возможных вариантов по созданию собственного расширения для PostgreSQL с использованием библиотеки pgx.
Большие данные — вещь относительная. Посмотрите на любого блогера: он генерирует кучу данных, в его телефоне десятки, а то и сотни гигабайтов изображений и видео. Если он не может обработать их с помощью подручных средств, их вполне можно считать большими данными.
При этом оцифрованная Библиотека конгресса в США совсем маленькая, хранить ее у себя дома может любой. Телескопы, на которых работают в Америке, могут производить несколько десятков терабайт за одну ночь. А радиотелескоп, размер которого квадратный километр, будет производить петабайты.
Уже несколько лет назад я столкнулся с проблемой производительности 1С на PostgreSQL в некоторых запросах, которые на MS SQL выполнялись относительно быстро. Тогда же выяснилось, что в 99% случаев такие запросы можно оптимизировать так, что они начинают выполняться даже быстрее, чем на MS SQL, всего навсего добавлением нужных индексов во временные таблицы.
В большинстве учетных систем, типа нашего СБИС, рано или поздно возникает проблема быстрого отображения реестра, в который по просьбам бизнес‑пользователей накручено несколько комбинируемых фильтров с очень редкой выборкой, ну никак не ложащихся в вашу красивую структуру базы данных и индексов базовой таблицы реестра — что‑нибудь типа "список продаж покупателям, чей день рождения выпадает на 29 февраля".
Универсального способа сделать «хорошо» тут нет, но я расскажу про модель запроса, которая позволит вам дать пользователю быстрый отклик, но при этом весьма эффективно с точки зрения PostgreSQL.
В этом номере самое интересное за январь начало февраля 2023. В том числе, конечно, о релизах
Репликация PostgreSQL с опережающей записью (WAL) — ключевая концепция в высоконагруженных архитектурах, поскольку она позволяет создавать высокодоступные и отказоустойчивые системы баз данных.
Привет! Меня зовут Дима Вагин, я бэкенд-инженер в Авито. Сегодня расскажу, как мы работаем с БД PostgreSQL из Go. Покажу, какие библиотеки и пулеры соединений мы используем для доставки в код параметров подключения и как мы их настраиваем. А ещё расскажу про проблемы, к которым приводит отмена контекста, и о том, как мы с ними справляемся.
Первая часть шаблона посвящена HTTP серверу.
Вторая часть шаблона посвящена прототипированию REST API.
Третья часть посвящена развертыванию шаблона в Docker, Docker Compose, Kubernetes (kustomize).
Четвертая часть будет посвящена развертыванию в Kubernetes с Helm chart и настройке Horizontal Autoscaler.
Пятая часть посвящена оптимизации Worker pool и особенностям его работы в составе микросервиса, развернутого в Kubernetes.
Для корректного развертывания в Kubernetes, в шаблон пришлось внести изменения:
Ссылка на новый репозиторий.
Шаблон goapp в репозитории полностью готов к развертыванию в Docker, Docker Compose, Kubernetes (kustomize), Kubernetes (helm).
Настоящая статья не содержит детального описание используемых технологий
Сегодня открою вам Америку на основе данных OpenStreetMap в PostgreSQL15/PostGIS и моего проекта openstreetmap_h3. Запустим запрос и сравним время его выполнения на колоночном хранилище Citus в PostgreSQL и на стандартном в секционированной по H3 геоиндексу базе данных объемом 100GB.
Найдем top15 мест по застройке а Северной Америке и общую протяженность дорог, а также их тип и покрытие. Не буду перегружать публикацию логами программ, сфокусируемся на данных! Вы можете легко повторить все запросы самостоятельно на своем компьютере или ноутбуке.
Продолжаем разбираться в способах повышения производительности PostgreSQL. На этот раз обсуждаем настройку запросов, логирования, автоочистки и параметров клиентского подключения. А также рассказываем об особенностях конфигурации на основе анализа рабочей нагрузки.
Продолжим тему из публикации «Как поместить весь мир в обычный ноутбук: PostgreSQL и OpenStreetMap».
Сегодня визуализируем 15 мест где в России больше всего зданий. В этом нам поможет мой проект openstreetmap_h3 и PostgreSQL 15. На данный момент OpenStreetMap H3 единственное решение для импорта OSM данных партиционированных по H3 геоиндексу в PostgreSQL и Citus massive parallel processing. Сохраним данные в колоночное хранилище и посмотрим на план запроса для него.
В этой публикации мы будем агрегировать данные в большой таблице где нас интересуют для этих операций лишь два столбца и сможем извлечь пользу от этой модели данных на NVMe накопителе. Раньше я работал с колоночными базами данных AWS Redshift, Dremio, QuestDB и HeavyDB, но не смотря на их производительность, до функционала/протестированности и стабильности PostgreSQL им еще пока еще ох как далеко. Вот и отлично, попробуем получить все плюсы экосистемы PostgreSQL и колоночного хранилища citus. Вперед, к заветной цели на самых свежих версиях программ нашего аналитического стека!
ORM (Object‑Relational Mapping) используется во многих языках программирования, в том числе и в 1С. Однако реализация высоконагруженных решений, приводит к мысли что разработчики ORM не учитывали ее влияния на производительность СУБД. Такая ситуация и в 1С и ORM на Java, и наверняка в других ORM. В предыдущих частях показана глубина проблемы
Концепция ORM как двигатель прогресса — выдержит ли ее ваша СУБД? / Хабр (habr.com)
Концепция ORM как двигатель прогресса – выявит слабое место Вашей СУБД / Хабр (habr.com)
В этой части предложено решение со стороны СУБД (MS SQL , Oracle, Postgres)
