Предисловие

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

На конкретном примере двух альтернативных запросов к PostgreSQL мы продемонстрируем, как нейросеть, анализируя планы выполнения и стоимость запросов, сформировала убедительную, но абсолютно ложную гипотезу о 85-95% превосходстве одного плана над другим. Реальное нагрузочное тестирование при растущей параллельной нагрузке (от 5 до 22 соединений) показало совершенно иную картину, опровергающую все теоретические выкладки.

Эта статья — предостережение для DBA и разработчиков: аппроксимация результатов и анализ стоимости планов не могут заменить реальные эксперименты в условиях, приближенных к производственным. Нейросети остаются ценным инструментом, но не истиной в последней инстанции, когда дело касается производительности PostgreSQL под нагрузкой.

ℹ️ Новый инструмент с открытым исходным кодом для статистического анализа, нагрузочного тестирования и построения отчетов доступен в репозитории GitFlic и GitHub

PG_EXPECTO

pg_expecto

Вопрос нейросети

Необходимо сформировать и обосновать гипотезу о влиянии плана выполнения на производительность запроса в условиях параллельной нагрузки в ходе нагрузочного тестирования для СУБД PostgreSQL .

Дано: СУБД с ресурсами CPU=8, RAM=8GB , PostgreSQL 17.

Изменение нагрузки по итерациям:

1 итерация - 5 параллельных соединений

2 итерация - 8 параллельных соединений

3 итерация - 9 параллельных соединений

4 итерация - 10 параллельных соединений

5 итерация - 12 параллельных соединений

6 итерация - 13 параллельных соединений

7 итерация - 15 параллельных соединений

8 итерация - 18 параллельных соединений

9 итерация - 22 параллельных соединений.

Тестовый запрос №1

"

WITH seats_available AS

( SELECT airplane_code, fare_conditions, count( * ) AS seats_cnt

FROM bookings.seats

GROUP BY airplane_code, fare_conditions

), seats_booked AS

( SELECT flight_id, fare_conditions, count( * ) AS seats_cnt

FROM bookings.segments

GROUP BY flight_id, fare_conditions

), overbook AS (

SELECT f.flight_id, r.route_no, r.airplane_code, sb.fare_conditions,

sb.seats_cnt AS seats_booked,

sa.seats_cnt AS seats_available

FROM bookings.flights AS f

JOIN bookings.routes AS r ON r.route_no = f.route_no AND r.validity @> f.scheduled_departure

JOIN seats_booked AS sb ON sb.flight_id = f.flight_id

JOIN seats_available AS sa ON sa.airplane_code = r.airplane_code

AND sa.fare_conditions = sb.fare_conditions

WHERE sb.seats_cnt > sa.seats_cnt

)

SELECT count(*) overbookings,

CASE WHEN count(*) > 0 THEN 'ERROR: overbooking' ELSE 'Ok' END verdict

FROM overbook;

"
План выполнения тестового запроса №1

"

Aggregate (cost=9825.94..9825.95 rows=1 width=40) (actual time=262.702..262.707 rows=1 loops=1)

-> Hash Join (cost=9431.95..9825.94 rows=1 width=0) (actual time=262.696..262.701 rows=0 loops=1)

Hash Cond: ((f.route_no = r.route_no) AND (seats.airplane_code = r.airplane_code))

Join Filter: (r.validity @> f.scheduled_departure)

Rows Removed by Join Filter: 217

-> Nested Loop (cost=9407.50..9796.79 rows=567 width=19) (actual time=218.641..259.306 rows=11355 loops=1)

-> Hash Join (cost=9407.22..9623.25 rows=567 width=8) (actual time=218.539..235.320 rows=11355 loops=1)

Hash Cond: (segments.fare_conditions = seats.fare_conditions)

Join Filter: ((count(*)) > (count(*)))

Rows Removed by Join Filter: 66545

-> HashAggregate (cost=9366.21..9507.87 rows=14166 width=20) (actual time=217.266..219.770 rows=10888 loops=1)

Group Key: segments.flight_id, segments.fare_conditions

Batches: 1 Memory Usage: 1425kB

-> Seq Scan on segments (cost=0.00..6654.55 rows=361555 width=12) (actual time=0.071..90.350 rows=361489 loops=1)

-> Hash (cost=40.71..40.71 rows=24 width=20) (actual time=1.228..1.230 rows=20 loops=1)

Buckets: 1024 Batches: 1 Memory Usage: 10kB

-> HashAggregate (cost=40.47..40.71 rows=24 width=20) (actual time=1.205..1.211 rows=20 loops=1)

Group Key: seats.airplane_code, seats.fare_conditions

Batches: 1 Memory Usage: 24kB

-> Seq Scan on seats (cost=0.00..27.41 rows=1741 width=12) (actual time=0.059..0.420 rows=1741 loops=1)

-> Index Scan using flights_pkey on flights f (cost=0.28..0.31 rows=1 width=19) (actual time=0.002..0.002 rows=1 loops=11355)

Index Cond: (flight_id = segments.flight_id)

-> Hash (cost=15.78..15.78 rows=578 width=33) (actual time=0.631..0.632 rows=578 loops=1)

Buckets: 1024 Batches: 1 Memory Usage: 45kB

-> Seq Scan on routes r (cost=0.00..15.78 rows=578 width=33) (actual time=0.083..0.375 rows=578 loops=1)

Planning Time: 5.779 ms

Execution Time: 263.774 ms

"

Тестовый запрос №2

"

SELECT

COUNT(*) AS overbookings,

