Поднимите руки те, у кого есть номер телефона... Вау, лес рук! Но знаете ли вы, что скрывается за этим набором цифр?
Тензор
Разработчик системы Saby
SQL HowTo: крупицы золота в реестре
Сложный
7 мин
Туториал
В большинстве учетных систем, типа нашего СБИС, рано или поздно возникает проблема быстрого отображения реестра, в который по просьбам бизнес‑пользователей накручено несколько комбинируемых фильтров с очень редкой выборкой, ну никак не ложащихся в вашу красивую структуру базы данных и индексов базовой таблицы реестра — что‑нибудь типа "список продаж покупателям, чей день рождения выпадает на 29 февраля".
Универсального способа сделать «хорошо» тут нет, но я расскажу про модель запроса, которая позволит вам дать пользователю быстрый отклик, но при этом весьма эффективно с точки зрения PostgreSQL.
One Tool to Analyze Them All
1 мин
Мы рады сообщить о реализации на explain.tensor.ru базовой поддержки анализа и визуализации планов, специфичных для PostgreSQL-совместимых решений: Timescale, Citus, Greenplum и Redshift.
Так что если в будущем вам встретится план, похожий на результат обычного
В развитие темы сопоставления узлов плана и запроса добавлена возможность быстрого просмотра и переключения между ними:
Так что если в будущем вам встретится план, похожий на результат обычного
EXPLAIN, но с некоторыми странными узлами — вы знаете, куда идти.EXPLAIN <-> SQL
В развитие темы сопоставления узлов плана и запроса добавлена возможность быстрого просмотра и переключения между ними:
PostgreSQL Antipatterns: «Бесконечность — не предел!», или Немного о рекурсии
4 мин
Рекурсия — очень мощный и удобный механизм, если над связанными данными делаются одни и те же действия «вглубь». Но неконтролируемая рекурсия — зло, которое может приводить или к бесконечному выполнению процесса, или (что случается чаще) к «выжиранию» всей доступной памяти.
СУБД в этом отношении работают по тем же принципам — "сказали копать, я и копаю". Ваш запрос может не только затормозить соседние процессы, постоянно занимая ресурсы процессора, но и «уронить» всю базу целиком, «съев» всю доступную память. Поэтому защита от бесконечной рекурсии — обязанность самого разработчика.
В PostgreSQL возможность использовать рекурсивные запросы через
СУБД в этом отношении работают по тем же принципам — "сказали копать, я и копаю". Ваш запрос может не только затормозить соседние процессы, постоянно занимая ресурсы процессора, но и «уронить» всю базу целиком, «съев» всю доступную память. Поэтому защита от бесконечной рекурсии — обязанность самого разработчика.
В PostgreSQL возможность использовать рекурсивные запросы через
WITH RECURSIVE появилась еще в незапамятные времена версии 8.4, но до сих пор можно регулярно встретить потенциально-уязвимые «беззащитные» запросы. Как избавить себя от проблем подобного рода?SQL HowTo: курсорный пейджинг с неподходящей сортировкой
3 мин
Этот пост родился как расширенный ответ на умозрительную задачу, обозначенную в статье «Хроники пэйджинга».
Пусть у нас есть реестр документов, с которым работают операторы или бухгалтеры в СБИС, вроде такого:
Традиционно, при подобном отображении используется или прямая (новые снизу) или обратная (новые сверху) сортировка по дате и порядковому идентификатору, назначаемому при создании документа —
Типичные возникающие при этом проблемы я уже рассматривал в статье «PostgreSQL Antipatterns: навигация по реестру». Но что если пользователю зачем-то захотелось «нетипичного» — например, отсортировать одно поле «так», а другое «этак» —
Можно ли решить эту задачу, эффективно используя только индекс
Пусть у нас есть реестр документов, с которым работают операторы или бухгалтеры в СБИС, вроде такого:
Традиционно, при подобном отображении используется или прямая (новые снизу) или обратная (новые сверху) сортировка по дате и порядковому идентификатору, назначаемому при создании документа —
ORDER BY dt, id или ORDER BY dt DESC, id DESC.Типичные возникающие при этом проблемы я уже рассматривал в статье «PostgreSQL Antipatterns: навигация по реестру». Но что если пользователю зачем-то захотелось «нетипичного» — например, отсортировать одно поле «так», а другое «этак» —
ORDER BY dt, id DESC? Но второй индекс мы создавать не хотим — ведь это замедление вставки и лишний объем в базе.Можно ли решить эту задачу, эффективно используя только индекс
(dt, id)?DBA: в погоне за пролетающими блокировками
10 мин
В прошлой статье, где я рассказывал о мониторинге БД PostgreSQL, была такая фраза:
Шансов поймать блокировки «в моменте» крайне мало, да и длиться они могут всего по несколько секунд, но ухудшая при этом плановое время выполнения запроса в десятки раз. А хочется-то не сидеть и ловить происходящее в онлайн-режиме, а в спокойной обстановке разобраться постфактум,кого из разработчиков покарать в чем именно была проблема — кто, с кем и из-за какого ресурса базы вступил в конфликт.
Но как? Ведь, в отличие от запроса с его планом, который позволяет детально понять, на что пошли ресурсы, и сколько времени это заняло, подобных наглядных следов блокировка не оставляет после себя…
Разве что короткую запись в логе:
Растут wait — приложение в кого-то «уперлось» на блокировках. Если это уже прошедшая разовая аномалия — повод разобраться в исходной причине.Такая ситуация — одна из самых неприятных для DBA:- на первый взгляд, база работает
- никакие ресурсы сервера не исчерпаны
- … но часть запросов при этом «подтормаживает»
Шансов поймать блокировки «в моменте» крайне мало, да и длиться они могут всего по несколько секунд, но ухудшая при этом плановое время выполнения запроса в десятки раз. А хочется-то не сидеть и ловить происходящее в онлайн-режиме, а в спокойной обстановке разобраться постфактум,
Но как? Ведь, в отличие от запроса с его планом, который позволяет детально понять, на что пошли ресурсы, и сколько времени это заняло, подобных наглядных следов блокировка не оставляет после себя…
Разве что короткую запись в логе:
process ... still waiting for ...
PostgreSQL Antipatterns: редкая запись долетит до середины JOIN
3 мин
Если писать SQL-запросы без анализа алгоритма, который они должны реализовать, ни к чему хорошему с точки зрения производительности это обычно не приводит.
Такие запросы любят «кушать» процессорное время и активно почитывать данные практически на ровном месте. Причем, это вовсе не обязательно какие-то сложные запросы, наоборот — чем проще он написан, тем больше шансов получить проблемы. А уж если в дело вступает оператор JOIN…
Само по себе соединение таблиц не вредно и не полезно — это просто инструмент, но и пользоваться им надо уметь.
Такие запросы любят «кушать» процессорное время и активно почитывать данные практически на ровном месте. Причем, это вовсе не обязательно какие-то сложные запросы, наоборот — чем проще он написан, тем больше шансов получить проблемы. А уж если в дело вступает оператор JOIN…
Само по себе соединение таблиц не вредно и не полезно — это просто инструмент, но и пользоваться им надо уметь.
SQL HowTo: находим «елочку» с помощью центра масс (Advent of Code 2024, Day 14: Restroom Redoubt)
Простой
7 мин
Кейс
В этой челлендж-серии статей попробуем использовать PostgreSQL как среду для решения задач Advent of Code 2024.
Возможно, SQL не самый подходящий для этого язык, зато мы рассмотрим его различные возможности, о которых вы могли и не подозревать.
В этой части мы научимся вычислять состояния клеточного автомата без прямого моделирования и узнаем, как можно среди них найти интересное.
Игры с джунами
Простой
4 мин
Туториал
Привет, Хабр! Меня зовут Ирина Москалева. Работаю в компании около 12 лет, в области HR. Когда-то подбирала персонал сама, но уже несколько лет руковожу своей командой и разрабатываю стратегию в этой сфере подбора и управления персоналом.
Хочу разбавить технические темы насущными и, по моему мнению, касающимися многих компаний, вопросами. Так вот, много лет мы активно набирали перспективных джунов. Откуда мы их брали? Помогали наши различные авторские школы, мероприятия по профориентации в области ИТ, практика и другие эвенты.
Как подготовиться к публичному выступлению: работа с голосом
Простой
3 мин
Туториал
Чем больше ты становишься экспертом, тем чаще HR видят в тебе не просто коллегу… а спикера на конференциях и митапах. Ну потому что нельзя скрывать такое сокровище!
Одно дело — подготовить доклад, другое — с ним выступить (тяжкий вздох). Словить атаческую панику за 5 минут до триумфального появления перед публикой может даже самый титулованный специалист. И это ок.
Чтобы не переживать и с удовольствием делиться опытом с аудиторией, нужно просто настроиться на выступление: привести в порядок голос и нервы.
Накануне Митапа в Уфе 28 марта собрали в статье лайфхаки, которые помогут чувствовать себя перед аудиторией комфортнее, а звучать — увереннее.
Обзор по LLM
10 мин
Обзор
В прошлом году(2023) в мире больших языковых моделей(LLM) произошло много нового и нитересного. В новостях появились фразы о гонке искусственных интеллектов, а многие ведущие IT компании включились в эту гонку. Рассмотрим как все начиналось, кто сейчас занимает лидирующие позиции в гонке и когда роботы захватят мир.
Плагин для анализа планов PostgreSQL в IDE JetBrains и его разработка
Средний
11 мин
Туториал
Для пользователей explain.tensor.ru - нашего сервиса визуализации PostgreSQL-планов, мы создали плагин "Explain PostgreSQL" для всех IDE от JetBrains, теперь есть возможность форматировать запросы и анализировать планы непосредственно в IDE.
Как использовать плагин и детали о его разработке читайте ниже.
Битва «Титанов». Сравнение двух лучших отечественных сканеров уязвимостей. MaxPatrol 8 и RedCheck Enterprise
13 мин
В последние месяцы в киберпространстве развернулась настоящая война, отчего незащищенные информационные активы значительно пострадали, а пользователи защитного инструментария от западных «партнеров» столкнулись с серьезнейшими санкциями, ограничивающими использование их ПО. Поэтому мы решили посмотреть на рынок отечественного ПО, разработанного для усиления «инфобеза».
Обычно на вопрос "Какой сканер безопасности купить?" вспоминаются лишь OpenVas и Nessus (Tenable). Но есть и другие достойные отечественные продукты, о которых мы сегодня и поговорим – это продукты для корпоративного сегмента, полностью лицензированные под все российские требования безопасности и имеющие сертификаты ФСТЭК и ФСБ:
PostgreSQL Antipatterns: рекурсивные грабли на ровном месте, или Сказка о потерянном времени
2 мин
В моей практике ускорения SQL-запросов для PostgreSQL, в большинстве случаев, все сводится к применению типовых методик - их не особенно-то и много, и прочитать про большинство из них можно в моем профиле.
Но иногда обнаруживаются очень странные вещи в поведении этой, безусловно, отличной СУБД.
Все началось с запроса, который мне показали с диагнозом "необъяснимо тормозит"...
Ближайшие события
DBA: прибираем «мертвые души»
4 мин
Иногда при выполнении длительных или плохо написанных запросов в PostgreSQL происходят разные неприятные вещи типа внезапного сбоя процесса или краша всего сервера.
В таких случаях на носителе могут остаться "мертвые души" - файлы (иногда совсем немаленькие, а вполне сравнимые по объему со всей остальной базой), которые были созданы во время работы процесса в качестве временного хранилища промежуточных данных.
Эти данные уже никому не нужны, никем не могут быть использованы, но сервер не торопится избавиться от них как Плюшкин.
PostgreSQL Antipatterns: DBA-детектив, или Три дела о потерянной производительности
30 мин
Сегодня вместо решения абстрактных алгоритмических задач мы выступим в роли детектива, по крупицам доставшейся информации исследующего неэффективные запросы, и рассмотрим три реальных дела, встречавшихся в разное время на просторах нашего приложения СБИС, когда простота и наивность при написании SQL превращалась в дополнительную нагрузку для PostgreSQL-сервера.
Дедукция и индукция помогут нам вычислить, что же все-таки хотел получить от СУБД разработчик, и почему это получилось не слишком оптимально. Итак, сегодня нас ждут:
Дедукция и индукция помогут нам вычислить, что же все-таки хотел получить от СУБД разработчик, и почему это получилось не слишком оптимально. Итак, сегодня нас ждут:
- Дело о непростом пути вверх
Разберем в live-видео на реальном примере некоторые из способов улучшения производительности иерархического запроса. - Дело о худеющем запросе
Увидим, как можно запрос упростить и ускорить в несколько раз, пошагово применяя стандартные методики. - Дело о развесистой клюкве
Восстановим структуру БД на основании единственного запроса с 11JOINи предложим альтернативный вариант решения на ней той же задачи.
Правильно [c]читаем параллельные планы PostgreSQL
4 мин
Исторически, модель работы сервера PostgreSQL выглядит как множество независимых процессов с частично разделяемой памятью. Каждый из них обслуживает только одно клиентское подключение и один запрос в любой момент времени — и никакой многопоточности.
Поэтому внутри каждого отдельного процесса нет никаких традиционных «странных» проблем с параллельным выполнением кода, блокировками, race condition,… А разработка самой СУБД приятна и проста.
Но эта же простота накладывает существенное ограничение. Раз внутри процесса всего один рабочий поток, то и использовать он может не более одного ядра CPU для выполнения запроса — а, значит, скорость работы сервера впрямую зависит от частоты и архитектуры отдельного ядра.
В наш век закончившейся «гонки мегагерцев» и победивших многоядерных и многопроцессорных систем такое поведение является непозволительной роскошью и расточительностью. Поэтому, начиная с версии PostgreSQL 9.6, при отработке запроса часть операций может выполняться несколькими процессами одновременно.
Поэтому внутри каждого отдельного процесса нет никаких традиционных «странных» проблем с параллельным выполнением кода, блокировками, race condition,… А разработка самой СУБД приятна и проста.
Но эта же простота накладывает существенное ограничение. Раз внутри процесса всего один рабочий поток, то и использовать он может не более одного ядра CPU для выполнения запроса — а, значит, скорость работы сервера впрямую зависит от частоты и архитектуры отдельного ядра.
В наш век закончившейся «гонки мегагерцев» и победивших многоядерных и многопроцессорных систем такое поведение является непозволительной роскошью и расточительностью. Поэтому, начиная с версии PostgreSQL 9.6, при отработке запроса часть операций может выполняться несколькими процессами одновременно.
Со схемами работы некоторых параллельных узлов можно ознакомиться в статье «Parallelism in PostgreSQL» by Ibrar Ahmed, откуда взято и это изображение.Правда, читать планы в этом случае становится… нетривиально.
PostgreSQL Antipatterns: сказ об итеративной доработке поиска по названию, или «Оптимизация туда и обратно»
7 мин
Тысячи менеджеров из офисов продаж по всей стране фиксируют в нашей CRM-системе ежедневно десятки тысяч контактов — фактов общения с потенциальными или уже работающими с нами клиентами. А для этого клиента надо сначала найти, и желательно очень быстро. И происходит это чаще всего по названию.
Поэтому неудивительно, что, разбирая в очередной раз «тяжелые» запросы на одной из самых нагруженных баз — нашего собственного корпоративного аккаунта СБИС, я обнаружил «в топе» запрос для «быстрого» поиска по названию для карточек организаций.
Причем дальнейшее расследование выявило интересный пример сначала оптимизации, а затем деградации производительности запроса при последовательной его доработке силами нескольких команд, каждая из которых действовала исключительно из лучших побуждений.
[КДПВ отсюда]
Что вообще обычно подразумевает пользователь, когда говорит про «быстрый» поиск по названию? Почти никогда это не оказывается «честный» поиск по подстроке типа
Пользователь же подразумевает на бытовом уровне, что вы ему обеспечите поиск по началу слова в названии и покажете более релевантным то, что начинается на введенное. И сделаете это практически мгновенно — при подстрочном вводе.
Поэтому неудивительно, что, разбирая в очередной раз «тяжелые» запросы на одной из самых нагруженных баз — нашего собственного корпоративного аккаунта СБИС, я обнаружил «в топе» запрос для «быстрого» поиска по названию для карточек организаций.
Причем дальнейшее расследование выявило интересный пример сначала оптимизации, а затем деградации производительности запроса при последовательной его доработке силами нескольких команд, каждая из которых действовала исключительно из лучших побуждений.
0: чего же хотел пользователь
Что вообще обычно подразумевает пользователь, когда говорит про «быстрый» поиск по названию? Почти никогда это не оказывается «честный» поиск по подстроке типа
... LIKE '%роза%' — ведь тогда в результат попадают не только 'Розалия' и 'Магазин Роза', но и 'Гроза' и даже 'Дом Деда Мороза'.Пользователь же подразумевает на бытовом уровне, что вы ему обеспечите поиск по началу слова в названии и покажете более релевантным то, что начинается на введенное. И сделаете это практически мгновенно — при подстрочном вводе.
Опыт построения логов на Postgres
10 мин
Мы разработали свою систему логирования на PostgreSQL… Да я знаю, что есть надстройки над ElasticSearch (GrayLog2, Logstash), и что есть другие похожие инструменты, и есть те, про которые не знаю. Тем не менее, наш инструмент на текущий момент построен на PostgreSQL, и он работает.
Во время рабочей недели со всех сервисов СБИС в облаке к нам поступает в сутки более 11 млрд записей, хранятся они 3 дня, общий объем занимаемого при этом места не превышает 32 Тб. Все это обрабатывает 8 серверов с PostgreSQL 9.6. Каждый сервер имеет 24 ядра, RAM 16Гб и 4 SSD диска по 1Тб.
Во время рабочей недели со всех сервисов СБИС в облаке к нам поступает в сутки более 11 млрд записей, хранятся они 3 дня, общий объем занимаемого при этом места не превышает 32 Тб. Все это обрабатывает 8 серверов с PostgreSQL 9.6. Каждый сервер имеет 24 ядра, RAM 16Гб и 4 SSD диска по 1Тб.
Трансляция видео посредством P2P-сетей
Средний
10 мин
Создавая сервис видеотрансляций, рано или поздно, при увеличении числа потребителей контента, возникает вопрос о масштабировании и доставке. Вы столкнетесь с проблемой не только вычислительных мощностей, но и пропускной способности вашей сети.
Я, как разработчик сервиса вебинаров, постараюсь в этой статье помочь разобраться с этими проблемами, по средствам P2P-сетей.