#оптимизация_запросов — Public Fediverse posts

Ускорение запросов в PostgreSQL: три рычага оптимизации и практический разбор

В предыдущих частях серии мы разобрали, как читать планы выполнения через EXPLAIN ANALYZE , и научились автоматически ловить медленные запросы с помощью pg_stat_statements, auto_explain и log_min_duration_statement. Теперь — следующий шаг: что делать с проблемами, которые вы нашли. В этой части разбираем три рычага оптимизации: статистику планировщика, индексы и рефакторинг SQL-запросов. На демонстрационном примере покажем, как снизить стоимость запроса почти вдвое — без изменений в инфраструктуре. Оборудование, конфигурация сервера и схема БД тоже влияют на производительность, но остаются за рамками статьи — здесь сосредоточимся на том, что можно улучшить на уровне запросов.

https://habr.com/ru/companies/first/articles/1035448/

#оптимизация #базы_данных #postgresql #оптимизация_запросов #план_запроса

Ускорение запросов в PostgreSQL: три рычага оптимизации и практический разбор

В предыдущих частях серии мы разобрали, как читать планы выполнения через EXPLAIN ANALYZE , и научились автоматически ловить медленные запросы с помощью pg_stat_statements, auto_explain и log_min_duration_statement. Теперь — следующий шаг: что делать с проблемами, которые вы нашли. В этой части разбираем три рычага оптимизации: статистику планировщика, индексы и рефакторинг SQL-запросов. На демонстрационном примере покажем, как снизить стоимость запроса почти вдвое — без изменений в инфраструктуре. Оборудование, конфигурация сервера и схема БД тоже влияют на производительность, но остаются за рамками статьи — здесь сосредоточимся на том, что можно улучшить на уровне запросов.

https://habr.com/ru/companies/first/articles/1035448/

#оптимизация #базы_данных #postgresql #оптимизация_запросов #план_запроса

Ускорение запросов в PostgreSQL: три рычага оптимизации и практический разбор

В предыдущих частях серии мы разобрали, как читать планы выполнения через EXPLAIN ANALYZE , и научились автоматически ловить медленные запросы с помощью pg_stat_statements, auto_explain и log_min_duration_statement. Теперь — следующий шаг: что делать с проблемами, которые вы нашли. В этой части разбираем три рычага оптимизации: статистику планировщика, индексы и рефакторинг SQL-запросов. На демонстрационном примере покажем, как снизить стоимость запроса почти вдвое — без изменений в инфраструктуре. Оборудование, конфигурация сервера и схема БД тоже влияют на производительность, но остаются за рамками статьи — здесь сосредоточимся на том, что можно улучшить на уровне запросов.

https://habr.com/ru/companies/first/articles/1035448/

#оптимизация #базы_данных #postgresql #оптимизация_запросов #план_запроса

Ускорение запросов в PostgreSQL: три рычага оптимизации и практический разбор

В предыдущих частях серии мы разобрали, как читать планы выполнения через EXPLAIN ANALYZE , и научились автоматически ловить медленные запросы с помощью pg_stat_statements, auto_explain и log_min_duration_statement. Теперь — следующий шаг: что делать с проблемами, которые вы нашли. В этой части разбираем три рычага оптимизации: статистику планировщика, индексы и рефакторинг SQL-запросов. На демонстрационном примере покажем, как снизить стоимость запроса почти вдвое — без изменений в инфраструктуре. Оборудование, конфигурация сервера и схема БД тоже влияют на производительность, но остаются за рамками статьи — здесь сосредоточимся на том, что можно улучшить на уровне запросов.

https://habr.com/ru/companies/first/articles/1035448/

#оптимизация #базы_данных #postgresql #оптимизация_запросов #план_запроса

Как найти медленный запрос в PostgreSQL: три инструмента мониторинга

EXPLAIN ANALYZE отлично справляется с диагностикой конкретного запроса — но только если вы уже знаете, какой именно запрос виновен. На практике проблемный запрос нужно сначала найти среди тысяч других. Ждать жалоб пользователей или вручную мониторить дашборды — путь, который не масштабируется. В этой статье разберём три инструмента PostgreSQL для автоматического поиска медленных запросов: pg_stat_statements, auto_explain и log_min_duration_statement. Для каждого — настройка, ключевые параметры и когда что использовать.

https://habr.com/ru/companies/first/articles/1034434/

#оптимизация #базы_данных #postgresql #оптимизация_запросов #план_запроса

Как найти медленный запрос в PostgreSQL: три инструмента мониторинга

EXPLAIN ANALYZE отлично справляется с диагностикой конкретного запроса — но только если вы уже знаете, какой именно запрос виновен. На практике проблемный запрос нужно сначала найти среди тысяч других. Ждать жалоб пользователей или вручную мониторить дашборды — путь, который не масштабируется. В этой статье разберём три инструмента PostgreSQL для автоматического поиска медленных запросов: pg_stat_statements, auto_explain и log_min_duration_statement. Для каждого — настройка, ключевые параметры и когда что использовать.