CASE WHEN COUNT(*) > 0 THEN 'ERROR: overbooking' ELSE 'Ok' END AS verdict

FROM (

SELECT

f.flight_id,

sb.fare_conditions,

sb.seats_cnt AS seats_booked,

(

SELECT COUNT(*)

FROM bookings.seats s

WHERE s.airplane_code = r.airplane_code

AND s.fare_conditions = sb.fare_conditions

) AS seats_available

FROM bookings.flights f

JOIN bookings.routes r ON r.route_no = f.route_no AND r.validity @> f.scheduled_departure

JOIN (

SELECT

flight_id,

fare_conditions,

COUNT(*) AS seats_cnt

FROM bookings.segments

GROUP BY flight_id, fare_conditions

) sb ON sb.flight_id = f.flight_id

WHERE sb.seats_cnt > (

SELECT COUNT(*)

FROM bookings.seats s

WHERE s.airplane_code = r.airplane_code

AND s.fare_conditions = sb.fare_conditions

)

) overbook;

"

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

"

Aggregate (cost=334506.18..334506.19 rows=1 width=40) (actual time=12894.579..12899.785 rows=1 loops=1)

CTE seats_agg

-> HashAggregate (cost=40.47..40.71 rows=24 width=20) (actual time=0.751..0.757 rows=20 loops=1)

Group Key: seats.airplane_code, seats.fare_conditions

Batches: 1 Memory Usage: 24kB

-> Seq Scan on seats (cost=0.00..27.41 rows=1741 width=12) (actual time=0.024..0.203 rows=1741 loops=1)

-> Hash Join (cost=326910.78..334463.31 rows=862 width=0) (actual time=12894.575..12899.777 rows=0 loops=1)

Hash Cond: (segments.flight_id = f.flight_id)

Join Filter: ((count(*)) > (SubPlan 2))

Rows Removed by Join Filter: 249660

-> Finalize HashAggregate (cost=315588.67..318101.77 rows=251310 width=20) (actual time=4473.982..4907.592 rows=249660 loops=1)

Group Key: segments.flight_id, segments.fare_conditions

Batches: 1 Memory Usage: 28177kB

-> Gather (cost=1000.44..308049.37 rows=1005240 width=20) (actual time=18.306..4125.482 rows=253416 loops=1)

Workers Planned: 4

Workers Launched: 4

-> Partial GroupAggregate (cost=0.44..206525.37 rows=251310 width=20) (actual time=0.606..4288.777 rows=50683 loops=5)

Group Key: segments.flight_id, segments.fare_conditions

-> Parallel Index Only Scan using idx_segments_flight_fare on segments (cost=0.44..167521.05 rows=4865495 width=12) (actual time=0.072..2456.531 rows=3892859 loops=5)

Heap Fetches: 271389

-> Hash (cost=11309.28..11309.28 rows=1026 width=8) (actual time=4365.785..4365.789 rows=99609 loops=1)

Buckets: 131072 (originally 2048) Batches: 1 (originally 1) Memory Usage: 4915kB

-> Nested Loop (cost=0.42..11309.28 rows=1026 width=8) (actual time=0.061..4277.802 rows=99609 loops=1)

-> Seq Scan on routes r (cost=0.00..148.02 rows=5502 width=33) (actual time=0.019..1.508 rows=5502 loops=1)

-> Index Scan using flights_route_no_scheduled_departure_key on flights f (cost=0.42..2.02 rows=1 width=19) (actual time=0.408..0.772 rows=18 loops=5502)

Index Cond: (route_no = r.route_no)

Filter: (r.validity @> scheduled_departure)

Rows Removed by Filter: 168

SubPlan 2

-> CTE Scan on seats_agg sa (cost=0.00..0.60 rows=1 width=8) (actual time=0.005..0.011 rows=1 loops=249660)

Filter: ((airplane_code = r.airplane_code) AND (fare_conditions = segments.fare_conditions))

Rows Removed by Filter: 19

Planning Time: 5.223 ms

Execution Time: 12929.075 ms

"

Сформулируй и обоснуй гипотезу - на сколько в процентном отношении будет отличатся производительность СУБД при использовании тестового запроса №2 по сравнению с использованием тестового запроса №1 ?

Ответ нейросети DeepSeek

На основании анализа планов выполнения и условий тестирования, сформулирую гипотезу о влиянии плана выполнения на производительность.

Гипотеза

Производительность тестового запроса №2 будет на 85-95% хуже (медленнее) по сравнению с тестовым запросом №1 в условиях параллельной нагрузки, причем этот разрыв будет увеличиваться с ростом количества соединений.

Обоснование гипотезы

1. Анализ планов выполнения

Запрос №1 (263.774 ms):

• Использует эффективные хэш-соединения

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

• Оптимальная работа с агрегациями

• Отсутствие параллельных операций, что снижает конкуренцию за ресурсы

Запрос №2 (12929.075 ms - в 49 раз медленнее):

• Использует дорогостоящие параллельные операции (Gather, Workers)

• Множественные вложенные циклы и подзапросы

• Высокая стоимость повторяющихся операций (SubPlan выполняется 249660 раз)

• Значительное использование памяти (Memory Usage: 28177kB)

2. Влияние параллельной нагрузки

С учетом ресурсов системы (CPU=8, RAM=8GB):

• При 5-8 соединениях: Запрос №2 будет значительно медленнее из-за дорогостоящих параллельных операций, но система еще не насыщена

• При 9-12 соединениях: Конкуренция за CPU усилится, параллельные операции в запросе №2 начнут конкурировать между собой и с другими сессиями

