
Примитивный запрос - простой джойн и группировка. Традиционные методы оптимизации - казалось бы, что могло пойти не так?..
Небольшой эксперимент, на тему необходимости проверки любых гипотез в конкретных условиях.
Примитивный запрос - простой джойн и группировка. Традиционные методы оптимизации - казалось бы, что могло пойти не так?..
Небольшой эксперимент, на тему необходимости проверки любых гипотез в конкретных условиях.
Предположим, вам надо обработать на PostgreSQL большое (не, не так... БОЛЬШОЕ) количество записей, чтобы посчитать какие-нибудь агрегаты. В предыдущей статье были разобраны различные варианты, как это можно организовать, а в этой посмотрим, как при этом особо никого не заблокировать, включая "набегающий поток" данных.
Например, это может быть пересчет остатков и ведение сводных продаж по товарам при их постоянных отгрузках, или агрегация сальдо и оборотов по бухгалтерским счетам, при массовых изменениях проводок, или что-то еще... В любой управленческой системе подобных задач наберется горка, и СБИС тоже не является исключением.
Но у всех этих ситуаций есть общий момент - количество изменений сильно больше количества целевых агрегатов. Например: тысячи товаров, по каждому десятки тысяч отгрузок в день.
С течением жизни приложения в его БД накапливается все больше данных. Десктопное оно, SaaS или даже мобильное - неважно, в современном мире почти каждый что-то хранит "у себя".
Если это какая-то локальная утилита - не страшно, само ее существование у пользователя достаточно ограничено. Но если это что-то вроде нашего СБИС, который накапливает и помогает анализировать операции за все время существования бизнеса, то, по мере его роста, не только операций становится больше, но и понимания, какие именно сводные отчеты помогают в оперативном управлении.
Вот про то, как сделать такие отчеты быстрыми, какие бывают способы их реализации и встречаются "грабли" на этом пути, сегодня и поговорим.
Одним из наиболее частых требований-"хотелок" бизнеса является построение всяких разных рейтингов - "самые оборотистые клиенты", "самые продаваемые позиции", "самые активные сотрудники", … - любимая тема разных дашбордов.
Традиционно, есть два подхода к этой задаче: запрос по требованию по "сырым" данным или предварительная агрегация. И если "просто посчитать" такой отчет по первичке - упражнение для SQL-новичка, но очень "тяжелое" для производительности СУБД, то вариант сделать так, чтобы он строился практически мгновенно при большом количестве активных аккаунтов независимых бизнесов, как у нас в СБИС, без необходимости пересчитывать агрегированную статистику каждый день судорожно по всем клиентам - интересная задача.
С транскриптом первой части, посвященной типовым проблемам производительности запросов и их решениям, можно ознакомиться в статье «Рецепты для хворающих SQL-запросов».
В этой челлендж-серии статей попробуем использовать PostgreSQL как среду для решения задач Advent of Code 2024.
Возможно, SQL не самый подходящий для этого язык, зато мы рассмотрим его различные возможности, о которых вы могли и не подозревать.
Используем динамическое программирование для подсчета количества вариантов размещений.
В Node.js IPC (Inter-Process Communication) - это механизм, используемый для обмена данными между процессами. Начиная с версии 12.16.0 в модуле child_processes появилась поддержка режима advanced serialization для IPC. Однако иногда он может привести к проблемам с зависанием сообщений, что приводит к ошибкам и проблемам с функциональностью. В этой статье мы расскажем как решили эту проблему.
В этой челлендж-серии статей попробуем использовать PostgreSQL как среду для решения задач Advent of Code 2024.
Возможно, SQL не самый подходящий для этого язык, зато мы рассмотрим его различные возможности, о которых вы могли и не подозревать.
В этой части воспользуемся обширными возможностями поиска в массивах и реализуем рекурсивную сортировку «пузырьком».
Привет, Хабр!
Поговорим о проблеме выбора DAST, который бы смог удовлетворить потребности регулярного поиска уязвимостей в web-инфраструктуре компании. Опытные пентестеры, специализирующиеся на web-приложениях, наверняка возразят: какой тут может быть выбор? Burp Suite PRO наше все! И будут правы, но на прошлом PHD мне в руки попала Позитивная карта импортозамещения (https://www.ptsecurity.com/upload/corporate/ru-ru/analytics/positive-research-2023-poster.pdf), где Positive Technologies предложили заместить иностранные DAST: Burp Suite Pro, Acunetix, Inviciti — своим решением PT BlackBox. Но чтобы коммерческим продуктам не быть едиными, заодно добавим в сравнение продукты open source.
Разберемся, импортозамещаться или приобретать через серые схемы иностранный Burp Suite Pro. Или вообще оставаться на бесплатном open source.
В нашем блоге так много статей о технологиях, научных решениях, новых приложениях и так мало про тех, кто стоит за всеми этими строчками кода, про обычных людей. Хотим рассказать о тех, кто ежедневно делает наш продукт лучше.
В нашем сервисе мониторинга и анализа PostgreSQL доступ к серверам осуществляется по протоколу SSH. В качестве ssh-клиента мы используем популярный модуль SSH2 , однако при передаче данных большого объема этот модуль вносит существенные задержки в event loop. Как их можно снизить - расскажем в этой статье.
На примере простой задачи клонирования ключей объекта посмотрим, есть ли реальные альтернативы по производительности столь презираемой JavaScript-разработчиками функции eval()
.
Подобная задача возникает, если оригинальное значение ключа надо оставить у объекта, а как-то обработанное - положить рядом в новый соответствующий ключ. То есть, для начала, из {"a" : 1, "b" : 2}
надо получить {"a" : 1, "a-copy" : 1, "b" : 2, "b-copy" : 2}
.
Пару лет назад я уже рассказывал, почему максимальная производительность подобных операций на JavaScript важна для нашего сервиса потокового анализа логов PostgreSQL, как можно поускорять парсинг с помощью WebAssembly, и вот сегодня - продолжение.
Мы заканчиваем мини-серию статей о работе с агрегатами в PostgreSQL:
- эффективная обработка потока «фактов»
И сегодня поговорим о том, как можно снизить суммарные задержки на вставку множества изменений в таблицы агрегатов за счет использования промежуточных таблиц и внешней обработки.
Анализ планов и форматирование запросов PostgreSQL удобно выполнять в VS Code, используя explain.tensor.ru и плагин, о котором пойдет речь ниже.
Периодически сталкиваюсь с однотипными задачами вида "показать TOP-N позиций на каждом из вложенных интервалов некоторого периода".
Это может быть "5 лучших по успеваемости студентов в каждом семестре за последний учебный год", или "помесячная динамика позиции 10 наиболее продающихся товаров", или, как у нас в сервисе визуализации PostgreSQL-планов explain.tensor.ru, "3 наиболее активных страны за каждый день":
В Тензоре около 7 тысяч сотрудников и более 100 филиалов по всей стране - такой компании категорически необходима видеокоммуникация. Существует 2 соизмеримых по издержкам решения: использовать существующий продукт или реализовать свой.
В этой статье я, разработчик отдела вебинаров, расскажу, каким образом наша компания, выбрав когда-то второй путь, пришла к собственному сервису вебинаров. Пройдя несколько итераций развития, на сегодняшний день мы научились проводить видеоконференции буквально на всех наших сотрудников.