https://habr.com/ru/companies/first/articles/1034434/

#оптимизация #базы_данных #postgresql #оптимизация_запросов #план_запроса

Как найти медленный запрос в PostgreSQL: три инструмента мониторинга

EXPLAIN ANALYZE отлично справляется с диагностикой конкретного запроса — но только если вы уже знаете, какой именно запрос виновен. На практике проблемный запрос нужно сначала найти среди тысяч других. Ждать жалоб пользователей или вручную мониторить дашборды — путь, который не масштабируется. В этой статье разберём три инструмента PostgreSQL для автоматического поиска медленных запросов: pg_stat_statements, auto_explain и log_min_duration_statement. Для каждого — настройка, ключевые параметры и когда что использовать.

https://habr.com/ru/companies/first/articles/1034434/

#оптимизация #базы_данных #postgresql #оптимизация_запросов #план_запроса

Как найти медленный запрос в PostgreSQL: три инструмента мониторинга

EXPLAIN ANALYZE отлично справляется с диагностикой конкретного запроса — но только если вы уже знаете, какой именно запрос виновен. На практике проблемный запрос нужно сначала найти среди тысяч других. Ждать жалоб пользователей или вручную мониторить дашборды — путь, который не масштабируется. В этой статье разберём три инструмента PostgreSQL для автоматического поиска медленных запросов: pg_stat_statements, auto_explain и log_min_duration_statement. Для каждого — настройка, ключевые параметры и когда что использовать.

https://habr.com/ru/companies/first/articles/1034434/

#оптимизация #базы_данных #postgresql #оптимизация_запросов #план_запроса

Почему CRM в Битрикс24 тормозит на 50К сделок и что с этим делать

Когда CRM в Битрикс24 начинает открывать список сделок по 10 секунд, обычно первым делом подозревают сервер, нагрузку или саму платформу. Но на практике узкое место часто лежит ближе к базе: фильтры по UF -полям без индексов, лишние JOIN , неявный LIKE в ORM , N+1 -запросы и обработчики, которые внезапно превращают массовое обновление в нагрузочный тест. В статье разбираем, как подойти к проблеме системно: включить slow query log , прочитать EXPLAIN , найти реальные причины тормозов и точечно ускорить CRM без миграции и бессмысленного наращивания железа.

https://habr.com/ru/companies/otus/articles/1029706/

#Битрикс24 #CRM #производительность_CRM #MySQL #slow_query_log #EXPLAIN #индексы #пользовательские_поля #D7_ORM #оптимизация_запросов

Почему CRM в Битрикс24 тормозит на 50К сделок и что с этим делать

Когда CRM в Битрикс24 начинает открывать список сделок по 10 секунд, обычно первым делом подозревают сервер, нагрузку или саму платформу. Но на практике узкое место часто лежит ближе к базе: фильтры по UF -полям без индексов, лишние JOIN , неявный LIKE в ORM , N+1 -запросы и обработчики, которые внезапно превращают массовое обновление в нагрузочный тест. В статье разбираем, как подойти к проблеме системно: включить slow query log , прочитать EXPLAIN , найти реальные причины тормозов и точечно ускорить CRM без миграции и бессмысленного наращивания железа.

https://habr.com/ru/companies/otus/articles/1029706/

#Битрикс24 #CRM #производительность_CRM #MySQL #slow_query_log #EXPLAIN #индексы #пользовательские_поля #D7_ORM #оптимизация_запросов

Почему CRM в Битрикс24 тормозит на 50К сделок и что с этим делать

Когда CRM в Битрикс24 начинает открывать список сделок по 10 секунд, обычно первым делом подозревают сервер, нагрузку или саму платформу. Но на практике узкое место часто лежит ближе к базе: фильтры по UF -полям без индексов, лишние JOIN , неявный LIKE в ORM , N+1 -запросы и обработчики, которые внезапно превращают массовое обновление в нагрузочный тест. В статье разбираем, как подойти к проблеме системно: включить slow query log , прочитать EXPLAIN , найти реальные причины тормозов и точечно ускорить CRM без миграции и бессмысленного наращивания железа.

https://habr.com/ru/companies/otus/articles/1029706/

#Битрикс24 #CRM #производительность_CRM #MySQL #slow_query_log #EXPLAIN #индексы #пользовательские_поля #D7_ORM #оптимизация_запросов

Почему CRM в Битрикс24 тормозит на 50К сделок и что с этим делать

Когда CRM в Битрикс24 начинает открывать список сделок по 10 секунд, обычно первым делом подозревают сервер, нагрузку или саму платформу. Но на практике узкое место часто лежит ближе к базе: фильтры по UF -полям без индексов, лишние JOIN , неявный LIKE в ORM , N+1 -запросы и обработчики, которые внезапно превращают массовое обновление в нагрузочный тест. В статье разбираем, как подойти к проблеме системно: включить slow query log , прочитать EXPLAIN , найти реальные причины тормозов и точечно ускорить CRM без миграции и бессмысленного наращивания железа.