• При 13-22 соединениях: Система достигнет насыщения CPU, что катастрофически скажется на производительности запроса №2

3. Прогнозируемая динамика производительности

4. Критические факторы

1. Конкуренция за CPU: Параллельные операции в запросе №2 создают дополнительную нагрузку, которая усугубляется с ростом числа соединений

2. Использование памяти: Запрос №2 требует значительно больше памяти (28MB vs 1.4MB для агрегаций), что может привести к свопингу при высокой нагрузке

3. Блокировки ресурсов: Множественные вложенные операции увеличивают время удержания блокировок

4. Эффект каскадного замедления: При насыщении системы время выполнения запроса №2 будет расти непропорционально быстрее, чем у запроса №1

Заключение

Запрос №1 демонстрирует оптимальный план выполнения для условий высокой параллельной нагрузки, в то время как запрос №2 содержит ресурсоемкие операции, которые становятся "узким местом" при увеличении числа одновременных соединений. Разрыв в производительности будет составлять 85-95% в пользу запроса №1 и будет увеличиваться с ростом нагрузки на систему.

Ответ нейросети Ask Postgres

Для формирования и обоснования гипотезы о различии производительности между тестовым запросом №1 и тестовым запросом №2 при параллельной нагрузке, проанализируем предоставленные планы выполнения и их ключевые характеристики.

1. Сравнение производительности по данным выполнения

Из планов выполнения:

• Запрос №1:
  Execution Time = 263.774 ms

• Запрос №2:
  Execution Time = 12929.075 ms

Разница во времени выполнения:

\Delta T = 12929.075 - 263.774 = 12665.301 \text{ ms}

Процентное отличие производительности (как относительное замедление запроса №2 относительно запроса №1):

\text{Замедление (%)} = \left( \frac{12929.075}{263.774} - 1 \right) \times 100% \approx \left( 49.01 - 1 \right) \times 100% = 4801%

То есть запрос №2 выполняется в ~49 раз медленнее, чем запрос №1.

Гипотеза:
При использовании тестового запроса №2 производительность СУБД PostgreSQL 17 будет снижена на 4800–4900% по сравнению с запросом №1, даже при низкой нагрузке, и это замедление будет экспоненциально усиливаться при увеличении параллельных соединений из-за неэффективной структуры подзапросов и повторных сканирований.

2. Обоснование гипотезы

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

A. Запрос №1 — эффективная структура с предварительной агрегацией

• Использует CTE (seats_available, seats_booked, overbook) для однократного вычисления агрегированных данных.

• Все JOINs выполняются на предварительно сгруппированных наборах данных (10888 и 20 строк).

• Hash Join и Nested Loop работают с малыми наборами данных.

• Нет повторных подзапросов — все данные вычислены один раз и кэшированы в хеш-таблицах.

• Память используется эффективно: Batches = 1, Memory Usage < 2 MB.

B. Запрос №2 — катастрофически неэффективная структура

• Подзапрос в WHERE (WHERE sb.seats_cnt > (SELECT COUNT(*) FROM seats ...)) выполняется для каждой строки результата JOIN (249660 раз!).

• Подзапрос ссылается на CTE seats_agg, который, хотя и вычисляется один раз, сканируется 249660 раз через CTE Scan — это O(n×m) сложность.

• Параллелизм не помогает: хотя используется 5 рабочих процессов (Workers Launched: 4), они не могут компенсировать экспоненциальный рост числа операций.

• Повторное сканирование routes и flights в подзапросе — 5502 × 18 = 99609 строк, что уже само по себе тяжело, но усугубляется подзапросом.

• Память: 28 MB на группировку, 4.9 MB на хеш — но это не главное; главное — количество операций.

• Heap Fetches: 271389 — указывает на высокую стоимость Index Only Scan из-за неоптимального доступа к данным.

C. Масштабируемость при параллельной нагрузке

• Запрос №1: линейная масштабируемость. При увеличении соединений с 5 до 22 — время растёт умеренно, так как все данные уже агрегированы.

• Запрос №2: квадратичная/экспоненциальная масштабируемость.
  Каждое новое соединение увеличивает количество одновременных выполнений подзапроса.
  При 22 соединениях — 22 × 249660 = ~5.5 млн подзапросов.
  Это приведёт к: Переполнению shared_buffers
  Конкуренции за CPU и I/O
  Росту времени выполнения до > 100 секунд (экстраполяция)
  

Пример экстраполяции:
При 22 соединениях, если каждый запрос занимает 12.9 сек, то общее время выполнения в системе (если все параллельны) может достигать 22 × 12.9 = 284 секунды.
При запросе №1 — 22 × 0.26 = 5.7 секунд.

3. Количественная гипотеза

Гипотеза:
При увеличении параллельных соединений с 5 до 22, производительность СУБД PostgreSQL 17 при использовании запроса №2 будет снижена на 4800–4900% по сравнению с запросом №1, и это замедление будет усиливаться квадратично с ростом нагрузки.

Обоснование в процентах:

• Базовое замедление (при 1 соединении):
  $$ \frac{12929}{263.774} \approx 49.01 \Rightarrow \text{4801% замедление} $$

• При параллельной нагрузке (22 соединения):Запрос №1: ~5.7 сек (22 × 0.263)
  Запрос №2: ~284.4 сек (22 × 12.929)
  Отношение: $ \frac{284.4}{5.7} \approx 49.9 $ → 4890% замедление
  

