Анализ вариантов оптимизации ресурсоёмкого SQL-запроса: Вариант-3 «Частичная агрегация»

Не верь на слово, проверь под давлением.

Предисловие

Оптимизировать запрос в вакууме — просто. Но как он поведет себя, когда десятки таких же запросов одновременно борются за ресурсы?

Методология исследования

Тестовая среда и инструменты:

• Тестовая ВМ: CPU = 8 / RAM = 8GB

• Инструмент нагрузочного тестирования и статистического анализа производительности СУБД: pg_expecto

• Тестовая база данных: "Демобаза 2.0" (большой размер, сложная схема)

• Условия тестирования: параллельная нагрузка, ресурсоемкий запрос

• СУБД: PostgreSQL 17

Конфигурационные параметры СУБД

track_io_timing = 'on'
listen_addresses = '0.0.0.0'
logging_collector = 'on'
log_directory = '/log/pg_log'
log_destination = 'stderr'
log_rotation_size = '0'
log_rotation_age = '1d'
log_filename = 'postgresql-%u.log'
log_line_prefix = '%m| %d| %a| %u| %h| %p| %e| '
log_truncate_on_rotation = 'on'
log_checkpoints = 'on'
archive_mode = 'on'
archive_command = 'true'
archive_timeout = '30min'
checkpoint_timeout = '15min'
checkpoint_warning = '60'
checkpoint_completion_target = '0.9'
min_wal_size = '2GB'
max_wal_size = '8GB'
synchronous_commit = 'on'
wal_compression = 'on'
random_page_cost = '1.1'
effective_io_concurrency = '300'
wal_sender_timeout = '0'
autovacuum_naptime = '1s'
autovacuum_vacuum_scale_factor = '0.01'
autovacuum_analyze_scale_factor = '0.005'
autovacuum_vacuum_cost_delay = '2ms'
autovacuum_max_workers = '4'
autovacuum_work_mem = '256MB'
vacuum_cost_limit = '4000'
bgwriter_delay = '10ms'
bgwriter_lru_multiplier = '4'
bgwriter_lru_maxpages = '400'
max_locks_per_transaction = '256'
max_pred_locks_per_transaction = '256'
shared_buffers = '1919MB'
effective_cache_size = '5757MB'
work_mem = '14MB'
temp_buffers = '14MB'
maintenance_work_mem = '479MB'
max_worker_processes = '8'
max_parallel_workers = '8'
max_parallel_workers_per_gather = '4'
idle_in_transaction_session_timeout = '1h'
statement_timeout = '8h'
pg_stat_statements.track_utility = 'off'
max_parallel_maintenance_workers = '4'
hash_mem_multiplier = '2'
autovacuum_vacuum_insert_scale_factor = '0.01'
shared_preload_libraries = 'pg_stat_statements , pg_wait_sampling'
commit_delay = '1000'
log_autovacuum_min_duration = '0'
wipe_file_on_delete = 'on'
wipe_heaptuple_on_delete = 'on'
wipe_mem_on_free = 'on'
wipe_memctx_on_free = 'on'
wipe_xlog_on_free = 'on'
log_connections = 'on'
log_disconnections = 'on'
pg_stat_statements.track = 'all'
max_connections = '1000'

План нагрузочного тестирования (param.conf)

# НАСТРОЙКИ НАГРУЗОЧНОГО ТЕСТИРОВАНИЯ
# Максимальная нагрузка
finish_load = 20
# Тестовая БД
testdb = demo
# Веса сценариев
scenario1 = 1.0

Нагрузка на СУБД

Тестовый запрос, используемый в качестве baseline : LEFT JOIN

Запрос демонстрирует:

1. LEFT JOIN bookings → tickets
   Все бронирования, даже без привязанных билетов

2. LEFT JOIN tickets → segments
   Все билеты, даже без перелётов

3. LEFT JOIN segments → flights
   Все перелёты, даже без информации о рейсах

4. LEFT JOIN segments → boarding_passes
   Все перелёты, даже без посадочных талонов

5. Выбирает случайную дату из существующих бронирований

6. Гарантирует, что период полностью входит в доступный диапазон дат

Такой запрос может быть полезен для анализа:

• Неполных бронирований

• Билетов без привязки к рейсам

• Рейсов без процедуры посадки

• Статистики по незавершённым операциям

Таблицы, используемые в тестовом запросе