https://habr.com/ru/companies/otus/articles/1029706/

#Битрикс24 #CRM #производительность_CRM #MySQL #slow_query_log #EXPLAIN #индексы #пользовательские_поля #D7_ORM #оптимизация_запросов

[Перевод] Как читать BUFFERS в EXPLAIN ANALYZE и находить I/O-узкие места в PostgreSQL

EXPLAIN ANALYZE часто воспринимается как инструмент, который показывает план выполнения запроса. Но если посмотреть внимательнее на блок BUFFERS, он начинает отвечать на более прикладной вопрос — где именно запрос упёрся в I/O и почему это произошло. В этой статье разберём, как читать эту статистику на уровне отдельных узлов плана, как интерпретировать hit/read в контексте нагрузки и почему сами числа почти ничего не значат без сравнения во времени.

https://habr.com/ru/companies/otus/articles/1024674/

#EXPLAIN_ANALYZE #postgres #sql #buffers #оптимизация_запросов #производительность_базы_данных #work_mem #shared_buffers

Гибридный кэш на базе Redis в серверной разработке

В серверной разработке кэш влияет не только на скорость ответа. От него напрямую зависят стоимость обработки запроса, нагрузка на базу, поведение системы под пиком и предсказуемость масштабирования. Именно поэтому практика кэширования имеет сегодня столько нюансов и разновидностей, если вы хотите реализовать что-то особенное или применить сложную схему кэширования, от ваших специалистов потребуются специальные навыки и умения. Под катом — рассказ о том, как мы ушли от кастомного кода к использованию гибридного кэша из .Net Framework, с какими сложностями столкнулись на этапе масштабирования системы, и как решали вопросы инвалидации кэша в процессе развития нашего проекта API Hub .

https://habr.com/ru/companies/cloud_x/articles/1024574/

#cloud_x_group #redis #кэш #cache #гибридный_кэш #кейс #оптимизация_запросов

Гибридный кэш на базе Redis в серверной разработке

В серверной разработке кэш влияет не только на скорость ответа. От него напрямую зависят стоимость обработки запроса, нагрузка на базу, поведение системы под пиком и предсказуемость масштабирования. Именно поэтому практика кэширования имеет сегодня столько нюансов и разновидностей, если вы хотите реализовать что-то особенное или применить сложную схему кэширования, от ваших специалистов потребуются специальные навыки и умения. Под катом — рассказ о том, как мы ушли от кастомного кода к использованию гибридного кэша из .Net Framework, с какими сложностями столкнулись на этапе масштабирования системы, и как решали вопросы инвалидации кэша в процессе развития нашего проекта API Hub .

https://habr.com/ru/companies/cloud_x/articles/1024574/

#cloud_x_group #redis #кэш #cache #гибридный_кэш #кейс #оптимизация_запросов

Гибридный кэш на базе Redis в серверной разработке

В серверной разработке кэш влияет не только на скорость ответа. От него напрямую зависят стоимость обработки запроса, нагрузка на базу, поведение системы под пиком и предсказуемость масштабирования. Именно поэтому практика кэширования имеет сегодня столько нюансов и разновидностей, если вы хотите реализовать что-то особенное или применить сложную схему кэширования, от ваших специалистов потребуются специальные навыки и умения. Под катом — рассказ о том, как мы ушли от кастомного кода к использованию гибридного кэша из .Net Framework, с какими сложностями столкнулись на этапе масштабирования системы, и как решали вопросы инвалидации кэша в процессе развития нашего проекта API Hub .

https://habr.com/ru/companies/cloud_x/articles/1024574/

#cloud_x_group #redis #кэш #cache #гибридный_кэш #кейс #оптимизация_запросов

Гибридный кэш на базе Redis в серверной разработке

В серверной разработке кэш влияет не только на скорость ответа. От него напрямую зависят стоимость обработки запроса, нагрузка на базу, поведение системы под пиком и предсказуемость масштабирования. Именно поэтому практика кэширования имеет сегодня столько нюансов и разновидностей, если вы хотите реализовать что-то особенное или применить сложную схему кэширования, от ваших специалистов потребуются специальные навыки и умения. Под катом — рассказ о том, как мы ушли от кастомного кода к использованию гибридного кэша из .Net Framework, с какими сложностями столкнулись на этапе масштабирования системы, и как решали вопросы инвалидации кэша в процессе развития нашего проекта API Hub .

https://habr.com/ru/companies/cloud_x/articles/1024574/

#cloud_x_group #redis #кэш #cache #гибридный_кэш #кейс #оптимизация_запросов

EXPLAIN ANALYZE в PostgreSQL: читаем планы выполнения экспертно