Вывод:
Гипотеза подтверждается: запрос №2 демонстрирует 4800–4900% замедление по сравнению с запросом №1, и это различие будет сохраняться и усиливаться при росте параллельной нагрузки.

4. Рекомендация

Запрос №1 — оптимален.
Запрос №2 — следует переписать в стиле №1, убрав подзапросы в WHERE и используя JOIN с предварительно агрегированными CTE.
Использование подзапросов в условиях WHERE с агрегацией — антипаттерн в PostgreSQL, особенно при параллелизме.

Источники подтверждения

• [PostgreSQL Documentation: Performance Tips — Avoid Subqueries in WHERE]

• [Postgres Pro: Optimizing Complex Queries with CTEs and Joins]

• [Why NOT to use correlated subqueries in WHERE]

Итог:
Гипотеза: Запрос №2 будет работать в 48–49 раз медленнее, чем запрос №1 — это 4800–4900% замедление.
Это не артефакт, а фундаментальная архитектурная ошибка в построении запроса.

Результат эксперимента

Среднее снижение операционной скорости при использовании тестового запроса №2 составило 2.83%.

Почему гипотеза нейросети не подтверждается и почему нейросети нельзя использоваться для экспертизы реальной производительности СУБД PostgreSQL

1. Некорректная интерпретация планов выполнения

План выполнения показывает потенциальную производительность, а не реальную под нагрузкой:

• cost - это оценка оптимизатора, а не реальное время

• План строится для изолированного выполнения, без учета конкуренции за ресурсы

• Отсутствуют данные о реальном влиянии на подсистемы ввода-вывода

2. Игнорирование эффектов параллельной нагрузки

Критические факторы, не учтенные в гипотезе:

Конкуренция за ресурсы:

• При 22 соединениях на 8 CPU возникает очередь выполнения

• Parallel workers в запросе №2 конкурируют между собой

• Увеличивается время ожидания блокировок

Проблемы с памятью:

• Запрос №2 использует 28MB для агрегаций

• При множественных выполнениях возникает давление на shared_buffers

• Возможен вытеснение кэша

3. Методологическая ошибка - экстраполяция без валидации

Гипотеза экстраполировала данные:

• От единичного выполнения → к параллельному

• Без учета нелинейной деградации производительности

• Игнорировала точку насыщения системы

4. Реальные результаты эксперимента

Реальное тестирование показало:

• Минимальную разницу в производительности между запросами

• Оба запроса упираются в общие ограничения системы

• Параллельные операции не дают преимущества под нагрузкой

5. Системные ограничения доминируют над различиями запросов

При параллельной нагрузке:

• Латентность дисковой подсистемы становится определяющим фактором

• Нагрузка на CPU выравнивает время выполнения разных запросов

• Эффект от оптимизации нивелируется общей нагрузкой

Ключевой вывод

Разница в производительности между оптимизированными запросами становится статистически незначимой, когда система достигает предела своих ресурсов. Нейросеть не учла, что при высокой параллельной нагрузке система становится настолько "зажатой" ресурсными ограничениями, что тонкие различия в планах выполнения перестают влиять на общую производительность.

Это классический случай, когда теоретический анализ не учитывает реальное поведение сложной системы под нагрузкой.

в Китае внедрена технология круговых спортивных трансляций, которая позволяет зрителям поворачивать камеру на 360° и следить за игрой с любого ракурса.

Пока такая функция доступна для бадминтона и баскетбола, но в будущем её планируют распространить и на другие виды спорта.

Технология работает за счёт массива камер, установленных по всему периметру корта. Все они ведут трансляцию одновременно, а переключение между ракурсами происходит простым свайпом в приложении без задержек.

2wai: Connect With AI Avatars — приложение американского стартапа 2Wai, которое позволяет создавать ИИ-клоны умерших родственников и общаться с ними, словно по видеозвонку.

Чтобы создать ИИ-клона, нужно отсканировать фотографии родственника. Нейросети обработают фото и сделают из них 3D-модель, которая будет максимально похожа на реального человека. Затем пользователю предлагается настроить голос, характер, настроение и прочие особенности родственника, чтобы общение было приближено к реальному.

После настройки 3D-аватара пользователь сможет общаться с ним голосом или текстом. ИИ будет генерировать «дружелюбные и ласковые» ответы.

Разработчики говорят, что цель проекта — сохранить воспоминания об умерших родных людях.

В соцсетях к приложению относятся скептически. Многие считают, что 2Wai поступает неэтично, предлагая общение с чат-ботом под видом тёплых бесед с родственниками. Также пользователи считают неправильным предлагать такую услугу по платной подписке.

p.s некоторые считают, что такое общение с умершими может навредить психике. Что думаете ? Кстати, в 2013 году вышла серия «Чёрного зеркала» об этом — «Я скоро вернусь».

Предисловие

Нейросети для оптимизации баз данных часто предлагают математически верные, но практически проигрышные решения. В статье показано, как попытка применить покрывающий индекс (Index Only Scan) для таблицы с 1 миллионом строк и всего 685 уникальными значениями обернулась падением производительности на 7% под нагрузкой. Этот пример доказывает: для данных с низкой кардинальностью и высокой конкуренцией за ресурсы эффективность простых индексов или даже полного сканирования может быть выше. Все гипотезы, даже от ИИ, должны проходить экспериментальную проверку.

ℹ️ Новый инструмент с открытым исходным кодом для статистического анализа, нагрузочного тестирования и построения отчетов доступен в репозитории GitFlic и GitHub

PG_EXPECTO

pg_expecto