demo=# \d bookings
                    Unlogged table "bookings.bookings"
    Column    |           Type           | Collation | Nullable | Default
--------------+--------------------------+-----------+----------+---------
 book_ref     | character(6)             |           | not null |
 book_date    | timestamp with time zone |           | not null |
 total_amount | numeric(10,2)            |           | not null |
Indexes:
    "bookings_pkey" PRIMARY KEY, btree (book_ref)
    "idx_bookings_book_date" btree (book_date)
Referenced by:
    TABLE "tickets" CONSTRAINT "tickets_book_ref_fkey" FOREIGN KEY (book_ref) REFERENCES bookings(book_ref)

demo=# \d tickets
               Unlogged table "bookings.tickets"
     Column     |     Type     | Collation | Nullable | Default
----------------+--------------+-----------+----------+---------
 ticket_no      | text         |           | not null |
 book_ref       | character(6) |           | not null |
 passenger_id   | text         |           | not null |
 passenger_name | text         |           | not null |
 outbound       | boolean      |           | not null |
Indexes:
    "tickets_pkey" PRIMARY KEY, btree (ticket_no)
    "idx_tickets_book_ref" btree (book_ref)
    "tickets_book_ref_passenger_id_outbound_key" UNIQUE CONSTRAINT, btree (book_ref, passenger_id, outbound)
Foreign-key constraints:
    "tickets_book_ref_fkey" FOREIGN KEY (book_ref) REFERENCES bookings(book_ref)
Referenced by:
    TABLE "segments" CONSTRAINT "segments_ticket_no_fkey" FOREIGN KEY (ticket_no) REFERENCES tickets(ticket_no)

demo=#  \d segments
                Unlogged table "bookings.segments"
     Column      |     Type      | Collation | Nullable | Default
-----------------+---------------+-----------+----------+---------
 ticket_no       | text          |           | not null |
 flight_id       | integer       |           | not null |
 fare_conditions | text          |           | not null |
 price           | numeric(10,2) |           | not null |
Indexes:
    "segments_pkey" PRIMARY KEY, btree (ticket_no, flight_id)
    "idx_segments_flight_id" btree (flight_id)
    "idx_segments_flight_id_fare_conditions" btree (flight_id, fare_conditions)
    "idx_segments_ticket_no" btree (ticket_no)
    "segments_flight_id_idx" btree (flight_id)
Check constraints:
    "segments_fare_conditions_check" CHECK (fare_conditions = ANY (ARRAY['Economy'::text, 'Comfort'::text, 'Business'::text]))
    "segments_price_check" CHECK (price >= 0::numeric)
Foreign-key constraints:
    "segments_flight_id_fkey" FOREIGN KEY (flight_id) REFERENCES flights(flight_id)
    "segments_ticket_no_fkey" FOREIGN KEY (ticket_no) REFERENCES tickets(ticket_no)
Referenced by:
    TABLE "boarding_passes" CONSTRAINT "boarding_passes_ticket_no_flight_id_fkey" FOREIGN KEY (ticket_no, flight_id) REFERENCES segments(ticket_no, flight_id)

demo=# \d boarding_passes
                 Unlogged table "bookings.boarding_passes"
    Column     |           Type           | Collation | Nullable | Default
---------------+--------------------------+-----------+----------+---------
 ticket_no     | text                     |           | not null |
 flight_id     | integer                  |           | not null |
 seat_no       | text                     |           | not null |
 boarding_no   | integer                  |           |          |
 boarding_time | timestamp with time zone |           |          |
Indexes:
    "boarding_passes_pkey" PRIMARY KEY, btree (ticket_no, flight_id)
    "boarding_passes_flight_id_boarding_no_key" UNIQUE CONSTRAINT, btree (flight_id, boarding_no)
    "boarding_passes_flight_id_boarding_time" btree (flight_id, boarding_time)
    "boarding_passes_flight_id_seat_no_key" UNIQUE CONSTRAINT, btree (flight_id, seat_no)
Foreign-key constraints:
    "boarding_passes_ticket_no_flight_id_fkey" FOREIGN KEY (ticket_no, flight_id) REFERENCES segments(ticket_no, flight_id)

demo=# \d flights
                                  Unlogged table "bookings.flights"
       Column        |           Type           | Collation | Nullable |           Default