Привет, Хабр! Запрос работает 30 секунд. Вы смотрите на него, всё вроде ок: JOIN по индексированным полям, WHERE по дате, LIMIT 100. Должен летать, но что-то не летает. Добавляете индекс наугад — не помогает. Переписываете подзапрос в CTE и стало ещё хуже. Проблема не в запросе, а в в том, что вы не смотрели в план выполнения. EXPLAIN ANALYZE показывает не что вы написали, а что PostgreSQL делает: какие индексы использует (и использует ли вообще), в каком порядке соединяет таблицы, где тратит время, сколько строк ожидал и сколько получил. Понять PostgreSQL

https://habr.com/ru/companies/otus/articles/1014452/

#explain #psql #PostgreSQL #план_выполнения #оптимизация_запросов #индексы_PostgreSQL #производительность_БД

EXPLAIN ANALYZE в PostgreSQL: читаем планы выполнения экспертно

Привет, Хабр! Запрос работает 30 секунд. Вы смотрите на него, всё вроде ок: JOIN по индексированным полям, WHERE по дате, LIMIT 100. Должен летать, но что-то не летает. Добавляете индекс наугад — не помогает. Переписываете подзапрос в CTE и стало ещё хуже. Проблема не в запросе, а в в том, что вы не смотрели в план выполнения. EXPLAIN ANALYZE показывает не что вы написали, а что PostgreSQL делает: какие индексы использует (и использует ли вообще), в каком порядке соединяет таблицы, где тратит время, сколько строк ожидал и сколько получил. Понять PostgreSQL

https://habr.com/ru/companies/otus/articles/1014452/

#explain #psql #PostgreSQL #план_выполнения #оптимизация_запросов #индексы_PostgreSQL #производительность_БД

EXPLAIN ANALYZE в PostgreSQL: читаем планы выполнения экспертно

Привет, Хабр! Запрос работает 30 секунд. Вы смотрите на него, всё вроде ок: JOIN по индексированным полям, WHERE по дате, LIMIT 100. Должен летать, но что-то не летает. Добавляете индекс наугад — не помогает. Переписываете подзапрос в CTE и стало ещё хуже. Проблема не в запросе, а в в том, что вы не смотрели в план выполнения. EXPLAIN ANALYZE показывает не что вы написали, а что PostgreSQL делает: какие индексы использует (и использует ли вообще), в каком порядке соединяет таблицы, где тратит время, сколько строк ожидал и сколько получил. Понять PostgreSQL

https://habr.com/ru/companies/otus/articles/1014452/

#explain #psql #PostgreSQL #план_выполнения #оптимизация_запросов #индексы_PostgreSQL #производительность_БД

EXPLAIN ANALYZE в PostgreSQL: читаем планы выполнения экспертно

Привет, Хабр! Запрос работает 30 секунд. Вы смотрите на него, всё вроде ок: JOIN по индексированным полям, WHERE по дате, LIMIT 100. Должен летать, но что-то не летает. Добавляете индекс наугад — не помогает. Переписываете подзапрос в CTE и стало ещё хуже. Проблема не в запросе, а в в том, что вы не смотрели в план выполнения. EXPLAIN ANALYZE показывает не что вы написали, а что PostgreSQL делает: какие индексы использует (и использует ли вообще), в каком порядке соединяет таблицы, где тратит время, сколько строк ожидал и сколько получил. Понять PostgreSQL

https://habr.com/ru/companies/otus/articles/1014452/

#explain #psql #PostgreSQL #план_выполнения #оптимизация_запросов #индексы_PostgreSQL #производительность_БД

[Перевод] Как найти подозрительные логины из разных стран за 2 часа в PostgreSQL

В задачах на SQL особенно интересно то, что один и тот же результат часто можно получить несколькими способами – и разница между ними оказывается не только в красоте запроса, но и в его поведении на реальных данных. В этой статье – разбор прикладной задачи про поиск подозрительных логинов из разных стран в пределах двух часов: с вариантом через self join, альтернативой на оконных функциях и сравнением планов выполнения в PostgreSQL. Разбор запроса

https://habr.com/ru/companies/otus/articles/1014814/

#postgresql #SQL #оконные_функции #поиск_аномалий #безопасность_аккаунтов #анализ_сессий #временные_окна #оптимизация_запросов #EXPLAIN_ANALYZE

BRIN, GIN, B‑Tree: полный гайд по индексам PostgreSQL для highload

Индексы есть, а запросы всё равно тормозят? Или наоборот — индексов слишком много, и они только увеличивают нагрузку на запись? Многие разработчики и администраторы баз данных попадают в ловушку: ставят B-Tree на всё подряд и надеются на лучшее. Но в highload-системах это может привести к катастрофе. В этой статье я делюсь реальным опытом работы с PostgreSQL. Статья будет полезна разработчикам, архитекторам и администраторам, которые хотят не просто «поставить индекс», а понять, как работает PostgreSQL под капотом и как проектировать базы данных, выдерживающие миллионы запросов в секунду.