Тестовая таблица

CREATE TABLE pgbench_test

(

aid integer PRIMARY KEY ,

bid integer,

abalance integer,

filler character(84)

);

INSERT INTO pgbench_test ( aid , bid , abalance , filler )

SELECT

id ,

floor(random() * 685 ) + 1 ,

floor(random() * (68500000 - 1 + 1)) + 1 ,

md5(random()::text)

FROM generate_series(1,1000000) id;

Индекс

CREATE INDEX pgbench_test_idx ON pgbench_test ( bid );

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

select test.abalance

into test_rec

from pgbench_accounts acc

join pgbench_test test on (test.bid = acc.bid )

where acc.aid = current_aid ;

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

Nested Loop (cost=14.51..1546.55 rows=1460 width=4) (actual time=0.894..366.050 rows=1468 loops=1)

-> Index Scan using pgbench_accounts_pkey on pgbench_accounts acc (cost=0.57..2.79 rows=1 width=4) (actual time=0.217..0.227 rows=1 loops=1)

Index Cond: (aid = 51440641)

-> Bitmap Heap Scan on pgbench_test test (cost=13.94..1529.17 rows=1460 width=8) (actual time=0.669..365.312 rows=1468 loops=1)

Recheck Cond: (bid = acc.bid)

Heap Blocks: exact=1407

-> Bitmap Index Scan on pgbench_test_idx (cost=0.00..13.57 rows=1460 width=0) (actual time=0.355..0.356 rows=1468 loops=1)

Index Cond: (bid = acc.bid)

Planning Time: 2.634 ms

Execution Time: 366.419 ms

ℹ️ Метод доступа = Bitmap Index Scan on pgbench_test_idx

Рекомендация нейросети DeepSeek

Покрывающий индекс

CREATE INDEX CONCURRENTLY idx_pgbench_test_bid_abalance ON pgbench_test(bid) INCLUDE (abalance);

Новый план выполнения тестового запроса

Nested Loop (cost=0.99..48.86 rows=1460 width=4) (actual time=0.771..1.186 rows=1432 loops=1)

-> Index Scan using pgbench_accounts_pkey on pgbench_accounts acc (cost=0.57..2.79 rows=1 width=4) (actual time=0.736..0.737 rows=1 loops=1)

Index Cond: (aid = 51440641)

-> Index Only Scan using idx_pgbench_test_bid_abalance on pgbench_test test (cost=0.42..31.47 rows=1460 width=8) (actual time=0.029..0.289 rows=1432 loops=1)

Index Cond: (bid = acc.bid)

Heap Fetches: 0

Planning Time: 4.949 ms

Execution Time: 1.302 ms

(8 rows)

💥Стоимость плана выполнения = 48.86

💥Снижение стоимости плана выполнения 96%

ℹ️ Метод доступа = Index Only Scan using idx_pgbench_test_bid_abalance

Сравнение операционной скорости в Эксперимент-2(обычный индекс) и Эксперимент-3(покрывающий индекс)

Результаты

1. До нагрузки 15 соединений производительность СУБД при использовании покрывающего индекса(эксперимент-3) ниже производительности СУБД с использованием простого индекса (эксперимент-2) в среднем на 7%.

2. С ростом нагрузки после 15 соединений производительность СУБД при использовании покрывающего индекса(эксперимент-3) выше производительности СУБД с использованием простого индекса (эксперимент-2) в среднем на 22%.

Причины снижения производительности при использовании покрывающего индекса в эксперименте-3

1. Конкуренция за ресурсы блокировок

Покрывающий индекс значительно больше по размеру, чем простой индекс на bid

При Index Only Scan требуется проверка visibility map для каждого блока индекса

В условиях конкурентного доступа возникают блокировки на уровне:

• Буферного кэша

• Страниц индекса

• Visibility map

2. Проблемы с Visibility Map

При конкурентном доступе PostgreSQL должен постоянно обновлять visibility map

До 15 сессий конкуренция за обновление visibility map создает дополнительную нагрузку

В эксперименте-2 Bitmap Heap Scan менее чувствителен к актуальности visibility map

3. Эффект "теплого" кэша

В эксперименте-2 данные распределены между:

• Индексными страницами (меньший размер)

• Страницами таблицы

Это позволяет лучше использовать параллелизм на уровне кэша

В эксперименте-3 все данные сосредоточены в одном большом индексе, что создает "горячие точки" доступа

4. Статистика планировщика

Planning Time: 2.634 ms  -- эксперимент-2

Planning Time: 4.949 ms  -- эксперимент-3 (на 88% больше!)

Усложнение индекса требует больше времени на планирование

При множественных параллельных сессиях это накладные расходы суммируются.

5. Пороговый эффект

До 15 сессий:

• Накладные расходы на поддержание покрывающего индекса превышают выгоду

• Конкуренция за visibility map доминирует

После 15 сессий:

• Выгода от исключения обращений к heap перевешивает накладные расходы

• Система достигает точки безубыточности

6. Сравнение планов выполнения

✅ Вывод по одиночному запросу:

Эксперимент-3 в 280 раз быстрее - покрывающий индекс работает идеально для одного запроса.

Расчёт кардинальности для таблицы 'pgbench_test' по столбцу bid

pgbench_db=# select attname , n_distinct from pg_stats where tablename = 'pgbench_test' and attname ='bid' ;

attname | n_distinct

---------+------------

bid  |  685

(1 row)

pgbench_db=# select reltuples from pg_class where relname = 'pgbench_test';

reltuples

-----------