---------------------+--------------------------+-----------+----------+------------------------------
 flight_id           | integer                  |           | not null | generated always as identity
 route_no            | text                     |           | not null |
 status              | text                     |           | not null |
 scheduled_departure | timestamp with time zone |           | not null |
 scheduled_arrival   | timestamp with time zone |           | not null |
 actual_departure    | timestamp with time zone |           |          |
 actual_arrival      | timestamp with time zone |           |          |
Indexes:
    "flights_pkey" PRIMARY KEY, btree (flight_id)
    "flights_route_no_scheduled_departure_key" UNIQUE CONSTRAINT, btree (route_no, scheduled_departure)
    "idx_flights_route_no" btree (route_no)
    "idx_flights_scheduled_departure" btree (scheduled_departure DESC)
Check constraints:
    "flight_actual_check" CHECK (actual_arrival IS NULL OR actual_departure IS NOT NULL AND actual_arrival IS NOT NULL AND actual_arrival > actual_departure)
    "flight_scheduled_check" CHECK (scheduled_arrival > scheduled_departure)
    "flight_status_check" CHECK (status = ANY (ARRAY['Scheduled'::text, 'On Time'::text, 'Delayed'::text, 'Boarding'::text, 'Departed'::text, 'Arrived'::text, 'Cancelled'::text]))
Referenced by:
    TABLE "segments" CONSTRAINT "segments_flight_id_fkey" FOREIGN KEY (flight_id) REFERENCES flights(flight_id)

Тестовый запрос - LEFT JOIN

WITH random_period AS (
    SELECT 
        start_date,
        start_date + INTERVAL '30 days' AS end_date
    FROM (
        SELECT 
            book_date AS start_date
        FROM bookings
        WHERE book_date <= (SELECT MAX(book_date) FROM bookings) - INTERVAL '30 days'
        ORDER BY RANDOM()
        LIMIT 1
    ) AS random_date
)
SELECT 
    b.book_ref,
    b.book_date,
    t.ticket_no,
    t.passenger_name,
    s.flight_id,
    f.status,
    f.scheduled_departure,
    f.actual_departure,
    bp.seat_no,
    bp.boarding_no,
    rp.start_date AS period_start,
    rp.end_date AS period_end
FROM random_period rp
CROSS JOIN LATERAL (
    SELECT *
    FROM bookings b
    WHERE b.book_date BETWEEN rp.start_date AND rp.end_date
) b
LEFT JOIN tickets t ON b.book_ref = t.book_ref
LEFT JOIN segments s ON t.ticket_no = s.ticket_no
LEFT JOIN flights f ON s.flight_id = f.flight_id
LEFT JOIN boarding_passes bp ON 
    s.ticket_no = bp.ticket_no 
    AND s.flight_id = bp.flight_id
ORDER BY b.book_date, t.ticket_no;

План выполнения тестового запроса - LEFT JOIN