https://habr.com/ru/companies/otus/articles/1008372/

#архитектура #PostgreSQL #индексы #оптимизация_запросов #highload #базы_данных #BTree #BRIN

BRIN, GIN, B‑Tree: полный гайд по индексам PostgreSQL для highload

Индексы есть, а запросы всё равно тормозят? Или наоборот — индексов слишком много, и они только увеличивают нагрузку на запись? Многие разработчики и администраторы баз данных попадают в ловушку: ставят B-Tree на всё подряд и надеются на лучшее. Но в highload-системах это может привести к катастрофе. В этой статье я делюсь реальным опытом работы с PostgreSQL. Статья будет полезна разработчикам, архитекторам и администраторам, которые хотят не просто «поставить индекс», а понять, как работает PostgreSQL под капотом и как проектировать базы данных, выдерживающие миллионы запросов в секунду.

https://habr.com/ru/companies/otus/articles/1008372/

#архитектура #PostgreSQL #индексы #оптимизация_запросов #highload #базы_данных #BTree #BRIN

BRIN, GIN, B‑Tree: полный гайд по индексам PostgreSQL для highload

Индексы есть, а запросы всё равно тормозят? Или наоборот — индексов слишком много, и они только увеличивают нагрузку на запись? Многие разработчики и администраторы баз данных попадают в ловушку: ставят B-Tree на всё подряд и надеются на лучшее. Но в highload-системах это может привести к катастрофе. В этой статье я делюсь реальным опытом работы с PostgreSQL. Статья будет полезна разработчикам, архитекторам и администраторам, которые хотят не просто «поставить индекс», а понять, как работает PostgreSQL под капотом и как проектировать базы данных, выдерживающие миллионы запросов в секунду.

https://habr.com/ru/companies/otus/articles/1008372/

#архитектура #PostgreSQL #индексы #оптимизация_запросов #highload #базы_данных #BTree #BRIN

BRIN, GIN, B‑Tree: полный гайд по индексам PostgreSQL для highload

Индексы есть, а запросы всё равно тормозят? Или наоборот — индексов слишком много, и они только увеличивают нагрузку на запись? Многие разработчики и администраторы баз данных попадают в ловушку: ставят B-Tree на всё подряд и надеются на лучшее. Но в highload-системах это может привести к катастрофе. В этой статье я делюсь реальным опытом работы с PostgreSQL. Статья будет полезна разработчикам, архитекторам и администраторам, которые хотят не просто «поставить индекс», а понять, как работает PostgreSQL под капотом и как проектировать базы данных, выдерживающие миллионы запросов в секунду.

https://habr.com/ru/companies/otus/articles/1008372/

#архитектура #PostgreSQL #индексы #оптимизация_запросов #highload #базы_данных #BTree #BRIN

Как мы ускорили SQL-запросы: реальные кейсы оптимизации PostgreSQL

Достаточно большое количество проблем производительности в backend-приложениях на самом деле находятся не в коде. За последние пару лет мне несколько раз приходилось разбирать системы, где: • API отвечало слишком долго • CPU базы был загружен почти на 100%

https://habr.com/ru/articles/1012922/

#оптимизация_SQL #оптимизация_запросов_postgresql #оптимизация_запросов #sql #postgresql #производительность_базы_данных #join

[Перевод] Почему VACUUM не спасает от раздувания индексов в PostgreSQL

VACUUM в PostgreSQL принято считать универсальным средством поддержания порядка: он очищает мёртвые кортежи, обновляет статистику и вроде бы держит базу «в форме». Но с индексами всё сложнее. В какой-то момент они начинают расти и деградировать так, что это уже влияет на планы запросов и поведение оптимизатора — при том, что формально всё обслуживается корректно. Разберёмся, где именно возникает это расхождение между ожиданиями и реальностью и что на самом деле происходит внутри B-дерева. Разобраться глубже

https://habr.com/ru/companies/otus/articles/1012266/

#postgres #PostgreSQL #VACUUM #раздувание_индексов #Bдерево #планировщик_запросов #оптимизация_запросов #REINDEX #производительность_базы_данных

EXPLAIN ANALYZE: как находить узкие места в запросах PostgreSQL

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

https://habr.com/ru/companies/first/articles/1006278/

#оптимизация #базы_данных #postgresql #оптимизация_запросов #оптимизация_запросов_postgresql #разбор_плана_запроса

Django ORM: как QuerySet ленится, цепляется и генерирует SQL

Django ORM прячет SQL за красивым Python-интерфейсом. Пишешь User.objects.filter(active=True).order_by('name')[:10] — получаешь список пользователей. Круто. Но когда запросы тормозят или N+1 пожирает базу, приходится понимать, что вообще происходит. Разберём внутренности QuerySet: почему он ленивый, как работает chaining, когда запрос реально выполняется, и чем select_related отличается от prefetch_related на уровне SQL.