1e+06

(1 row)

⚠️Выводы:

1. При низкой и средней нагрузке накладные расходы на поддержание сложной структуры данных могут перевешивать ее преимущества.

2. Покрывающие индексы полезны при высокой кардинальности и редких запросах — не при низкой кардинальности и высокой параллельности.

3. Иногда "оптимизация" — это деградация.

⚠️Снижение стоимости запроса — это полезный индикатор потенциального улучшения производительности в рамках неизменной среды выполнения, но он не является ни необходимым (производительность можно повысить "мимо" планировщика), ни достаточным (планировщик может ошибаться) условием.

Операционная система Android уже более 16 лет на рынке смартфонов. Ее версии каждый год сменяются одна за другой, и простому пользователю трудно уследить за ними и понять: а что нового добавили в этот раз? С чего все начиналось, и как продукт Google проходил свой тернистый путь от очередного конкурента Symbian до самой распространенной в мире мобильной ОС.

История появления

Еще в 2003 году, во время бурного развития кнопочных телефонов, программист Энди Рубин и его приятели зарегистрировали компанию Android Inc. Она занялась разработкой новой операционной системы для смартфонов. Но к тому времени стали широко распространяться смартфоны на ОС Symbian, поэтому выпустить что-то реально конкурирующее с ней было трудно. Спустя два года разработки у команды Энди попросту кончились средства, без которых продолжить дальнейшую работу было невозможно.

В 2005 компанией Android Inc. неожиданно заинтересовалась мегакорпорация Google, которая выкупила ее у владельцев за 50 миллионов долларов. 5 ноября 2007 года Google сообщила о создании мобильной платформы Android, обладающей открытым исходным кодом. Именно эту дату принято считать днем рождения Android, хотя первое устройство на данной ОС появились на год позже — лишь в конце 2008-го.

Чтобы обозначать версии системы не только цифрами, Google решила использовать последовательность букв латинского алфавита. Первые разработки получили кодовые названия Astro Boy и Bender — в честь роботов из аниме Астробой и мультсериала Футурама. Однако из-за проблем с авторскими правами компания вынуждена была отказаться от использования имен персонажей. С третьей версии системы, именованной Cupcake, пошла традиция использовать в качестве кодовых «сладкие» названия. Сохранилась она и до сих пор.

Изначально Android не поражал воображение своими возможностями. Особенно по сравнению с самой популярной мобильной ОС того времени — Symbian. Да и появившаяся чуть раньше iPhone OS (iOS в девичестве) выглядела во многом интереснее. Но разработчики не тратили время зря, и со временем вводили в систему все новые и новые возможности, попутно избавляя ее от багов и недоработок.

Android 1.x (2008-2009)

В сентябре 2008 года Google анонсировала первый смартфон на новой операционной системе — T-Mobile G1. Он предназначался для американского рынка и было разработано совместно с компанией HTC. Устройство с Android 1.0 предлагало пользователю магазин приложений Android Market, несколько домашних экранов, произвольное размещение папок и ярлыков на главном экране (которое у iOS появилось только недавно), уведомления, мультизадачность и поддержку графического API OpenGL ES 1.1.

Международная версия смартфона под названием HTC Dream изначально поставлялась с Android 1.1, выпущенной 9 февраля 2009 года. Она содержала в себе множество мелких улучшений и исправлений.

27 апреля, всего два месяца спустя, был выпущен Android 1.5. Именно с этой версии ОС стала доступна и другим производителям, помимо HTC. Она принесла с собой много привычных вещей, без которых и сегодня использование смартфона немыслимо: таких, как поворот экрана, запись видео, папки для ярлыков приложений и виджеты. И, что самое главное — поддержку виртуальных клавиатур. В первых версиях системы эта функция отсутствовала, и в обязательном порядке нужно было использовать физическую клавиатуру устройства.

Через полгода, 15 сентября, свет увидела новая версия Android — 1.6. В ней сняли ограничение экрана в 320 точек по ширине и 480 по высоте. Теперь устройства могли оснащаться качественными панелями с разрешением до 800х480. Была улучшена работа с Play Market, где стало появляться все больше и больше разнообразных сторонних приложений. Система получила доработки для галереи и интерфейса камеры, позволяя более удобно и интуитивно управлять ими.

Android 2.x (2009-2010)

Первое «большое» обновление Android 2.0 было выпущено 26 октября 2009 года. Оно принесло поддержку HTML5 в браузере, новые функции графического ускорения интерфейса и большое количество мелких доработок. Именно распространение «второго» Андроида в начале 2010 года ознаменовало собой начало заката устройств на конкурентных Symbian и Windows Mobile. С этого момента началось постепенное становление «зеленого робота» в качестве самой распространенной мобильной операционной системы.

В Android 2.1, выпущенный 12 января 2010 года, была внедрена поддержка «живых» обоев. Это было красиво и необычно для мобильных устройств того времени. Однако такие обои значительно сокращали время работы из-за усиленного расхода аккумулятора.

Android 2.2 увидел свет 20 мая того же года. Несмотря на «некруглую» цифру, он стал достаточно крупным обновлением. Разработчиками была произведена большая оптимизация производительности и потребляемой ОС памяти, вследствие чего была ускорена работа программ и повышена плавность интерфейса. Добавилась поддержка HD-экранов с разрешением до 1280 точек по большей стороне, а также возможность использовать смартфон как точку доступа Wi-Fi или USB-модем. Система получила поддержку API OpenGL ES 2.0, что значительно расширило возможности графики для новых игр.