Sort  (cost=2544355.52..2550077.32 rows=2288717 width=93) (actual time=58778.563..59050.999 rows=1146771 loops=1)
   Sort Key: b.book_date, t.ticket_no
   Sort Method: external merge  Disk: 121832kB
   CTE random_period
     ->  Subquery Scan on random_date  (cost=66429.70..66429.71 rows=1 width=16) (actual time=2883.937..2883.945 rows=1 loops=1)
           ->  Limit  (cost=66429.70..66429.70 rows=1 width=16) (actual time=2883.919..2883.925 rows=1 loops=1)
                 InitPlan 2
                   ->  Result  (cost=0.45..0.46 rows=1 width=8) (actual time=1.994..1.996 rows=1 loops=1)
                         InitPlan 1
                           ->  Limit  (cost=0.43..0.45 rows=1 width=8) (actual time=1.989..1.991 rows=1 loops=1)
                                 ->  Index Only Scan Backward using idx_bookings_book_date on bookings  (cost=0.43..128154.91 rows=7113192 width=8) (actual time=1.988..1.989 rows=1 loops=1)
                                       Heap Fetches: 0
                 ->  Sort  (cost=66429.24..72356.90 rows=2371064 width=16) (actual time=2883.917..2883.918 rows=1 loops=1)
                       Sort Key: (random())
                       Sort Method: top-N heapsort  Memory: 25kB
                       ->  Index Only Scan using idx_bookings_book_date on bookings bookings_1  (cost=0.43..54573.91 rows=2371064 width=16) (actual time=2.183..1714.099 rows=6894590 loops=1)
                             Index Cond: (book_date <= ((InitPlan 2).col1 - '30 days'::interval))
                             Heap Fetches: 0
   ->  Hash Left Join  (cost=685482.92..2046557.85 rows=2288717 width=93) (actual time=49378.694..57307.629 rows=1146771 loops=1)
         Hash Cond: (s.flight_id = f.flight_id)
         ->  Merge Right Join  (cost=681880.13..2036946.95 rows=2288717 width=69) (actual time=49326.107..56627.660 rows=1146771 loops=1)
               Merge Cond: (s.ticket_no = t.ticket_no)
               ->  Merge Left Join  (cost=1.12..1264914.46 rows=20598448 width=25) (actual time=3.919..32375.016 rows=6564405 loops=1)
                     Merge Cond: ((s.ticket_no = bp.ticket_no) AND (s.flight_id = bp.flight_id))
                     ->  Index Only Scan using segments_pkey on segments s  (cost=0.56..424624.50 rows=20598448 width=18) (actual time=3.875..1950.364 rows=6564405 loops=1)
                           Heap Fetches: 0
                     ->  Index Scan using boarding_passes_pkey on boarding_passes bp  (cost=0.56..637941.24 rows=19870556 width=25) (actual time=0.033..25169.883 rows=6564405 loops=1)
               ->  Materialize  (cost=681879.01..690532.20 rows=1730639 width=58) (actual time=21308.253..22022.391 rows=1146771 loops=1)
                     ->  Sort  (cost=681879.01..686205.61 rows=1730639 width=58) (actual time=21308.245..21812.491 rows=862459 loops=1)
                           Sort Key: t.ticket_no
                           Sort Method: external merge  Disk: 58600kB
                           ->  Nested Loop Left Join  (cost=0.87..464448.40 rows=1730639 width=58) (actual time=2886.101..18909.459 rows=862459 loops=1)
                                 ->  Nested Loop  (cost=0.43..31711.08 rows=790355 width=31) (actual time=2884.013..3268.567 rows=397632 loops=1)
                                       ->  CTE Scan on random_period rp  (cost=0.00..0.02 rows=1 width=16) (actual time=2883.941..2883.946 rows=1 loops=1)
                                       ->  Index Scan using idx_bookings_book_date on bookings b  (cost=0.43..23807.51 rows=790355 width=15) (actual time=0.063..308.659 rows=397632 loops=1)
                                             Index Cond: ((book_date >= rp.start_date) AND (book_date <= rp.end_date))
                                 ->  Index Scan using idx_tickets_book_ref on tickets t  (cost=0.43..0.52 rows=3 width=34) (actual time=0.038..0.038 rows=2 loops=397632)
                                       Index Cond: (book_ref = b.book_ref)
         ->  Hash  (cost=2247.35..2247.35 rows=108435 width=28) (actual time=52.383..52.385 rows=108435 loops=1)
               Buckets: 131072  Batches: 1  Memory Usage: 7377kB
               ->  Seq Scan on flights f  (cost=0.00..2247.35 rows=108435 width=28) (actual time=0.024..22.614 rows=108435 loops=1)
 Planning Time: 37.456 ms
 Execution Time: 59151.413 ms

---

Эксперимент-1 : вариант с использованием EXISTS

Эксперимент-2 : вариант с оптимизацией структуры запроса (TUNING)

Эксперимент-3 «Частичная агрегация»

Тестовый запрос - ARRAY

WITH random_period AS (
    SELECT 
        book_date AS start_date,
        book_date + INTERVAL '30 days' AS end_date
    FROM bookings 
    ORDER BY RANDOM() 
    LIMIT 1
),
booking_summary AS (
    SELECT 
        b.book_ref,
        b.book_date,
        COUNT(t.ticket_no) as ticket_count,
        ARRAY_AGG(t.ticket_no) as ticket_numbers
    FROM bookings b
    LEFT JOIN tickets t ON b.book_ref = t.book_ref
    WHERE b.book_date BETWEEN (SELECT start_date FROM random_period) 
                        AND (SELECT end_date FROM random_period)
    GROUP BY b.book_ref, b.book_date
)
SELECT 
    bs.book_ref,
    bs.book_date,
    bs.ticket_count,
    tn.ticket_no,  -- Используем развернутое значение
    t.passenger_name,
    s.flight_id,
    f.status