https://habr.com/ru/companies/otus/articles/988886/

#django #Django_ORM #QuerySet #ленивые_запросы #оптимизация_запросов #работа_с_БД

Условие в виртуальной таблице 1C

Волею судеб мне по работе пришлось посмотреть несколько занятий по подготовка к сертификации 1С:Специалист. И от одного лектора вдруг услышал, что использование в условиях виртуальной таблицы массивов, когда можно применить таблицу, — это плохо и медленно. А на сомнения слушателя он ответил: «Я гарантирую это». Думаю, ошибается человек, чего не бывает. И тут в другом занятии другой лектор говорит то же самое. Тут уже волей-неволей задумаешься: а вдруг я чего не помню уже? Но ведь не раз ускорял запросы, меняя таблицы на массивы. И захотелось проверить. Чем не повод для первой статьи на Хабре?

https://habr.com/ru/companies/T1Holding/articles/970234/

#1С #Запрос #оптимизация #оптимизация_запросов #фактчекинг

[Перевод] ACID-свойства транзакций в SQL

Для чего существуют принципы ACID? Можно ответить по бумажке, сказать, что это нужно для того, чтобы каждая транзакция обрабатывалась надежно, данные оставались в безопасности и системы работали предсказуемо. Все это в свою очередь должно гарантировать целостность данных. Но что это вообще такое и на что влияет? А ответ очень простой. Обеспечивая целостность данных, мы предупреждаем ситуации, когда, к примеру, деньги со счета списались, но получателю так и не пришли. Или заказ оформился, а складские остатки не обновились. В этой статье вы узнаете, почему так важны принципы ACID и что это за принципы. Оставайтесь со мной, если интересно!

https://habr.com/ru/companies/otus/articles/968212/

#acid #транзакции #реляционные_базы_данных #согласованность_данных #блокировки #распределённые_системы #NoSQL #оптимизация_запросов

[Перевод] Эвристика: OR в SQL — это дорого

Один запрос выполняется 100 мс, другой — меньше 1 мс. Оба делают одно и то же, но второй написан на странном, почти алхимическом SQL. В чём подвох? Первый использует OR , а второй — хитрую комбинацию AND . Этот перевод — расследование того, почему условие OR так дорого обходится вашей базе данных, и практическое руководство по тому, как проектировать схемы, чтобы избежать этой ловушки производительности.

https://habr.com/ru/companies/postgrespro/articles/953506/

#оптимизация_запросов #планировщик_запросов #индексы #базы_данных #postgresql #postgres #postgresql_17 #postgresql_18

Нейронные оптимизаторы запросов в реляционных БД (Часть 2): На пути к продуктивизации

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

https://habr.com/ru/companies/postgrespro/articles/848218/

#оптимизация #Bao #AQO #нейросети #оптимизация_запросов #машинное_обучение #обучение_с_подкреплением #многорукие_бандиты #knn #reinforcementlearning

Пять возможностей PostgreSQL, о которых редко вспоминают

Привет, Хабр! Постгрес – не просто реляционная БД, а настоящий кладезь фич, о которых начинающий разработчик может и не догадываться. Всё началось с того, что PostgreSQL изначально писался на С/C++ и всегда тянуло к расширению стандартного SQL набора возможностей. Так однажды разработчики решили добавить в него JSONB , логику на уровне запросов и многое другое – что в итоге сделало его не хуже NoSQL-систем. Но вернёмся к малоизвестным фичам. Ниже – пять приёмов и возможностей, которые неожиданно полезны в повседневной работе.

https://habr.com/ru/companies/otus/articles/941456/

#psql #postgresql #базы_данных #оптимизация_запросов #права_доступа #диапазонные_типы #производительность

Анализ плана выполнения запроса с оконной функцией в SQL Server (+бонус)

В статье подробно разбирается план выполнения запроса с оконной функцией в MS SQL Server, проводится сравнительный тест производительности с альтернативным запросом. Статья будет полезна разработчикам, работающим с аналитическими запросами в SQL Server, а также всем, кто хочет глубже понять логику оптимизатора и влияние различных факоров на планы выполнения.

https://habr.com/ru/articles/918210/

#tsql #ms_sql_server #план_выполнения_запросов #оптимизация_запросов

Отслеживание изменений размеров таблиц Arenadata DB

История, связанная с этой задачей, началась для нас в мае 2024 года. Один из крупных пользователей Greenplum/Arenadata DB обратился к нам с запросом реализовать возможность отслеживания изменения размеров файлов данных таблиц. Эта функциональность стала бы составной частью, источником событий для системы мониторинга пользовательских кластеров. Задача показалась нам крайне интересной и перспективной. Однако пользователю, как это часто бывает, решение требовалось уже вчера. С одной стороны, мы осознавали всю сложность этой задачи в полнофункциональной реализации для всех пользователей нашего продукта (и как следствие, адекватно оценивали предполагаемые трудозатраты). С другой стороны, затачивать решение под конкретного пользователя, но в то же время и поставлять эту реализацию как часть общего решения мы сочли неправильным. По итогу команда разработки продолжила работу в своём темпе и в соответствии со своим представлением о реализации.