6 декабря 2010 года был представлен Android 2.3. Если в прошлом обновлении сосредоточились на повышении производительности, то в этом — на оптимизации расхода батареи и улучшении времени автономной работы. Появилась поддержка модулей NFC, нескольких камер, интернет-телефонии, а также новых датчиков — барометра и гироскопа.

Android 3.x–4.x (2011–2013)

Android 3.0, представленный 22 февраля 2011 года, стал специальным ответвлением ОС для планшетов. Исходный код системы Google, впервые за всю ее историю, решила не публиковать. В числе изменений была оптимизация работы с экранами высокого разрешения, улучшенная многозадачность, поддержка внешних устройств ввода — клавиатур и мышей.

Все эти новшества перекочевали в Android 4.0, который появился уже через несколько месяцев — 19 октября. С его выходом в свет Google признала эксперимент с делением ОС на категории устройств неудачным, вновь вернувшись к универсальному решению, подходящему и для смартфонов, и для планшетов.

Четвертая версия системы стала новой во всех смыслах этого слова. Изменения коснулись как ее внешнего вида, так и внутреннего устройства. Новый доработанный интерфейс стал более интуитивным, предлагая заметно больше возможностей. Внутренние улучшения коснулись переработанной многозадачности, новых функций для работы с камерой, поддержки Wi-Fi Direct и множества других мелких доработок.

27 июня 2012 года был выпущен Android 4.1. Так с четвертой версии система стала требовательнее к оборудованию, в обновлении внедрили новую технологию интерфейса под названием Project Butter. Она основана на работе вертикальной синхронизации с тройной буферизацией, благодаря которой ОС стала работать намного плавнее. Для планшетов были внедрен новый интерфейс, более соответствующий концепции единой версии ОС для всех устройств.

С Android 4.2, увидевшего свет 29 октября, стало доступно новое удобство — использование профилей пользователей. Теперь можно было отдать устройство в пользование другому человеку, просто сменив учетную запись профиля — аналогично системе пользователей у десктопной ОС Windows.

24 июля 2013 года был представлен Android 4.3. Его главным новшеством стала поддержка API OpenGL ES 3.0, благодаря которому на ОС теперь могли появиться более красивые и графически продвинутые игры.

Завершающим этапом для четвертой версии системы стал Android 4.4, отмечающий день рождения 31 октября того же года. Именно в этой ОС появилась знаменитая голосовая команда «ОК, Google», позволяющая задать смартфону выполнение каких-то несложных действий — например, поиск информации в интернете, воспроизведение музыки или отправку электронной почты.

Android 5.x–7.x (2014–2016)

Очередная страница в истории системы открылась 3 ноября 2014 года. Android 5 принес с собой новый переработанный интерфейс Material Design, целью которого стало сделать взаимодействия пользователя с устройством более простым и удобным. Несмотря на то, что на момент появления пятой версии ОС большинство смартфонных процессоров были 32-битными, в ней впервые появилась поддержка 64-битных вычислений.

Запуск приложений и переключение между ними ускорилось, а потребление оперативной памяти снизилось. Все это — благодаря новой среде выполнения Android Runtime (ART). Она появилась в Android 4.4 в качестве опциональной, но лишь в пятой версии ОС стала основной. С ART приложения во время установки распаковываются единожды, тогда как с ее предшественницей Dalvik приходилось делать это при каждом их запуске.

28 мая 2015 года был выпущен Android 6. Впервые за историю ОС новый номер означал не основательно переработанную версию системы, а всего лишь небольшой апдейт. Такая схема сохранилась и по сегодняшний день.

Шестая версия получила расширенный контроль над правами приложений. Она могла обеспечить дополнительную экономию энергии благодаря функции Doze — активации глубокого спящего режима при отсутствии движения устройства. Появилась поддержка системы электронных платежей Android Pay (сейчас она называется Google Pay) и поддержка сканеров отпечатков пальцев на уровне платформы — ранее она ложилась на плечи производителей устройств.

Android 7 увидел свет 22 августа 2016 года. В числе новшеств — разделение экрана для одновременной работы с двумя приложениями, фоновое переключение задач, поддержка режима «картинка в картинке, функций виртуальной реальности и ярлыков действий для приложений. Также появилась поддержка графического API Vulkan 1.0 — преемника «взрослого» OpenGL и мобильного OpenGL ES, способного расширить возможности графики для смартфонов до уровня компьютеров и консолей.

Android 8.x–11.x (2017–2020)

В Android 8, который был представлен ровно через год, Google заметно обновила интерфейс. Изменился дизайн уведомлений, появились динамические иконки и значки событий на них. В систему был добавлен API нейронных сетей, который позволяет использовать вычислительные мощности смартфонных процессоров для улучшения фото- и видеосъемки. Одновременно появилось и ответвление Android Go — упрощенная оптимизированная версия ОС, предназначенная для бюджетных смартфонов с малым объемом оперативной памяти.

Android 9 появился 6 августа 2018 года. В нем добавили адаптацию интерфейса под экраны с различными вырезами, оптимизировали производительность системы, а также научили ОС распознавать редко используемые приложения и отзывать у них разрешения. Обновленная система научилась работать с Vulkan 1.1.

Юбилейная десятая версия Android была выпущена 3 сентября 2019 года. Для нее добавили поддержку смартфонов-раскладушек, переработали систему уведомлений и расширили поддержку кастомизации интерфейса с помощью тем, значков и шрифтов.