FROM booking_summary bs
CROSS JOIN UNNEST(bs.ticket_numbers) AS tn(ticket_no)  -- Разворачиваем массив здесь
LEFT JOIN tickets t ON t.ticket_no = tn.ticket_no      -- Теперь соединяем по одиночному значению
LEFT JOIN segments s ON s.ticket_no = t.ticket_no
LEFT JOIN flights f ON f.flight_id = s.flight_id
ORDER BY bs.book_date, tn.ticket_no;  -- Сортируем по развернутому значению

План выполнения тестового запроса - ARRAY

 Sort  (cost=602598.54..603774.42 rows=470349 width=80) (actual time=32916.398..33173.216 rows=1078047 loops=1)
   Sort Key: b.book_date, tn.ticket_no
   Sort Method: external merge  Disk: 78992kB
   CTE random_period
     ->  Limit  (cost=191879.84..191879.84 rows=1 width=24) (actual time=4366.534..4366.546 rows=1 loops=1)
           ->  Sort  (cost=191879.84..209662.82 rows=7113192 width=24) (actual time=4366.531..4366.534 rows=1 loops=1)
                 Sort Key: (random())
                 Sort Method: top-N heapsort  Memory: 25kB
                 ->  Seq Scan on bookings  (cost=0.00..156313.88 rows=7113192 width=24) (actual time=0.147..3051.234 rows=7113192 loops=1)
   ->  Hash Left Join  (cost=86766.61..332003.89 rows=470349 width=80) (actual time=12377.785..31429.152 rows=1078047 loops=1)
         Hash Cond: (s.flight_id = f.flight_id)
         ->  Nested Loop Left Join  (cost=83163.83..327166.39 rows=470349 width=72) (actual time=12311.365..30556.856 rows=1078047 loops=1)
               ->  Nested Loop Left Join  (cost=83163.26..104902.04 rows=355660 width=82) (actual time=12311.267..23764.409 rows=821542 loops=1)
                     ->  Nested Loop  (cost=83162.69..95979.99 rows=355660 width=55) (actual time=12311.155..14786.294 rows=821542 loops=1)
                           ->  Finalize GroupAggregate  (cost=83162.69..88866.79 rows=35566 width=55) (actual time=12311.108..13733.846 rows=388524 loops=1)
                                 Group Key: b.book_ref
                                 InitPlan 2
                                   ->  CTE Scan on random_period  (cost=0.00..0.02 rows=1 width=8) (actual time=4366.541..4366.544 rows=1 loops=1)
                                 InitPlan 3
                                   ->  CTE Scan on random_period random_period_1  (cost=0.00..0.02 rows=1 width=8) (actual time=0.001..0.002 rows=1 loops=1)
                                 ->  Gather Merge  (cost=83162.65..88066.51 rows=35566 width=55) (actual time=12311.079..13099.448 rows=388524 loops=1)
                                       Workers Planned: 1
                                       Workers Launched: 1
                                       ->  Partial GroupAggregate  (cost=82162.64..83065.33 rows=35566 width=55) (actual time=7912.508..8455.765 rows=194262 loops=2)
                                             Group Key: b.book_ref
                                             ->  Sort  (cost=82162.64..82277.17 rows=45811 width=29) (actual time=7912.458..8132.223 rows=410771 loops=2)
                                                   Sort Key: b.book_ref
                                                   Sort Method: external merge  Disk: 16168kB
                                                   Worker 0:  Sort Method: external merge  Disk: 16016kB
                                                   ->  Nested Loop Left Join  (cost=0.87..78616.09 rows=45811 width=29) (actual time=1.708..7358.141 rows=410771 loops=2)
                                                         ->  Parallel Index Scan using idx_bookings_book_date on bookings b  (cost=0.43..982.51 rows=20921 width=15) (actual time=0.892..210.773 rows=194262 loops=2)
                                                               Index Cond: ((book_date >= (InitPlan 2).col1) AND (book_date <= (InitPlan 3).col1))
                                                         ->  Index Scan using idx_tickets_book_ref on tickets t_1  (cost=0.43..3.68 rows=3 width=21) (actual time=0.035..0.036 rows=2 loops=388524)
                                                               Index Cond: (book_ref = b.book_ref)
                           ->  Function Scan on unnest tn  (cost=0.00..0.10 rows=10 width=32) (actual time=0.001..0.001 rows=2 loops=388524)
                     ->  Memoize  (cost=0.57..2.79 rows=1 width=27) (actual time=0.010..0.010 rows=1 loops=821542)
                           Cache Key: tn.ticket_no
                           Cache Mode: logical
                           Hits: 0  Misses: 821542  Evictions: 607974  Overflows: 0  Memory Usage: 28673kB
                           ->  Index Scan using tickets_pkey on tickets t  (cost=0.56..2.78 rows=1 width=27) (actual time=0.009..0.009 rows=1 loops=821542)
                                 Index Cond: (ticket_no = tn.ticket_no)
               ->  Index Only Scan using segments_pkey on segments s  (cost=0.56..0.60 rows=2 width=18) (actual time=0.007..0.008 rows=1 loops=821542)
                     Index Cond: (ticket_no = t.ticket_no)
                     Heap Fetches: 0
         ->  Hash  (cost=2247.35..2247.35 rows=108435 width=12) (actual time=66.115..66.117 rows=108435 loops=1)
               Buckets: 131072  Batches: 1  Memory Usage: 5727kB
               ->  Seq Scan on flights f  (cost=0.00..2247.35 rows=108435 width=12) (actual time=0.056..32.890 rows=108435 loops=1)
 Planning Time: 61.057 ms
 Execution Time: 33270.417 ms