https://habr.com/ru/companies/arenadata/articles/881808/

#arenadata_db #monitoring #greenplum #postgres #bloom_filter #оптимизация_запросов #big_data #grafana #субд #метрики

Простая минификация Json тел запросов / ответов с Kotlin Serialization

Привет! Недавно в рамках одного из проектов на стеке KMP, Ktor и Kotlin Serialization мы с командой решили провести эксперимент и определить возможность и целесобразность минификации тел запросов / ответов на Json. Да, мы знаем про GraphQL, Protobuf и др., но в нашем случае имел место необузданный интерес наколхозить такое решение. И при всей его наивности удалось сократить средний размер итоговых джсонов (после всех внутренних оптимизаций) на 15-20%.

https://habr.com/ru/articles/933474/

#kotlin #kmp #kotlin_multiplatform #ktor #json #kotlin_serialization #оптимизация_запросов #http #архитектура #сериализация

Правильный порядок колонок в B-tree индексах PostgreSQL или правило ESR

Когда в проекте используется составной B-tree индекс, важно не просто "создать индекс", а сделать это правильно — иначе запросы могут не только не ускориться, но и начать работать медленнее. Возникает логичный вопрос: как выбрать порядок колонок, чтобы индекс действительно работал эффективно? Брутфорсом? По интуиции? По селективности? В этой статье я расскажу, как подходить к построению составных индексов в PostgreSQL, на что реально влияет порядок колонок. Также разберём простое правило ESR, которое помогает упростить выбор и получать стабильный прирост производительности на всех стендах.

https://habr.com/ru/articles/911688/

#postgresql #Btree #составной_индекс #многоколонковый_индекс #ESR_правило #оптимизация_запросов #селективность #план_выполнения #explain_analyze #индексный_скан

Оптимизация инсертов в ClickHouse через Kafka Sink-коннекторы

Меня зовут Артем Москальков, я — ведущий инженер данных в Магнит OMNI. В статье я расскажу о том, как мы оптимизировали производительность кластера в ClickHouse. Частые мелкие вставки данных через Kafka Sink-коннектор серьёзно замедляли работу ClickHouse из-за огромного числа отдельных запросов. Путём настройки параметров потребителя Kafka и включения объединения партиций удалось сгруппировать записи в крупные блоки, что резко снизило нагрузку на базу и многократно увеличило её пропускную способность.

https://habr.com/ru/companies/magnit/articles/926834/

#kafka #инсерт #оптимизация_запросов #clickhouse #коннекторы #insert #etl #etlпроцессы #dwh #elt

Миграция витрины данных с СУБД Teradata в СУБД Greenplum

Миграция СУБД с одной технологии на другую — сложный процесс, который связан не только с конвертацией кода и переливкой данных из одной системы в другую, хотя и здесь есть неочевидные нюансы. Это часто и вопросы, связанные с совместимостью функциональности, производительностью, безопасностью данных, архитектурными особенностями новой системы и многими другими аспектами. Меня зовут Станислав Свириденко и я DWH-разработчик AXENIX. В этой статье хочу рассказать об опыте миграции витрины данных с проприетарной СУБД Teradata на свободную СУБД GreenPlum. Поговорим о задачах, подводных камнях, на которые мы периодически натыкались, и способах решений, найденных в процессе.

https://habr.com/ru/companies/oleg-bunin/articles/821045/

#greenplum #sql #teradata #субд #миграция_базы_данных #конвертация_бд #сопоставление_данных #оптимизация_запросов #политики_доступа #мониторинг

Загадка от Жака Фреско: как построить свой Rate Limiter и не утонуть в море компромиссов

Построить Rate Limiter — легко. Сделать его быстрым, отказоустойчивым и работающим в нескольких дата-центрах — сложнее. Делюсь опытом реализации нашего облачного Rate Limiter в DDoS-Guard: принцип работы, анализ правил и реальные примеры из практики.

https://habr.com/ru/companies/ddosguard/articles/908662/

#ratelimit #rate_limiting #ratelimiter #rate_limiter #ddosguard #оптимизация_запросов #429_request #облачные_решения #redis #consul

Хеш-индексы в PostgreSQL: быстрый поиск или скрытые проблемы?

Хеш-индексы в PostgreSQL - мощный, но недооценённый инструмент. Когда они быстрее B-Tree, а когда наоборот? Простое объяснение, тесты и ключевые нюансы, которые помогут ускорить запросы...

https://habr.com/ru/articles/882106/

#базы_данных #sql #оптимизация_запросов #индексы #btree #hash #производительность #BTree_vs_Hash #разработка #dba