Очередным небольшим обновлением 8 сентября 2020 года стал Android 11. Ключевое изменение –совместимость с мобильными сетями 5G. Также была улучшена поддержка «раскладушек» и нейронных сетей.

Android 12.x–15.x (2021–2024)

4 октября 2021 года Google запускает очередную версию ОС Android — 12. Система заметно «похорошела» благодаря новой концепции интерфейса Material You. Теперь цветовая гамма для системных меню и приложений создается с учетом цветов обоев, что позволяет организовать единое пользовательское пространство без резких перепадов цветов. Вдобавок к этому были доработаны значки и внесены изменения в системную анимацию, благодаря чему она стала более плавной и естественной. Также был усилен контроль за фоновыми приложениями – теперь заряд должен расходоваться чуть экономнее.

Финальная версия Android 13 появилась уже через несколько месяцев, 15 августа 2022 года. Отправка уведомлений стала одним из разрешений, которое теперь выключено по умолчанию. Благодаря этому избавиться от назойливых уведомлений стало намного проще. Появилась возможность ограничивать взаимодействие приложений и файловой системы: вместо доступа ко всему накопителю теперь можно выбрать только определенные файлы. А языковые настройки теперь можно менять для каждого приложения отдельно.

4 октября 2023 года миру был представлен Android 14. В нем была улучшена персонализация экрана блокировки, расширены возможности использования нескольких профилей, а также в очередной раз проделана работа по оптимизации энергопотребления приложений в фоне. С этой версии Google отказалась от нативной поддержки 32-битных вычислений: теперь любая программа для работы должна иметь 64-разрядную версию, а установка приложений для Android 5.1 и более старых запрещена.

Android 15 был выпущен 3 сентября 2024 года. Появился мониторинг износа аккумулятора — теперь его состояние можно узнать, не прибегая к специальным программам. Новая функция «Private Space» позволяет создать секретный профиль, приложения и данные из которого надежно «спрятаны» и не попадут в основной аккаунт. Для экономии места можно задействовать архивацию приложений — для этого они будут удалены, но при повторном скачивании все их данные будут восстановлены до состояния при последнем запуске. К тому же, появилась возможность менять голосовой помощник по умолчанию: заметное удобство для тех, кому не нравится Google Ассистент.

Заключение

Опытные пользователи, пользующиеся смартфонами Android с ее первых выпусков, насчет списка новшеств в современных версиях ОС наверняка скажут «Да разве это изменения!». И будут правы. Действительно, в последние годы почти все нововведения в системе сосредоточены вокруг внешнего вида и мелких доработок. Но это говорит в первую очередь о том, что Android достиг своей зрелости. Его первые версии обрастали необходимым функционалом и внутренними изменениями с каждым новым выпуском. Однако уже после Android 5 бурный рост закончился, и в ход пошла более тонкая работа по мелким улучшениям и ежегодной актуализации системы.

С одной стороны, медленный «рост» системе сейчас даже в плюс. До сих пор можно пользоваться старыми версиями от Android 6 и выше — большинство приложений пишется с учетом именно шестой версии как минимальной. С другой стороны, в последнее время Google все настоятельнее рекомендует разработчиками создавать их как минимум для Android 8.

Компания начала «закручивать гайки» с появлением Android 14. Конечно же в первую очередь для того, чтобы сократить актуальный парк версий ОС и стимулировать пользователей покупать новые смартфоны. Но, если посмотреть на календарь, то поддержку восьмой версии системы получили многие смартфоны даже 2016 года выпуска — а это целых восемь лет назад. При этом Android, в отличие от конкурентной iOS, не ограничен единственным источником приложений в виде встроенного магазина. Поэтому даже устройствами на Android 5 вполне можно пользоваться — если, конечно, они до сих пор «живы» и для плавной работы им хватает производительности.

Чего ждать от обновленной версии популярной мобильной системы в 2025 году? Android 16 обещает принести с собой доработанную функцию изменения частоты экрана, которая будет подстраиваться под приложения, расширенные возможности вибрации для различных игр и приложений, а также одновременную передачу звука по Bluetooth на несколько устройств.

Утечки говорят, что новая ОС в этот раз появится уже в мае. Но до этого времени Google еще не раз доработает свое детище, добавив в него очередные улучшения — пусть не фундаментальные, но все-таки полезные и приятные. Система старается не отставать от современности, и постоянно предлагает пользователям что-то новое, при этом оставаясь открытой, гибкой и настраиваемой с учетом пожеланий владельца гаджета. Именно благодаря этому Android год за годом остается выбором миллионов пользователей во всем мире и самой популярной мобильной ОС.

Некоторые характеристики:

вес основного модуля — 70 кг, объём — 0,468 кубических метров;

грузоподъёмность — 200 кг, максимальный взлётный вес — 270 кг;

скорость полёта — 160 км/ч;

высота полёта — более 6000 метров;

дальность полёта — от 40 минут до 8 часов, в зависимости от конфигурации;

для взлёта достаточно площади 3×3 метра.

Janus-1 может использоваться в разных целях, включая личные поездки, грузовые перевозки, экстренную медицинскую помощь, аэрофотосъёмку и поисково-спасательные работы.

Вертолёт оснащён двигателем, который работает на дизельном топливе, керосине или реактивном топливе Jet A.

p.s Janus-1 уже доступен для коммерческого использования, цена полностью собранного аппарата — 249 800 долларов США, комплекта для самостоятельной сборки — 219 800 долларов США (без учёта доставки). 17.8 млн рублей.

Добавляем в вишлист к Новому Году

Хотели бы такой ? Признавайтесь