Сравнительный анализ планов выполнения запросов

Преимущества:

• В 1.8 раза быстре�� основного запроса

• Использование параллельных вычислений (Workers Launched: 1)

• Эффективное кэширование (Memoize с логическим кэшированием)

• Меньше планируемых строк для обработки (470K)

Недостатки:

• Более сложное планирование (61.1 мс)

• Использование агрегации и развертывания массивов

• Больше операций с памятью (28.7 MB для кэша)

Ключевые отличия при использовании частичной агрегации

• Агрегация в CTE с ARRAY_AGG

• Развертывание массивов через UNNEST

• Параллельная обработку

• Логическое кэширование результатов

Производительность и ожидания СУБД

Операционная скорость

График изменения операционной скорости в ходе нагрузочного тестирования при использоваении тестового запроса "JOIN" и "ARRAY"

График изменения относительной разницы операционной скорости для запроса "ARRAY" по сравнению с тестовым запросом "JOIN"

Среднее увеличение операционной скорости при использовании запроса "ARRAY" составило 120.15%

Ожидания СУБД

График изменения ожиданий СУБД в ходе нагрузочного тестирования при использоваении тестового запроса "JOIN" и "ARRAY"

График изменения относительной разницы ожиданий СУБД для запроса "ARRAY" по сравнению с тестовым запросом "JOIN"

Сравнительный анализ wait_event_type

1. wait_event_type = IO

• LEFT JOIN : Экстремально высокие значения (до 15K), быстрый рост

• ARRAY: В 2 раза меньше максимальная нагрузка (до 8K), более стабильный рост

• Вывод: ARRAY значительно эффективнее работает с диском

2. wait_event_type = IPC

• LEFT JOIN : Очень высокие значения (до 24K), агрессивный рост

• ARRAY: На порядок ниже (до 131), умеренный рост

• Вывод: LEFT JOIN создает большую конкуренцию за ресурсы между процессами

3. wait_event_type = LWLOCK

• LEFT JOIN : Высокие значения (до 106), стабильный рост

• ARRAY: Более высокие максимальные значения (до 227), но плавный рост

• Вывод: ARRAY использует больше легковесных блокировок, но распределяет их лучше

4. wait_event_type = TIMEOUT

• LEFT JOIN : Значительное количество (до 19), указывает на ожидания

• ARRAY: Минимальные значения (до 5)

• Вывод: ARRAY меньше подвержен блокировкам и ожиданиям

Итог

Преимущества при использовании частичной агрегации :

• В 2-3 раза меньше нагрузка на IO и IPC

• Более стабильный профиль выполнения

• Меньше блокировок и ожиданий

• Лучшая масштабируемость при параллельной работе

Метрики iostat для дискового устройства, используемого файловой системой /data

Дисковая подсистема не участвует в ограничении производительности данных запросов.

Метрики vmstat

Сравнительный анализ ключевых метрик

Процессы (procs)

Параметр	LEFT JOIN	ARRAY
procs_r	4-9 (высокая очередь выполнения)	5-15 (умеренная очередь)
procs_b	1-2 (постоянно есть заблокированные процессы)	0-1 (минимальное блокирование)

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

Память