Проекции в Vertica: что это, как использовать, и почему не стоит создавать их под каждый запрос

Иван Якунин, продуктовый аналитик команды Fintech Marketplace, рассказал про то, как в Авито работают с Vertica, и на примерах объяснил, что такое проекции, и когда их стоит использовать.

https://habr.com/ru/companies/avito/articles/808713/

#sql #vertica #проекции #оптимизация_запросов

Оптимизация БД начинается в пятницу

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

https://habr.com/ru/companies/uzum/articles/940624/

#postgresql #postgresql_performance #оптимизация_запросов #оптимизация #оптимизация_кода #uzum #uzumtech

Нейронные оптимизаторы запросов в реляционных БД (Часть 3): Погружение в ранжирование

Ранжирование — это уникальная разновидность задач в машинном обучении, обособленная как от классификации, так и регрессии. Заключительная статья по нейрооптимизаторам в РСУБД, как ни странно, связана именно с ней. Бум в развитии подобных моделей произошёл совсем недавно — в 2023 году, что мы с вами подробно разберём. Сначала погрузимся в ранжирование в целом, а затем увидим, как в соответствии с новой постановкой задачи адаптировались методы поиска оптимального плана исполнения запроса.

https://habr.com/ru/companies/postgrespro/articles/857998/

#оптимизация #нейросети #ранжирование #ltr #оптимизация_запросов #машинное_обучение #LambdaLoss #SoftRank #LambdaRank

[Перевод] Почему не стоит заменять пустые значения на 0 в Power BI

Если вы когда-либо занимались построением отчётов в Power BI, то наверняка сталкивались с просьбой «заменить пустые значения на ноль — чтобы было красиво». Кажется, мелочь. Но на самом деле это решение может незаметно убить производительность модели, превратить быстрый отчёт в тормозящий интерфейс, а оптимизатор — в беспомощного наблюдателя. В этой статье — разбор того, что происходит под капотом VertiPaq, как DAX на самом деле обрабатывает BLANK , и почему иногда лучше оставить пустое значение пустым.

https://habr.com/ru/companies/otus/articles/934484/

#power_bi #dax #BLANK #производительность_отчётов #оптимизация_запросов #VertiPaq #аналитическая_модель #бизнесотчётность #фильтрация_данных

Техническая внутренняя кухня StarRocks: оптимизация JOIN — от логики до распределённого выполнения

Как StarRocks добивается высокой производительности JOIN-запросов в аналитических нагрузках. В материале — практическая кухня оптимизатора: какие типы JOIN эффективнее и когда их стоит конвертировать (например, CROSS→INNER, OUTER→INNER при NULL‑отвергающих предикатах), как работает predicate pushdown, извлечение предикатов из OR, вывод эквивалентностей и pushdown LIMIT. Разбираем Join Reorder для многотабличных запросов (Left‑Deep, Exhaustive, Greedy, DPsub), модель стоимости (CPU*(Row(L)+Row(R))+Memory*Row(R)) и выбор лучшего плана. На уровне распределённого исполнения — MPP‑архитектура, свойства распределения (Distribution Property) и узлы Exchange; пять базовых планов: Shuffle, Broadcast, Bucket Shuffle, Colocate и экспериментальный Replicate Join. Плюс Global Runtime Filter (Min/Max, IN, Bloom) для ранней фильтрации на Scan. Даем практические принципы: используйте более быстрые типы JOIN, стройте хеш по малой таблице, в многоJOINовых запросах сперва выполняйте высокоселективные соединения, сокращайте объём данных и сетевой трафик. Материал для инженеров данных, DBA, разработчиков OLAP и всех, кто проектирует производительные SQL‑планы.

https://habr.com/ru/articles/943050/

#starrocks #join #оптимизация_запросов #mpp #распределенный #predicate #olapкубы

Анализ плана выполнения запроса с оконной функцией в SQL Server (+бонус)

В статье подробно разбирается план выполнения запроса с оконной функцией в MS SQL Server, проводится сравнительный тест производительности с альтернативным запросом. Статья будет полезна разработчикам, работающим с аналитическими запросами в SQL Server, а также всем, кто хочет глубже понять логику оптимизатора и влияние различных факоров на планы выполнения.

https://habr.com/ru/articles/918210/

#tsql #ms_sql_server #план_выполнения_запросов #оптимизация_запросов

Анализ плана выполнения запроса с оконной функцией в SQL Server (+бонус)

В статье подробно разбирается план выполнения запроса с оконной функцией в MS SQL Server, проводится сравнительный тест производительности с альтернативным запросом. Статья будет полезна разработчикам, работающим с аналитическими запросами в SQL Server, а также всем, кто хочет глубже понять логику оптимизатора и влияние различных факоров на планы выполнения.

https://habr.com/ru/articles/918210/

#tsql #ms_sql_server #план_выполнения_запросов #оптимизация_запросов