Параметр	LEFT JOIN	ARRAY
memory_swpd	203-217(использует swap)	204-237 (стабильное использование)
memory_free	179-182(низкая свободная память)	178-329 (больше свободной памяти)
memory_buff	10-147(нестабильные буферы)	3-124 (стабильные буферы)

Вывод: При использовании частичной агрегации эффективнее используется память, меньше обращений к swap.

Ввод-вывод

Параметр	LEFT JOIN	ARRAY
io_bi	42442-86819 (очень высокая активность чтения)	12455-34691 (в 2-3 раза меньше чтения)
io_bo	3474-7528(высокая активность записи)	3569-22387 (сопоставимая запись)

Вывод: При использовании частичной агрегации значительно снижается нагрузку на IO.

Системные события

Параметр	LEFT JOIN	ARRAY
system_in	10097-14285 (высокие прерывания)	6324-9509 (меньше прерываний)
system_cs	9511-13765 (частые переключения контекста)	1505-2586 (значительно меньше переключений)

Вывод: Использовании частичной агрегации создает меньше системной нагрузки.

Загрузка CPU

Параметр	LEFT JOIN	ARRAY
cpu_us	35-57% (умеренная пользовательская нагрузка)	59-95% (высокая пользовательская нагрузка)
cpu_sy	4-5% (низкая системная нагрузка)	2-4% (минимальная системная нагрузка)
cpu_id	17-47% (простой уменьшается со временем)	0-36% (эффективное использование CPU)
cpu_wa	10-17% (высокое ожидание IO)	0-3% (минимальное ожидание IO)

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

Итог

Использование частичной агрегации демонстрирует значительно лучшую эффективность использования системных ресурсов:

• Оптимизированное использование CPU - больше времени на полезную работу

• Сниженная нагрузка на IO - меньше операций чтения/записи

• Стабильное управление памятью - минимальное использование swap

• Эффективное планирование процессов - меньше блокировок и переключений

Производительность подтверждается на всех уровнях: от дисковой подсистемы до управления процессами, что объясняет его более быстрое выполнение по сравнению с базовым вариантом "LEFT JOIN".

Общий итог : Часть-3 "Частичная агрегация"

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

Производительность СУБД:

Среднее увеличение операционной скорости при использовании запроса "ARRAY" составило 120.15%

📊 Анализ эффективности выполнения запросов

Планы выполнения:

• Частичная агрегация использует современные возможности PostgreSQL: параллельные вычисления, кэширование Memoize, агрегацию через ARRAY_AGG

• Несмотря на более сложный план, демонстрируется лучшая производительность

Ожидания СУБД (Wait Events):

• Снижение нагрузку на IO в 2-3 раза

• Межпроцессное взаимодействие уменьшено на порядок (с 24K до 131)

• Меньше блокировок и таймаутов - более стабильная работа

💾 Использование системных ресурсов

Дисковая подсистема:

• Оба подхода эффективно используют кэширование в памяти

• Физический IO не является ограничивающим фактором

• Данные полностью помещаются в оперативной памяти

Процессор и память:

• Частичная агрегация эффективнее использует CPU (95% пользовательского времени против 57%)

• Снижено время ожидания IO с 17% до 3%

• Более стабильное управление памятью - меньше использования swap

Системные процессы:

• На 70-80% меньше переключений контекста 

• Минимальное количество заблокированных процессов

• Снижена системная нагрузка на прерывания и обработку

🎯 Ключевые факторы успеха использования частичной агрегация

1. Уменьшение объема обрабатываемой информации

2. Эффективное использование многоядерных систем

3. Cнижение нагрузки на подсистемы

4. Меньшая конкуренция за ресурсы

💡 Заключение

Метод частичной агрегации "ARRAY" демонстрирует кардинальное превосходство над традиционным JOIN-подходом в условиях высокой параллельной нагрузки. Оптимизированное использование вычислительных ресурсов, снижение конкуренции и эффективная работа с памятью делают этот подход предпочтительным для современных высоконагруженных систем.

---

Продолжение цикла "Анализ вариантов оптимизации ресурсоёмкого SQL-запроса"

Вариант-4: Использование временных таблиц

Вариант-5: Оптимизация с помощью условий в JOIN

Вариант-6: Пакетная обработка с LIMIT-OFFSET

Вариант-7: Использование покрывающих индексов

Вариант-8: Материализованное представление

Итог: сравнительный анализ вариантов оптимизации ресурсоемкого запроса