Горячее
Лучшее
Свежее
Подписки
Сообщества
Блоги
Эксперты
0 просмотренных постов скрыто
1

Оптимизация пагинации в PostgreSQL: Как настройка work_mem превратила ROW_NUMBER в лидера производительности⁠⁠

Взято с основного технического канала Postgres DBA (возможны правки в исходной статье).

Память решает: как ROW_NUMBER обогнал Deferred Join

Память решает: как ROW_NUMBER обогнал Deferred Join

Предисловие

В мире высоконагруженных баз данных выбор метода пагинации может стать решающим фактором для производительности системы. Эксперимент, проведённый с двумя подходами — классическим ROW_NUMBER и отложенным соединением (Deferred Join) — показал, что даже архитектурно более совершенный метод не гарантирует победы без тонкой настройки СУБД. Исследование раскрывает, как правильная конфигурация памяти PostgreSQL перевесила преимущества Deferred Join и позволила ROW_NUMBER добиться превосходства на параллельной нагрузке до 22 сессий.

Начало экспериментов с методом пагинации ROW_NUMBER

Прогноз нейросети

Вопрос

Используя информацию о размерах таблиц, схеме баз данных и тестовых запросах, дай прогноз и обоснование - какой тестовый запрос покажет большую производительность для нагрузочного тестирования с параллельной нагрузкой от 5 до 22 сессий для СУБД PostgreSQL 17 c ресурсами CPU=8 RAM=8GB

Прогноз:
Наибольшую производительность при параллельной нагрузке (5–22 сессии) покажет запрос plan-1 (ROW_NUMBER()) после оптимизации индексами.

Экспериментальная проверка

Анализ ситуации нейросетью

Почему не оправдался прогноз нейросети о большей эффективности метода ROW_NUMBER для заданных условий ?

5. Условия, при которых ROW_NUMBER() действительно был бы эффективнее:

Сценарий 2: Адекватный размер work_mem

Если бы work_mem был ≥ 256MB для сортировки в памяти

какие значение work_mem необходимо установить для получения преимущества метода row_number при максимальной нагрузке 22 параллельные сессии при общем размере RAM=8GB ?

-- Для получения преимущества ROW_NUMBER():
SET work_mem = '180MB';
SET max_parallel_workers_per_gather = 1;
SET max_parallel_workers = 16;

-- В postgresql.conf:
work_mem = 180MB
max_parallel_workers_per_gather = 1
max_parallel_workers = 16
max_worker_processes = 16
shared_buffers = 2GB
effective_cache_size = 6GB

Задача

Экспериментальная проверка рекомендации нейросети по оптимизации метода пагинации ROW_NUMBER

Изменение конфигурационных параметров СУБД

ALTER SYSTEM SET work_mem = '180MB';

ALTER SYSTEM SET max_parallel_workers_per_gather = 1;

ALTER SYSTEM SET max_parallel_workers = 16;

ALTER SYSTEM SET max_worker_processes = 16 ;

ALTER SYSTEM SET shared_buffers = '2GB';

ALTER SYSTEM effective_cache_size = '6GB';

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

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

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

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

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

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

Результат

Среднее превышение операционной скорости , при использовании метода ROW_NUMBER составило 12.59%

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

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

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

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

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

Результат

Среднее снижение ожиданий СУБД, при использовании метода ROW_NUMBER составило 18.06%

Характерные особенности тестовых запросов и планов выполнения

1. Общая цель запросов

Оба запроса решают задачу случайной пагинации (выбор случайной "страницы" из 100 строк) для отфильтрованных данных (билеты с бизнес-классом).

2. Основные различия в подходах

Первый запрос (ROW_NUMBER()):

  • Использует оконную функцию ROW_NUMBER() для нумерации всех строк

  • Фильтрует по диапазону номеров строк после нумерации

  • Ключевая проблема: Выполняет полную сортировку и нумерацию всех 2.15 млн строк

Второй запрос (Deferred Join):

  • Использует отложенное соединение (deferred join)

  • Сначала выбирает только ticket_no с помощью OFFSET/LIMIT

  • Затем соединяет остальные данные по отобранным ключам

  • Преимущество: Сортирует только ключи, а не все данные

3. Производительность

Первый запрос:

  • Время выполнения: 12.65 секунд

  • Основные затраты:
    Merge Semi Join: 9.3 секунды
    Сортировка 2.15 млн строк: 850-1000 мс (quicksort, 170 МБ памяти)
    WindowAgg (оконная функция): 1723 мс

Второй запрос:

  • Время выполнения: ~16.1 секунды (неполные данные в выводе)

  • Основные затраты:
    Merge Semi Join: 8.75 секунды
    Сортировка для OFFSET: 5.5 секунды (top-N heapsort, 15 МБ памяти)
    Hash Join: 5575 мс

4. Критические различия в планах

Сортировка:

  1. Первый запрос: Сортирует все столбцы (ticket_no, book_ref, passenger_name) - 92 байта на строку

  2. Второй запрос: Сортирует только ticket_no - 32 байта на строку

Использование памяти:

  1. Первый: 170 МБ для сортировки всех данных

  2. Второй: 15 МБ для сортировки только ключей

Фильтрация:

  1. Первый: Сначала нумерует все строки, затем фильтрует 100

  2. Второй: Сначала выбирает 100 ключей, затем соединяет данные

5. Проблемы обоих подходов

  1. Общая проблема: floor(random() * COUNT(*)/100) требует полного сканирования для подсчета строк

  2. Производительность OFFSET: Во втором запросе OFFSET должен "пропустить" много строк (случайная страница * 100)

6. Рекомендации

Для оптимизации:

  1. Второй подход лучше архитектурно (deferred join), но в данном случае медленнее из-за:
    Необходимости вычислять OFFSET
    Hash Join вместо более эффективного соединения

  2. Потенциальные улучшения:
    Использовать keyset pagination вместо OFFSET
    Кэшировать общее количество строк
    Рассмотреть материализованные представления для filtered_tickets

В текущей реализации:

  • Первый запрос быстрее (12.65с vs ~16.1с), но использует больше памяти

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

7. Вывод

Оба запроса имеют проблемы с производительностью из-за необходимости обработки всех 2.15 млн строк для случайной выборки. Deferred Join (второй подход) - более правильная архитектурная паттерн, но требует оптимизации OFFSET и соединения для повышения эффективности в данном конкретном случае.

Характерные особенности производительности СУБД

1. Производительность (SPEED)

ROW_NUMBER подход:

  • Начальная производительность: 60

  • Стабильная после 45 итерации: 96

  • Максимум: 96 (после адаптации)

  • Прирост: 60 → 96 (+60%)

Deferred Join подход:

  • Начальная производительность: 52

  • Стабильная после 55 итерации: 84

  • Максимум: 84

  • Прирост: 52 → 84 (+61.5%)

Вывод: ROW_NUMBER показывает на 14.3% выше абсолютную производительность (96 vs 84).

2. Динамика адаптации

ROW_NUMBER:

  • Быстрый рост до 96 за 55 итераций

  • Более резкие скачки производительности

  • Ранняя стабилизация (с 55 итерации)

Deferred Join:

  • Более плавный рост до 84

  • Дольше адаптируется (до 55 итерации)

  • Стабильнее на низких нагрузках

3. Ожидания и блокировки

ROW_NUMBER:

  • TIMEOUT появляются с итерации 46 (при нагрузке 10 соединений)

  • LWLOCK стабилизируются на уровне 3-6

  • WAITINGS: 4-7

Deferred Join:

  • IO ожидания появляются с итерации 73 (при нагрузке 15+ соединений)

  • LWLOCK: 4-8 (выше, чем у ROW_NUMBER)

  • WAITINGS: до 21 пикового значения

  • Более выраженные скачки в ожиданиях (74 итерация: 21 ожидание)

4. Корреляция с нагрузкой

  • Нагрузка растет от 5 до 22 соединений

  • Критические точки:
    10 соединений (итерация 46): ROW_NUMBER начинает показывать TIMEOUT
    15 соединений (итерация 73): Deferred Join показывает IO ожидания
    18+ соединений: оба подхода стабилизируются на максимальных значениях ожиданий

5. Ключевые различия в поведении

ROW_NUMBER:

  1. Выше пиковая производительность (96 vs 84)

  2. Раннее появление TIMEOUT (с 10 соединений)

  3. Меньше LWLOCK в среднем (3-6 vs 4-8)

  4. Более предсказуемые паттерны ожиданий

Deferred Join:

  1. Лучше масштабируется при низких нагрузках

  2. Более стабильные WAITINGS (кроме пиков)

  3. Появление IO ожиданий вместо TIMEOUT

  4. Сильнее страдает от LWLOCK

6. Анализ проблемных точек

ROW_NUMBER:

  • Проблема: TIMEOUT при 10+ соединениях

  • Причина: WindowAgg + сортировка больших данных конкурируют за ресурсы

  • Симптом: Конкуренция за CPU/память

Deferred Join:

  • Проблема: IO ожидания при 15+ соединениях

  • Причина: Hash Join + сортировка для OFFSET требуют disk I/O

  • Симптом: Конкуренция за disk I/O и LWLOCK

7. Рекомендации по оптимизации

Для ROW_NUMBER:

  1. Увеличить work_mem для уменьшения disk spills

  2. Рассмотреть материализованные представления для filtered_tickets

  3. Кэшировать COUNT(*) для random_page

Для Deferred Join:

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

  2. Увеличить shared_buffers для кэширования hash таблиц

  3. Рассмотреть использование keyset pagination вместо OFFSET

8. Общий вывод

  1. ROW_NUMBER лучше для:
    Максимальной производительности (14.3% выше)
    Систем с достаточными CPU/памятью
    Сценариев с <10 конкурентных соединений

  2. Deferred Join лучше для:
    Систем с ограничениями по памяти
    Сценариев с предсказуемыми IO паттернами
    Приложений, чувствительных к TIMEOUT

  3. Оба подхода требуют оптимизации при >10 конкурентных соединений

  4. Критическая нагрузка: 10-15 соединений (точка деградации производительности)

Метрики производительности инфраструктуры

1. Использование CPU

ROW_NUMBER:

  • Начало: 61% user, 3% system, 36% idle

  • Критическая точка (итерация 50): резкий переход на 95-96% user, 4% system, 0% idle

  • Стабильная нагрузка: 96% user, 4% system, 0% idle

  • Вывод: Полная загрузка CPU с преобладанием пользовательского времени

Deferred Join:

  • Начало: 61% user, 2% system, 36% idle

  • Критическая точка (итерация 52): переход на 97% user, 3% system, 0% idle

  • Стабильная нагрузка: 97% user, 3% system, 0% idle

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

Сравнение: Deferred Join показывает на 1% выше user CPU и на 1% ниже system CPU.

2. Использование памяти

ROW_NUMBER:

  • Свободная память: 1791 → 2753 KB (+53% рост)

  • Буферы: 47 → 6 KB (-87% снижение)

  • Кэш: 4955 → 2751 KB (-44% снижение)

  • Своп: 70 → 67 KB (минимальное изменение)

  • Вывод: Активное использование кэша и буферов

Deferred Join:

  • Свободная память: 4567 → 2207 KB (-51% снижение)

  • Буферы: 18 → 6 KB (-67% снижение)

  • Кэш: 2211 → 2728 KB (+23% рост)

  • Своп: 69 → 73 KB (незначительный рост)

  • Вывод: Увеличение использования кэша, снижение свободной памяти

Сравнение: ROW_NUMBER активнее использует кэш в начале, Deferred Join наращивает кэш в процессе.

3. Ввод-вывод (IO)

ROW_NUMBER:

  • io_bo: 52 → 58 (+11.5% рост)

  • Пиковые значения: до 59

  • Вывод: Умеренный рост IO при увеличении нагрузки

Deferred Join:

  • io_bo: 59 → 65 (+10% рост)

  • Пиковые значения: до 68

  • Вывод: Более высокий базовый уровень IO

Сравнение: Deferred Join имеет на 10-15% выше активность IO, что соответствует ожиданиям из предыдущего анализа (IO ожидания).

4. Системные метрики

ROW_NUMBER:

  • Прерывания (system_in): 5687 → 8279 (+45% рост)

  • Переключения контекста (system_cs): 657 → 1053 (+60% рост)

  • Процессы в run queue (procs_r): 6 → 15 (+150% рост)

Deferred Join:

  • Прерывания (system_in): 5652 → 8274 (+46% рост)

  • Переключения контекста (system_cs): 652 → 1063 (+63% рост)

  • Процессы в run queue (procs_r): 5 → 15 (+200% рост)

Сравнение: Оба подхода показывают схожий рост системных метрик, Deferred Join имеет немного больше переключений контекста.

5. Критические точки перехода

ROW_NUMBER:

  • Итерация 50 (нагрузка 10): переход на 0% idle CPU

  • Сопровождается: Ростом procs_r до 9

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

Deferred Join:

  • Итерация 52 (нагрузка 10): переход на 0% idle CPU

  • Сопровождается: Ростом procs_r до 9

  • Симптом: Снижение свободной памяти до 4000 KB

6. Корреляция с нагрузкой

  • 5-8 соединений: Оба подхода работают с простоями CPU (36% idle)

  • 10 соединений: Критическая точка (0% idle)

  • 12-15 соединений: Стабилизация на максимальной нагрузке

  • 18-22 соединений: Дальнейший рост системных метрик

7. Ключевые различия по метрикам

ROW_NUMBER преимущества:

  1. Меньше IO операций (58 vs 68)

  2. Лучшее использование памяти (растущая свободная память)

  3. Более стабильный кэш (меньше колебаний)

Deferred Join преимущества:

  1. Меньше системного времени CPU (3% vs 4%)

  2. Более предсказуемое использование кэша (постепенный рост)

  3. Меньше начальных буферов (более эффективное использование)

8. Проблемные паттерны

ROW_NUMBER:

  • Проблема: Резкое падение кэша с 4955 до 2751

  • Причина: Оконные функции требуют больших рабочих наборов

  • Риск: Потенциальные page faults при недостатке памяти

Deferred Join:

  • Проблема: Высокий базовый уровень IO (59 vs 52)

  • Причина: Hash Join и сортировка для OFFSET

  • Риск: Disk I/O bottlenecks при высокой нагрузке

9. Общие выводы по метрикам

  1. Оба подхода CPU-bound: 0% idle при нагрузке ≥10 соединений

  2. Deferred Join более IO-intensive: на 10-15% выше IO активность

  3. ROW_NUMBER более memory-intensive: активнее использует кэш и буферы

  4. Критическая нагрузка: 10 соединений для обоих подходов

  5. Масштабирование: Deferred Join лучше сохраняет кэш, но требует больше IO

10. Рекомендации по оптимизации системы

Для ROW_NUMBER:

  1. Увеличить work_mem для сортировки в памяти

  2. Настроить shared_buffers для кэширования рабочих наборов

  3. Мониторить page faults и swap активность

Для Deferred Join:

  1. Оптимизировать индексы для уменьшения IO

  2. Рассмотреть SSD для уменьшения latency IO операций

  3. Настроить effective_io_concurrency для параллельного IO

Итог:

Выбор между подходами зависит от конфигурации системы -

  • ROW_NUMBER для CPU-обеспеченных архитектур

  • Deferred Join для систем с хорошим IO.

Показать полностью 6
[моё] Postgresql Тестирование Нейронные сети Инженер Статья Длиннопост
0
4

UNION vs UNION ALL⁠⁠

Почему одно объединение "умное", но медленное, другое - "тупое", но честное?

Обсудим сегодня эту тему.

UNION vs UNION ALL

А пока подписывайся на мой канал На связи: SQL Там я публикую посты про особенности и нюансы SQL. Этот канал про то, как не бояться баз данных, понимать, что такое JOIN, GROUP BY и почему NULL ≠ 0. Его я веду с нуля подписчиков. Присоединяйся!

UNION и UNION ALL.

На вид - почти одно и то же.
По смыслу - разные вещи.

И вот почему

UNION ALL — «тащит всё как есть»

UNION ALL просто берёт результаты двух запросов и клеит их друг под другом:

SELECT name FROM customers

UNION ALL

SELECT name FROM partners;

Никаких проверок, дубликатов, умностей.

- Если в обоих списках есть «Иван», то итоговый результат будет два «Ивана».
- Если порядок в исходных таблицах хаотичный, в результате он будет ещё хаотичнее.

UNION ALL = быстро + честно + без фильтров.

UNION - «умный, но медленный»

UNION делает то же самое, но перед тем как вернуть результат, он удаляет дубликаты:

SELECT name FROM customers

UNION

SELECT name FROM partners;

Чтобы убрать дубли, PostgreSQL/Oracle/MySQL вынуждены:

  • отсортировать результат

  • или построить hash-сет

  • и только потом вернуть данные

Это дорого.
На миллионах строк может стать тормозом №1 в отчёте.

UNION = красиво, чисто, но медленно.

Где использовать UNION?

✔ Когда действительно нужны уникальные значения

Например, получить список всех пользователей, независимо от источника:

SELECT user_id FROM old_system

UNION

SELECT user_id FROM new_system;

✔ Когда нужно исключить дубли после сложной логики

Например, когда запросы пересекаются, а ты не хочешь вручную писать DISTINCT.

Где использовать UNION ALL?

Практически везде, там где не надо удалять дубликаты, т.к. их по определению нет.
Например объединение отчетных данных за разные периоды.

SELECT * FROM sales_2024

UNION ALL

SELECT * FROM sales_2025;

Неочевидный факт: порядок строк не гарантируется

Ни в UNION, ни в UNION ALL.

Если хочешь порядок — дописывай: ORDER BY

Вывод:

  • UNION ALL — как корзина: «скидываем всё подряд».

  • UNION — как фильтр: «скидываем всё, но потом отбираем уникальное».

Мой канал На связи: SQL ждет тебя, если ты тоже хочешь познакомиться с базовым языком для аналитики данных. Подписывайся!

Показать полностью 1
[моё] Аналитик Аналитика SQL Анализ данных Microsoft Excel База данных Таблица Postgresql IT Длиннопост
0
3

PostgreSQL : Seq Scan против индексов - парадоксальный, на первый взгляд, итог нагрузочного тестирования⁠⁠

Взято с основного технического канала Postgres DBA (возможны правки в исходной статье).

Seq Scan: Неожиданный чемпион высоких нагрузок.

Seq Scan: Неожиданный чемпион высоких нагрузок.

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

В этой статье показаны результаты нагрузочного тестирования PostgreSQL в условиях нагрузочного тестирования, которые привели к парадоксальному на первый взгляд выводу. Когда количество одновременных операций растет, а данные активно читаются, дорогостоящие индексы могут не справиться, превратившись из помощников во вредителей. И как оказалось, старый добрый Seq Scan — метод полного сканирования таблицы — неожиданно стал в итоге самым эффективным решением в этом сценарии.

Постановка экспериментов

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

CREATE TABLE pgbench_test

(

aid integer PRIMARY KEY ,

bid integer,

abalance integer,

filler character(84)

);

ALTER TABLE pgbench_test ADD CONSTRAINT "pgbench_test_bid_fkey" FOREIGN KEY (bid) REFERENCES pgbench_branches(bid);

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;

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

select test.abalance

from pgbench_accounts acc

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

where acc.aid = current_aid ;

Эксперимент-1 : Метод доступа Seq Scan

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

Стоимость плана = 21620.62

Gather (cost=1002.80..21620.62 rows=1460 width=4) (actual time=4.088..329.017 rows=1468 loops=1)

Workers Planned: 3

Workers Launched: 3

-> Hash Join (cost=2.80..20474.62 rows=471 width=4) (actual time=1.821..300.589 rows=367 loops=4)

Hash Cond: (test.bid = acc.bid)

-> Parallel Seq Scan on pgbench_test test (cost=0.00..19619.81 rows=322581 width=8) (actual time=0.692..263.390 rows=250000 loops=4)

-> Hash (cost=2.79..2.79 rows=1 width=4) (actual time=0.488..0.489 rows=1 loops=4)

Buckets: 1024 Batches: 1 Memory Usage: 9kB

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

Index Cond: (aid = 51440641)

Planning Time: 1.977 ms

Execution Time: 329.301 ms

Эксперимент-2 : Метод доступа Bitmap Index Scan

CREATE INDEX pgbench_test_idx ON pgbench_test ( bid );

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

Стоимость плана = 1546.55

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

Эксперимент-3 : Метод доступа Index Only Scan

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

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

Стоимость плана = 48.86

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

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

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

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

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

  1. До 8-ми соединений - наибольшая производительность получена с использованием метода доступа Bitmap Index Scan.

  2. После 8-ми соединений и до 22-х - наибольшая производительность получена с использованием метода доступа Seq Scan.

Причины эффективности Seq Scan при параллельной нагрузке

1. Увеличение нагрузки на подсистему ввода-вывода

  • Без индекса: Sequential Scan читает данные большими последовательными блоками

  • С индексом: Index Scans создают случайный доступ к диску

2. Конкуренция за буферный кэш

  • Индекс занимает место в shared_buffers

  • Вытесняет полезные данные из кэша

  • Каждое соединение читает разные части индекса → больше промахов кэш

3. Блокировки в системных каталогах

  • При использовании индекса PostgreSQL обращается к системным каталогам

  • Увеличивается конкуренция за pg_index, pg_class

  • Особенно заметно при многих одновременных соединениях

4. CPU overhead

  • Обработка индекса требует больше CPU операций

  • Bitmap Index Scan + Bitmap Heap Scan сложнее чем простой Seq Scan

  • При росте соединений CPU становится узким местом

Показать полностью 2
[моё] Postgresql Тестирование Длиннопост
0
6

PG_EXPECTO: Прицельный залп по проблемам производительности PostgreSQL⁠⁠

Взято с основного технического канала Postgres DBA (возможны правки в исходной статье).

Определи цель, заряди параметры, устрани проблему

Определи цель, заряди параметры, устрани проблему

Предисловие:

Когда производительность СУБД падает под нагрузкой, важно не стрелять наугад. Методика PG_EXPECTO предлагает сначала выявить ключевые цели — проблемные запросы и типы ожиданий — и только затем наносить точный удар, используя «большие пушки» оптимизации.

1. Анализ ожиданий СУБД на основании данных о диаграмме Парето

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

1. Анализ ожиданий типа IPC (Inter-Process Communication)

BgWorkerShutdown (40,62%) — наиболее проблемное событие:

  • Указывает на ожидание завершения фоновых процессов

  • Возможные причины:

  • Медленное завершение параллельных worker-процессов

  • Проблемы с освобождением ресурсов

  • Возможные deadlock-ситуации при завершении

ParallelFinish (25,4%) и ExecuteGather (21,14%):

  • Связаны с параллельным выполнением запросов

  • Высокие значения могут указывать на:

  • Слишком агрессивные настройки параллелизма

  • Конкуренцию за ресурсы между параллельными worker-ами

  • Неоптимальные планы выполнения параллельных запросов

2. Анализ ожиданий типа LWLock (Lightweight Locks)

BufferMapping (49,46%) — основная проблема в блокировках:

  • Указывает на конкуренцию за доступ к буферному кешу

  • Возможные причины:

  • Недостаточный размер shared_buffers

  • Высокая конкурентная нагрузка на горячие данные

  • Отсутствие или неэффективность индексов

SerializableXactHash (31,72%):

  • Связано с транзакциями уровня изоляции SERIALIZABLE

  • Может указывать на:

  • Высокую конкуренцию за структуры данных serializable транзакций

  • Необходимость оптимизации транзакций

Рекомендации по устранению проблем:

Для IPC-ожиданий:

1.Проверить настройки параллелизма:

max_parallel_workers_per_gather

max_parallel_workers

max_worker_processes

2.Анализировать логи на предмет ошибок воркеров

3.Рассмотреть уменьшение параллелизма для сложных запросов

Для LWLock-ожиданий:

  1. Оптимизировать работу с буферным кешем:

  2. Увеличить shared_buffers (если позволяет RAM)

  3. Проверить эффективность индексов

  4. Рассмотреть использование pg_prewarm для критичных данных

  5. Для Serializable транзакций:

  6. Проверить необходимость использования SERIALIZABLE изоляции

  7. Оптимизировать длительность транзакций

  8. Рассмотреть альтернативные уровни изоляции

Общие рекомендации:

  1. Сбор дополнительной информации:

  2. Получить полный список ожиданий за период инцидента

  3. Проверить мониторинг нагрузки на CPU, IO, память

  4. Возможные immediate-действия:

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

  6. Временно снизить параллелизм

  7. Добавить индексы на часто используемые поля в условиях WHERE/JOIN

Вывод:

Основные проблемы связаны с параллельным выполнением запросов и конкуренцией за буферный кеш. Рекомендуется поэтапная оптимизация настроек параллелизма и работы с памятью.

2. Анализ событий ожиданий по отдельным SQL-запросам на основании данных о диаграмме Парето

Проанализируй данные по событиям ожидания для SQL запросов по queryid в ходе инцидента производительности СУБД PostgreSQL

Ключевые выводы по корреляции типов ожиданий и запросов

1. Запросы с наибольшим влиянием на IPC-ожидания:

Топ-1 проблемный запрос (17,6% IPC ожиданий):

  • queryid: -1701015661318396920 3018 вызовов, 85k строк

  • Ожидания: BgWorkerShutdown, ParallelFinish, BufferIO, ExecuteGather

  • Анализ: Часто выполняемый параллельный запрос с проблемами завершения воркеров

Топ-2 (14% IPC ожиданий):

  • queryid: -678327810318891437 5183 вызовов, 5183 строк

  • Особенность: Каждый вызов возвращает ровно 1 строку

  • Высокая частота выполнения усиливает проблемы параллелизма

2. Запросы с наибольшим влиянием на LWLock-ожидания:

Топ-1 проблемный запрос (24,73% LWLock ожиданий):

  • queryid: -8182552260313222074 42,7k вызовов, 8,5M строк

  • Ожидания: BufferMapping

  • Анализ: Крайне часто выполняемый запрос с высокой конкуренцией за буферный кеш

Критический запрос, присутствующий в обеих категориях:

  • queryid: 5459520954633506046:

  • IPC: 5,34% (параллельное выполнение)

  • LWLock: 11,83% (ParallelHashJoin)

  • Особенность: 287 вызовов, но 217k строк на вызов (~759 строк/вызов)

  • Вероятно: Сложный аналитический запрос с хеш-соединениями

Детальный анализ проблемных паттернов:

A. Проблемы параллельного выполнения:

  1. Запросы с ParallelFinish и ExecuteGather:

  2. Все топ-8 IPC запросов имеют эти ожидания

  3. Рекомендация: Уменьшить max_parallel_workers_per_gather для этих queryid

  4. Конкретные кандидаты на оптимизацию:

  5. queryid: 1374759154717555017 2053 вызова, 0 строк

  6. Возможно, DML-операция с неправильным планом

  7. Имеет HashBuildHashInner - проблема с хеш-таблицами

B. Проблемы с блокировками буферов:

  1. Высокочастотные запросы:

  2. queryid: -8182552260313222074 42k вызовов

  3. Решение: Кэширование на уровне приложения, batch-обработка

  4. Serializable транзакции в db5:

  5. 4 из топ-8 LWLock запросов используют SerializableXactHash

  6. Все из базы db5

  7. Рекомендация: Пересмотреть уровень изоляции

Приоритетные действия:

1. Немедленные меры:

  • Для queryid: -8182552260313222074 (42k вызовов):

  • -- Добавить индексы на используемые предикаты

  • -- Внедрить кэширование на 5-10 минут

  • Для queryid: -1701015661318396920 (частый параллельный запрос):

  • -- Принудительно отключить параллельное выполнение

  • SET max_parallel_workers_per_gather = 0;

2. Среднесрочная оптимизация:

Группа 1: Частые параллельные запросы

  • queryid: -678327810318891437 (5k вызовов)

  • queryid: 3449463017331132112 (3k вызовов)

  • Действие: Оптимизация планов, уменьшение частоты выполнения

Группа 2: Запросы с хеш-соединениями

  • queryid: 5459520954633506046

  • queryid: 1374759154717555017

  • Действие: Увеличить work_mem, добавить индексы для соединений

3. Долгосрочные изменения:

Для базы db5 (Serializable транзакции):

  • Аудит необходимости SERIALIZABLE изоляции

  • Возможный переход на REPEATABLE READ

Настройка PostgreSQL:

# Увеличить для уменьшения BufferMapping

shared_buffers

# Оптимизация параллельных запросов

max_parallel_workers_per_gather = 2 (вместо 4-8)

parallel_setup_cost = 1000

parallel_tuple_cost = 0.1

# Увеличение для хеш-соединений

work_mem = 32MB (или больше)

Рекомендуемый план действий:

  1. Неделя 1: Оптимизация двух самых проблемных запросов

  2. queryid: -8182552260313222074 (кэширование)

  3. queryid: -1701015661318396920 (отключение параллелизма)

  4. Неделя 2: Анализ и оптимизация запросов с хеш-соединениями

  5. Добавление индексов

  6. Пересмотр логики запросов

  7. Неделя 3: Работа с часто выполняемыми запросами

  8. Батчинг

  9. Оптимизация бизнес-логики

  10. Неделя 4: Пересмотр уровня изоляции в db5

  11. Тестирование производительности при READ COMMITTED/REPEATABLE READ

Важно:

Все изменения должны тестироваться на staging-окружении с нагрузочным тестированием.

3.Сводный отчет по ожиданиям и проблемным SQL запросам

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

Контекст

В ходе инцидента производительности СУБД PostgreSQL выявлены проблемные SQL-запросы с высокой корреляцией (≥0.7) между типом ожидания и нагрузкой на СУБД. Отчет сформирован на основе анализа событий ожиданий и соответствующих запросов.

Ключевые наблюдения

  1. Наиболее частые события ожидания:

  2. IPC: BgWorkerShutdown (40,62%)

  3. LWLock: BufferMapping (49,46%)

  4. Наиболее проблемные запросы:

  5. IPC: -1701015661318396920 (17,6% ожиданий)

  6. LWLock: -8182552260313222074 (24,73% ожиданий)

  7. Распределение по БД:

  8. db1 и db5 имеют наибольшее количество проблемных запросов

  9. role1 является общей ролью для всех проблемных запросов

  10. Паттерны ожиданий:

  11. Запросы с высоким числом CALLS часто имеют ожидания типа LWLock

  12. Запросы с большим количеством возвращаемых ROWS склонны к ожиданиям IPC

Рекомендации для дальнейшего анализа

  1. Сфокусироваться на оптимизации запросов с наибольшим процентом ожиданий

  2. Исследовать причины частых событий BgWorkerShutdown и BufferMapping

  3. Проанализировать работу параллельных операций (ParallelFinish, ExecuteGather)

  4. Проверить настройки, связанные с управлением блокировками и параллельным выполнением

Показать полностью 3
[моё] Postgresql Тестирование Нейронные сети Статья Исследования Длиннопост
0
4

PG_EXPECTO: Принцип «только большие пушки» для СУБД⁠⁠

В силу ограниченности платформы Пикабу - статья сокращена. Полностью - на основном канале Дзен.

Когда нужен не просто выстрел, а залп главным калибром.

Когда нужен не просто выстрел, а залп главным калибром.

PG_EXPECTO — это не просто инструмент, а целостный комплекс, построенный на двух новых принципах.

1. Комплексный статистический анализ (CSSA)

Система больше не разделяет метрики СУБД и инфраструктуры. Она создаёт единый корреляционный снимок всей системы:

  • Вертикальная корреляция: Вместо отдельных событий система видит цепочки: например, как медленный запрос вызывает рост очереди дисковых операций (iowait).

  • Проактивность: Комплекс отслеживает не сбои, а тренды. Он может предупредить: «Обнаружена устойчивая тенденция к деградации из-за X», позволяя устранить проблему до того, как она затронет пользователей.

2. Семантический анализ и нейросеть-ассистент

Это и есть та самая «турбина». Вместо сырых графиков PG_EXPECTO использует нейросеть, которая интерпретирует данные в контексте.

Практический пример

Инцидент производительности СУБД в панели Zabbix

Регрессионный и корреляционный анализ производительности и ожиданий СУБД

Операционная скорость и ожидания СУБД

График изменения операционной скорости СУБД перед инцидентом

График изменения операционной скорости СУБД перед инцидентом

Исходные данные для семантического анализа нейросетью

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

2. Метрика vmstat

3.Метрика iostat для дискового устройства, файловой системы /data

3.Метрика iostat для дискового устройства, файловой системы /wal

1.Анализ производительности и ожиданий СУБД

Проведи анализ производительности и ожиданий СУБД PostgreSQL за заданный период

На основе предоставленных данных можно провести следующий анализ производительности и ожиданий СУБД PostgreSQL за период с 08:40 до 09:40:

📈 1. Регрессионный анализ

· Операционная скорость (SPEED):

o Коэффициент детерминации R2=0.88R2=0.88 → модель хорошо описывает данные.

o Угол наклона = -43.1 → скорость со временем снижается.

· Ожидания СУБД (WAITINGS):

o R2=0.75R2=0.75 → модель умеренно точна.

o Угол наклона = +40.87 → количество ожиданий растёт.

🔗 2. Корреляционный анализ

· SPEED vs WAITINGS: −0.763→ сильная отрицательная корреляция. Чем больше ожиданий, тем ниже скорость.

· WAITINGS vs IPC: 0.9039 → очень сильная положительная корреляция. Рост межпроцессного взаимодействия связан с ростом ожиданий.

· WAITINGS vs LWLOCK: 0.9587 → почти прямая зависимость. Ожидания сильно связаны с лёгкими блокировками (lightweight locks).

📉 3. Динамика изменения показателей

· SPEED:

o Начало: ~130 572

o Конец: ~90 948

o Снижение на ~30% за час.

· WAITINGS:

o Начало: 345

o Конец: 435

o Рост на ~26%.

· IPC и LWLOCK также растут, особенно заметно после 09:30.

⚠️ 4. Потенциальные проблемы

1. Рост LWLOCK → возможна конкуренция за лёгкие блокировки (например, в памяти).

2. Рост IPC → увеличивается нагрузка на межпроцессное взаимодействие, возможно из-за параллельных запросов.

3. Падение SPEED при росте WAITINGS → система тратит больше времени на ожидания (возможно, из-за блокировок или нехватки ресурсов).

2.Анализ vmstat

Проведи анализ метрик vmstat за заданный период

На основе данных vmstat за период с 08:40 до 09:40 проведён анализ производительности системы, на которой работает PostgreSQL. Вот ключевые выводы:

📊 1. Общие тенденции

· Время простоя CPU (idle) снизилось с 90% до 85%.

· Пользовательская нагрузка CPU (us) выросла с 9% до 13%.

· Системная нагрузка CPU (sy) стабильна (2%).

· Ожиданий ввода-вывода (wa) не наблюдается (0%).

🧠 2. Анализ памяти

Показатель Начало Конец Изменение Комментарий

swpd 710МБ 749МБ +39 МБ Незначительный рост свопа, система не испытывает нехватки RAM.

free 7185МБ 3221МБ -3964 МБ Сильное снижение свободной памяти, что говорит о её активном использовании.

cache 53521МБ 55937МБ +2416МБ Кэш памяти увеличивается, что нормально при активной работе с диском.

Вывод: Память активно используется, но свопинг минимален — система работает в рамках доступной памяти.

💽 3. Ввод-вывод (I/O)

Показатель Начало Конец Пиковое значение Тренд

bi (блоков ввода/с) 572 2409 2409 Резкий рост после 09:25.

bo (блоков вывода/с) 850 511 850 Снижение, затем стабилизация.

Вывод:

· После 09:25 резко выросла активность чтения с диска (bi).

· Это совпадает с падением SPEED в данных PostgreSQL.

· Возможно, это связано с увеличением количества запросов к данным, не помещающихся в кэш.

🔄 4. Системные показатели

Показатель Начало Конец Изменение

in (прерываний/с) 12833 14503 +13%

cs (переключений контекста/с) 6835 7033 +3%

Вывод: Умеренный рост прерываний и переключений контекста, что соответствует увеличению нагрузки.

📉 5. Связь с данными PostgreSQL

Сравнивая с предыдущим анализом cluster.txt, наблюдаем:

1. Рост ожиданий (WAITINGS) в PostgreSQL коррелирует с:

o Ростом bi (чтение с диска).

o Увеличением us (пользовательская нагрузка CPU).

2. Падение SPEED совпадает с:

o Увеличением bi (дисковые операции).

o Снижением idle CPU.

⚠️ 6. Потенциальные узкие места

1. Дисковый ввод-вывод: резкий рост bi после 09:25 может быть причиной замедления.

2. Использование памяти: свободная память уменьшается, но свопинг незначителен — пока критично.

3. Нагрузка на CPU: idle снижается, но не до критических значений.

✅ 7. Рекомендации

1. Оптимизация запросов:

o Увеличить shared_buffers, чтобы больше данных кэшировалось в памяти.

o Проверить наличие медленных запросов, выполняющих полное сканирование таблиц.

2. Мониторинг диска:

o Проверить скорость дисковых операций (например, с помощью iostat).

o Рассмотреть использование SSD или увеличение скорости дискового массива.

3. Настройка PostgreSQL:

o Увеличить effective_cache_size.

o Настроить work_mem для уменьшения операций на диске.

4. Системные настройки:

o Убедиться, что достаточно оперативной памяти для кэширования.

o Рассмотреть увеличение количества CPU, если нагрузка продолжит расти.

📈 8. Визуализация (рекомендуется)

· График SPEED и bi на одной оси времени → проверить корреляцию.

· График WAITINGS и us (пользовательская нагрузка CPU).

· График free memory и cache → отследить использование памяти.

График SPEED и bi на одной оси времени → проверить корреляцию.

Для наглядности значения bi увеличены в 10 раз

Для наглядности значения bi увеличены в 10 раз

Отрицательная корреляция: Рост значений bi сопровождается снижением операционной скорости.

График WAITINGS и us (пользовательская нагрузка CPU).

Для наглядности значения us увеличены в 10 раз

Для наглядности значения us увеличены в 10 раз

Положительная корреляция: Рост значений us сопровождается увеличением количества ожиданий.

График free memory и cache → отследить использование памяти.

Отрицательная корреляция: Рост значений free сопровождается снижением значений cache.

free -3964 МБ: Сильное снижение свободной памяти, что говорит о её активном использовании.

cache +2416 МБ: Кэш памяти увеличивается, что нормально при активной работе с диском.

3. Анализ iostat для файловой системы /data

На основе данных iostat для устройства vdb за период с 08:40 до 09:40 проведён анализ дисковых операций. Вот ключевые выводы:

📊 1. Общая картина

· Устройство vdb используется для операций чтения и записи.

· %util (загрузка диска) выросла с 5.59% до 6.7% — загрузка низкая.

· aqu_sz (средняя длина очереди) незначительно снизилась с 0.26 до 0.20 — очереди практически нет.

📈 2. Операции чтения (Read)

Показатель Начало Конец Изменение Комментарий

r/s (чтений/с) 40.00 27.92 -30% Снижение количества операций чтения.

rMB/s (МБ/с) 0.84 2.82 +235% Резкий рост объёма читаемых данных.

rareq_sz (средний размер запроса) 19.35 КБ 67.09 КБ +247% Запросы стали крупнее.

r_await (среднее время чтения, мс) 2.07 3.73 +80% Увеличение времени отклика на чтение.

Вывод:

После 09:20 резко вырос объём читаемых данных (rMB/s) и средний размер запроса (rareq_sz). Это говорит о переходе на более крупные блоки данных, возможно из-за изменения типа запросов (например, сканирование больших таблиц).

📉 3. Операции записи (Write)

Показатель Начало Конец Изменение

w/s (записей/с) 16.83 15.20 -10%

wMB/s (МБ/с) 0.62 0.26 -58%

wareq_sz (средний размер записи) 31.74КБ 4.22КБ -87%

w_await (среднее время записи, мс) 5.57 3.59 -36%

Вывод:

Нагрузка на запись снижается, операции становятся мельче и быстрее.

🔗 4. Корреляция с WAITINGS (PostgreSQL)

· После 09:20 наблюдается рост r_await (время чтения) и WAITINGS (ожидания в СУБД).

· Рост rMB/s совпадает с ростом WAITINGS и падением SPEED.

· Это подтверждает гипотезу о том, что увеличение времени доступа к диску влияет на производительность БД.

⚠️ 5. Потенциальные проблемы

1. Увеличение времени чтения (r_await): с 2 мс до 3.7 мс — рост на 80%.

2. Увеличение размера запросов (rareq_sz): с 19 КБ до 67 КБ — возможно, из-за отсутствия индексов или полного сканирования таблиц.

3. Рост объёма читаемых данных (rMB/s): в 3 раза — нагрузка на диск возросла.

✅ 6. Рекомендации

1. Оптимизация запросов PostgreSQL:

o Проверить выполнение планов запросов (EXPLAIN ANALYZE).

o Добавить индексы для часто сканируемых таблиц.

o Увеличить shared_buffers, чтобы больше данных кэшировалось в памяти.

2. Мониторинг диска:

o Проверить скорость диска (например, с помощью hdparm или fio).

o Убедиться, что диск не фрагментирован.

3. Настройка PostgreSQL:

o Увеличить effective_cache_size.

o Настроить random_page_cost и seq_page_cost в соответствии с типом диска.

4. Аппаратные улучшения:

o Рассмотреть переход на SSD, если используется HDD.

o Увеличить скорость дисковой подсистемы (RAID, кэширование).

📈 7. Визуализация (рекомендуется)

· График rMB/s и WAITINGS на одной оси времени.

· График r_await и rareq_sz.

· График %util и aqu_sz для оценки загрузки диска.

График rMB/s и WAITINGS.

Для наглядности значения rMB/s увеличены в 100 раз

Для наглядности значения rMB/s увеличены в 100 раз

Увеличение rMB/s сопровождается ростом количества ожиданий.

График r_await и rareq_sz.

График %util и aqu_sz для оценки загрузки диска.

Для наглядности значения aqu_sz увеличены в 10 раз

Для наглядности значения aqu_sz увеличены в 10 раз

🎯 Заключение

Основная причина деградации производительности — рост размера и времени выполнения дисковых операций чтения, что приводит к увеличению лёгких блокировок (LWLOCK) и ожиданий (WAITINGS) в СУБД.

Приоритет действий:

1. Оптимизация запросов и индексов

2. Настройка параметров PostgreSQL (память, I/O)

3. Аппаратное улучшение дисковых подсистем

4. Мониторинг и алертинг ключевых метрик

Система не испытывает критической нехватки CPU или памяти, но дисковый ввод-вывод стал узким местом из-за изменившегося характера нагрузки (крупные запросы на чтение).

Показать полностью 11
[моё] Postgresql Нейронные сети Статья Инженер DeepSeek Длиннопост
1
Блог компании

Дизайн для детей: обучение цифровому творчеству на онлайн-курсах⁠⁠

Уроки обучения дизайну для детей могут строиться вокруг пары самостоятельных направлений. Это, скажем, web-дизайн, в рамках которого предполагается погружение в теорию и практику использования Figma и подобных сервисов для прототипирования и создания визуальных макетов страниц. Второе же направление в данном контексте – графический дизайн. Осваивать его ребята различных возрастов могут путем работы с рядом редакторов, например Photoshop и Illustrator.

Собрали несколько комплексных и обособленных онлайн-курсов и проанализировали их: если тема дополнительного обучения творческого ребенка актуальна, материал придется кстати.

Содержание

  • Графический и веб-дизайн для детей: подборка онлайн-курсов для ребят младшего школьного и подросткового возраста

  • Комплексная траектория «UX/UI-дизайн» для детей 12–17 лет

  • Уроки графического дизайна для школьников, обучающихся в 5–11-х классах

  • Занятия по графическому и веб-дизайну: обучение для школьников

  • Цифровой дизайн: уроки для ребят 7–16 лет

  • Курс «Digital-дизайнер» для детей от 10 до 15 лет

  • Уроки графического дизайна для детей: обучение онлайн школьников 10+ лет

  • Уроки обучения веб-дизайну для детей от 8 до 17 лет

  • FAQ

  • Чем полезны уроки обучения веб-дизайну для детей?

  • Как выбрать онлайн-курсы веб-дизайна для подростков?

  • В каком возрасте можно записаться на обучение веб-дизайну для школьников?

  • Онлайн-обучение дизайну для детей подойдет только творческим ребятам?

Графический и веб-дизайн для детей: подборка онлайн-курсов для ребят младшего школьного и подросткового возраста

Сразу предлагаем перейти к сути: далее опубликовали ряд тематических курсов и аналитические сведения по каждому варианту.

Комплексная траектория «UX/UI-дизайн» для детей 12–17 лет

Узнать о траектории графического и веб-дизайна для подростков

Форматы: пройти уроки обучения графическому и веб-дизайну для детей можно в группе или один на один с опытным учителем.

Цена: от 600 рублей за час.

Скидка: 10 %. Получить выгоду удастся, если заплатить за 12 уроков минимум в день обращения.

Оплата маткапиталом: предусмотрена, дополнительно можно оформить вычет в размере 13 % и воспользоваться рассрочкой.

Содержание уроков: если коротко, то занятия по графическому и веб-дизайну для подростков помогут участникам траектории разобраться в создании сайтов, использовании Adobe Photoshop и Illustrator, а также собрать ряд проектов и добавить их в собственное портфолио.

Если более конкретно, то школьникам предстоит освоить:

  • Веб-дизайн на примере использования Figma. Это сервис, функционирующий онлайн и предназначенный специально для создания макетов и прототипов сайтов. Дополнительно в соответствующий перечень блоков теории и практики заложены темы, касающиеся создания веб-проектов посредством конструктора Tilda, не требующего навыков в написании кода;

  • Графический дизайн на примере использования Photoshop и Illustrator от Adobe. Если более конкретно, то участникам образовательной траектории предстоит поработать с цветом, формами, расположением визуальных элементов в проектах, а также вникнуть в векторную и растровую графику как обособленные сферы графического дизайна в целом.

Уроки графического дизайна для школьников, обучающихся в 5–11-х классах

Форматы: организатор набирает мини-группы, индивидуальные уроки не предусмотрены.

Цена: от 770 рублей за урок.

Темы: применение Figma, использование Photoshop, конструирование сайтов посредством Tilda и т. д.

Занятия по графическому и веб-дизайну: обучение для школьников

Форматы: мини-группы.

Цена: весь курс стоит от 34 750 рублей.

Темы: дизайн лендингов, графические концепции, работа с визуалом, разработка афиш и баннеров, оформление плакатов и т. д.

Цифровой дизайн: уроки для ребят 7–16 лет

Форматы: только индивидуальные удаленные уроки.

Цена: от 1 200 рублей за урок.

Темы: работа с инструментами различных графических редакторов, основы композиции и колористики, выполнение иллюстраций, создание макетов сайтов, фирменный стиль и т. д.

Курс «Digital-дизайнер» для детей от 10 до 15 лет

Форматы: набираются группы.

Цена: от 1 650 рублей за одно дистанционное занятие.

Темы: азы иллюстрации, создание композиции графического проекта, верстка, элементы фирменного стиля, основы так называемой упаковки бренда и т. д.

Уроки графического дизайна для детей: обучение онлайн школьников 10+ лет

Форматы: проводятся индивидуальные и индивидуально-групповые уроки.

Цена: от 790 рублей за урок.

Темы: коллажи в Фотошопе, ретуширование фотографий, креатив и стилизация, создание стикеров из пикселей и т. д.

Уроки обучения веб-дизайну для детей от 8 до 17 лет

Форматы: только один на один с учителем.

Цена: базовая стоимость занятия составляет 1 500 рублей.

Темы: создание графических интерфейсов, работа с прототипами, использование сервиса Figma и т. д.

FAQ

Чем полезны уроки обучения веб-дизайну для детей?

Уроки веб‑дизайна дают детям отличную возможность развить креативность и прокачать пространственное мышление. На курсах ребята учатся работать с цветами, формами и композицией, продумывать визуальную гармонию проектов и не только. В процессе создания макетов сайтов и интерфейсов школьники пробуют выражать свои идеи через дизайн-концепции, экспериментируют с разными стилями и находят собственный почерк. Это не просто рисование, каким оно предстает на бумаге. Это цифровое и часто вполне осмысленное творчество, где каждая деталь имеет значение и помогает ребенку выразить себя.

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

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

А еще тематические занятия повышают цифровую грамотность и дают представление о том, как устроены современные онлайн‑сервисы вроде Figma, что в будущем может стать хорошей основой для профессионального роста в IT.

Как выбрать онлайн-курсы веб-дизайна для подростков?

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

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

Не менее значимы человеческий фактор и формат поддержки. Лучше выбирать курсы, где есть обратная связь от преподавателя: комментарии к работам, разборы ошибок и ответы на вопросы помогают подростку не застревать на трудностях и чувствовать, что его прогресс замечают.

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

Учет этих и других факторов поможет сделать безошибочный выбор, который в дальнейшем даст устойчивый результат.

В каком возрасте можно записаться на обучение веб-дизайну для школьников?

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

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

Онлайн-обучение дизайну для детей подойдет только творческим ребятам?

Нет, онлайн‑обучение дизайну подойдет не только творческим ребятам. Сегодня тематические образовательные программы для детей строятся так, чтобы вести конкретного ученика с самого начала, то есть от азов и до сложных тем. Все это реализуемо, даже если до этого учащийся никогда не рисовал и не интересовался графикой.

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

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

При этом важно понимать, что на курсах дизайна ребята учатся не вдохновению из головы, а конкретным приемам и алгоритмам действий для творчества, и именно через это открывают в себе способность придумывать и воплощать собственные идеи. Так что отсутствие опыта или творческих наклонностей – не препятствие, если ребенок хочет попробовать себя в представленном направлении.

Реклама ООО «ПИКСЕЛЬ.СТАДИ», ИНН: 5074078988

Показать полностью 8
Программирование Обучение IT Образование Программа Python Тестирование Программист Задача Linux Postgresql Microsoft Windows Фриланс Автоматизация Openai Информационная безопасность Заработок в интернете Стартап Блоги компаний Длиннопост
Блог компании

Создание модов на языке программирования Python в Майнкрафте: ТОП-10 онлайн-курсов для обучения детей⁠⁠

Уроки языка программирования «Питон» с нуля для детей не всегда обязательно строить вокруг сухой теории и выполнения скучных проектов. Дело в том, что данный инструмент можно использовать в связке с Minecraft для разработки и кодинга модов, что на практике улучшает восприятие Python и делает учебный процесс куда более увлекательным. Это обусловлено популярностью Майнкрафта среди детей и подростков.

Содержание

  • Онлайн-курсы Python – языка программирования в Майнкрафте

  • Python-разработчик: образовательная траектория для младших школьников и подростков 10–13 лет

  • Онлайн-уроки Python в Minecraft для ребят 10+ лет

  • Курс «Основы математической логики в среде Minecraft» для детей 8–12 лет

  • Уроки программирования и 3Д-моделирования для детей 8–10 лет

  • Онлайн-занятия по кодингу в Майнкрафте для школьников 9–12 лет

  • Online-курс по программированию в Майнкрафте для детей 7–12 лет

  • Уроки создания модификаций в Minecraft для школьников 10 лет и старше

  • Трехмерное моделирование и кодинг в игровой вселенной для ребят 8–10 лет

  • Уроки кодинга на языке программирования Python в Minecraft для ребят 9–14 лет

  • Дистанционный курс написания кода в Майнкрафте для ребят 9 лет и старше

  • FAQ

  • Можно ли записаться на курсы языка программирования «Питон» для подростков без Майнкрафта?

  • Есть ли онлайн-занятия по языку «Питон» для 8-х классов?

  • Какой язык программирования используется в Minecraft для кодинга модов?

  • На каком языке программирования написан сам Майнкрафт?

Онлайн-курсы Python – языка программирования в Майнкрафте

Собрали десятку тематических онлайн-курсов, которые помогут разобраться в написании кода на «Питоне» на примере программирования модов для популярной игровой вселенной Minecraft. По традиции представили некоторые аналитические сведения вроде цен, форматов и тем.

Python-разработчик: образовательная траектория для младших школьников и подростков 10–13 лет

Узнать о комплексной траектории разработки и кодинга на «Питоне»

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

Форматы: освоить представленное направление можно в группе или индивидуально с учителем.

Цена: от 600 рублей за один час онлайн-уроков.

Скидки: 10 %. Для получения выгоды нужно выполнить условие в виде оплаты 12 занятий минимум в день обращения.

Выгоды: вычет 13 % после учебы, оплата маткапиталом, рассрочка.

Содержательная сторона: отметили, что траектория объединяет два курса. Первый можно считать вводным: он основан на программировании модов для Майнкрафта на «Питоне». Второй же поможет углубиться в основы кодинга на данном языке и приблизиться к пониманию принципов продвинутого написания текстового кода.

Комплексность траектории выражается в том, что благодаря ее освоению каждый ребенок сможет разобраться в:

  • Основах кодинга на Python и продвинутом программировании на данном языке;

  • Принципах гейм-дизайна, создания игр и модов на примере разработки функциональных дополнений для Minecraft.

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

Так, курсы языка программирования «Питон» для детей и подростков, объединенные в траекторию, помогут овладеть данным инструментом и начать использовать его на продвинутом уровне даже вне рамок Майнкрафта.

Онлайн-уроки Python в Minecraft для ребят 10+ лет

Форматы: видео в записи.

Цена: доступ к видеокурсу на месяц стоит 7 990 рублей. Если хочется увеличить срок до 160 суток, потребуется заплатить 20 000+.

Темы: циклы, ввод текста, случайные числа, типы данных, создание модов для Майнкрафта и т. д.

Курс «Основы математической логики в среде Minecraft» для детей 8–12 лет

Форматы: один на один с учителем и в группе.

Цена: от 4 900 рублей за месяц.

Темы: операторы, компараторы, логические схемы, строительство в игровой вселенной и т. д.

Уроки программирования и 3Д-моделирования для детей 8–10 лет

Форматы: групповые занятия.

Цена: от 1 650 рублей за урок.

Темы: написание кода, создание 3D-моделей, скриптинг различных модов и т. д.

Онлайн-занятия по кодингу в Майнкрафте для школьников 9–12 лет

Форматы: мини-группы.

Цена: базовая стоимость занятия составляет 1 200 рублей.

Темы: структура Minecraft-модов, пиксельная графика, типы данных, координаты, условия и т. д.

Online-курс по программированию в Майнкрафте для детей 7–12 лет

Форматы: индивидуальное и групповое онлайн-обучение.

Цена: от 1 125 рублей за урок.

Темы: основы кодинга в игровой вселенной, создание игровых объектов, командная разработка и т. д.

Уроки создания модификаций в Minecraft для школьников 10 лет и старше

Форматы: группы.

Цена: от 5 200 рублей за месяц.

Темы: разработка Minecraft-модификаций, проектирование внутриигровых объектов, 3Д-моделирование и т. д.

Трехмерное моделирование и кодинг в игровой вселенной для ребят 8–10 лет

Форматы: групповое дистанционное обучение.

Цена: от 3 000 рублей за онлайн-урок.

Темы: моды для Minecraft, их создание и программирование, трехмерное моделирование и т. д.

Уроки кодинга на языке программирования Python в Minecraft для ребят 9–14 лет

Форматы: индивидуальное обучение.

Цена: нет информации.

Темы: методы и атрибуты, работа с координатами, условные операторы, сравнение, синтаксис «Питона», его потенциал с точки зрения создания модов и т. д.

Дистанционный курс написания кода в Майнкрафте для ребят 9 лет и старше

Форматы: индивидуальный и индивидуально-групповой.

Цена: от 790 рублей / урок.

Темы: основы программирования, азы 3Д-моделирования, создание мини-игр в виде модификаций и т. д.

FAQ

Можно ли записаться на курсы языка программирования «Питон» для подростков без Майнкрафта?

Да, такие курсы есть. Они предлагаются различными онлайн- и офлайн-школами программирования для детей.

Отличительная особенность – упор на использование языка для выполнения проектов, альтернативных модам для Minecraft. Вместе с тем не стоит полагать, что увлекательная практика исключается или опускается до минимума: проектная деятельность – основа множества современных детских курсов «Питона». Почти в любой вероятной ситуации ребятам предстоит осваивать теорию и закреплять получаемые представления посредством практики. Речь, скажем, о программировании чат-ботов, создании 2Д-игр на Python и не только.

Есть ли онлайн-занятия по языку «Питон» для 8-х классов?

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

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

Дополнительно советуем уточнить сведения о лицензировании организатора: наличие разрешительной документации будет плюсом. В других статьях в блоге отмечали, что это гарантия качества образовательных программ. Дополнительно лицензия открывает клиентам доступ к ряду условных бонусов вроде возможности оплаты занятий ребенка средствами маткапитала или оформления налогового вычета в размере 13 %.

Какой язык программирования используется в Minecraft для кодинга модов?

В преобладающем количестве случаев речь о «Питоне», о чем позволяет утверждать подготовленная нами подборка. Но здесь же подчеркнем, что есть альтернативные направления, скажем, основанные на теории и практике использования функции Code Builder. В случае с ней предполагается вводное обучение младших школьников путем погружения в блочное программирование.

При этом важно учитывать, что в Code Builder необходимо использовать блоки с текстовыми командами, написанными на Python и JavaScript. То есть в случае с кодингом модов в неоднократно упомянутой игровой вселенной вероятны два варианта языков, а именно «Питон» и ДжаваСкрипт.

На каком языке программирования написан сам Майнкрафт?

Minecraft существует в двух основных версиях, которые написаны на разных языках программирования. Оригинальный вариант игры прописан посредством использования Java. Данная и стартовая версия создана Маркусом Перссоном.

Выбор представленного языка был обусловлен его кроссплатформенностью: игра может работать на различных операционных системах без необходимости переписывания кода. Кроме того, открытая архитектура как важное свойство Java позволила сформировать обширное сообщество моддеров. Речь о том, что пользователи получили возможность разрабатывать и устанавливать модификации, существенно расширяющие функционал игры.

Вторая версия под названием Minecraft: Bedrock Edition была переписана на языке C++. Здесь выбор, как кажется, связан с необходимостью обеспечить высокую производительность и эффективное управление ресурсами на разнообразных устройствах, включая консоли и мобильные телефоны. Потребность в этом стала вытекать из роста популярности Майнкрафта.

Благодаря C++ версия Bedrock способна похвастаться лучшей оптимизацией и стабильной работой даже на сравнительно слабых устройствах. Дополнительно вариант поддерживает кроссплатформенную игру, то есть пользователи могут играть вместе независимо от того, используют они ПК, консоль или смартфон.

Между версиями есть существенные различия. Java Edition доступна исключительно на ПК, предлагает широкие возможности для моддинга, но может характеризоваться проблемами производительности при установке большого количества модификаций.

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

Реклама ООО «ПИКСЕЛЬ.СТАДИ», ИНН: 5074078988

Показать полностью 11
Программирование IT Обучение Инженер Программа Python Тестирование Образование Linux Postgresql Microsoft Автоматизация Windows Openai Фриланс Информационная безопасность Стартап Программист Блоги компаний Длиннопост
Блог компании

Бесплатные курсы Python для школьников: видеоуроки и подборки роликов для самостоятельного освоения языка⁠⁠

Бесплатные курсы Python для детей – это не всегда обязательно направления и образовательные программы, выстроенные традиционным строгим образом. Речь о том, что в интернете есть множество видеокурсов и подборок роликов, предназначенных для самостоятельного и пошагового освоения языка.

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

Содержание

  • Курсы Python для школьников бесплатно: видеоуроки и последовательные подборки обучающих роликов

  • Видеокурсы Python для детей бесплатно онлайн

  • Плейлисты с обучающими роликами на тему «Питона»

  • Уроки программирования на Python для детей на примере создания модов для Майнкрафта

  • FAQ

  • Уроки Python для детей бесплатно онлайн чем-то хуже традиционных курсов?

  • Бесплатные курсы Python для детей помогут ребенку стать программистом?

  • Зачем онлайн-школы распространяют курсы Python для школьников бесплатно?

  • Связаны ли Scratch и Python для детей?

Курсы Python для школьников бесплатно: видеоуроки и последовательные подборки обучающих роликов

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

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

Итак, приступаем к сути.

Видеокурсы Python для детей бесплатно онлайн

Ссылка на страницу с видеокурсами на тему программирования, создания игр и сайтов

На представленной странице опубликованы различные направления кодинга на «Питоне» в формате видеокурсов. Для примера опишем примечательные варианты. Это:

  • Создание игр в Майнкрафте и программирование на Python. Вариант поможет разобраться в основах геймдева путем освоения текстового кодинга. Стимул и мотив для ребенка на пути к достижению учебных результатов и целей – возможность создания модов для популярной игровой вселенной Minecraft;

  • Написание кода на «Питоне». Данный видеокурс Python для детей не основан на сухой и скучной теории: будет практика, предстоит создать различные игры, запрограммировать их на представленном языке, что сделает занятия увлекательными и интересными даже для непоседливого ребенка;

  • Python для новичков. Это вводный видеокурс с базовыми уроками программирования на Python для детей. Удастся разобраться в переменных, библиотеках, функциях, разработке игр для Android и т. д.

Видеокурсы – отличный инструмент для старта. После них, когда базовые навыки получены, можно перейти к дополнительным занятиям с использованием плейлистов с образовательным потенциалом. Искать их можно на Rutube и иных популярных видеохостингах, а если делать это лень, просто перейдите к следующему разделу: собрали и опубликовали несколько интересных вариантов.

Плейлисты с обучающими роликами на тему «Питона»

Подборка плейлистов на тему программирования на «Питоне» и не только

Если хочется найти уроки Python для детей и пройти их бесплатно онлайн, можно воспользоваться и Rutube. На представленной странице нашли несколько релевантных подборок:

  • Уроки Python для школьников. Особенность плейлиста – включение в него базовой информации. Просмотр роликов поможет узнать о том, что такое «Питон», что значит код в программировании, какие есть переменные и библиотеки, циклы, списки, функции и т. д.;

  • Разработка игр на «Питоне». В подборке продемонстрированы примеры выполнения различных гейм-проектов. Это, скажем, игра «Поймай крота», а также Сапер, Змейка, Ping-Pong и т. д.;

  • Строительство в Майнкрафте с помощью Python. Ролики в плейлисте помогут разобраться, как посредством данного языка в Minecraft можно сделать ракету, маяк, красивый дом, башню, портал, машину, лес и не только.

Если что-то не получилось или возникли трудности либо просто хочется пройти углубленное обучение использованию «Питона», подойдет курс, представленный далее.

Уроки программирования на Python для детей на примере создания модов для Майнкрафта

Узнать об онлайн-курсе

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

Форматы: обучаться можно в группе или индивидуально, а также по видеоматериалам в записи.

Цена: один онлайн-урок стоит 800 рублей минимум.

Скидки: 10 %. Выгода доступна новичкам. Активировать скидку удастся путем оплаты минимум 12 занятий в день обращения.

Выгоды: оплата маткапиталом, рассрочка 50/50, налоговый вычет в размере 13 %.

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

Содержательная сторона: акцент в рамках онлайн-курса поставлен на создание модов для Minecraft и их программирование посредством Python. Удастся разобраться, помимо прочего, в использовании среды разработки IDLE, работе с библиотекой Turtle, в применении базовых конструкций. Предусмотрены дополнительные блоки теории и практики, посвященные кодингу модов, основам геймдева и игрового дизайна на примере разработки в Minecraft.

FAQ

Уроки Python для детей бесплатно онлайн чем-то хуже традиционных курсов?

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

Однако и частные авторы – любители или профи – могут демонстрировать высокий уровень. Но стоит понимать, что профессиональные программисты на деле куда больше заняты основным направлением деятельности: записывать обучающие ролики им просто некогда. И все-таки снова подчеркнем, что даже любительские видео могут быть достаточно полезными и содержательными.

Говорить, что хуже или лучше, не будем. Отметим лишь, что в случае с теми же бесплатными видеокурсами понять, насколько качественные ролики предлагаются, удастся только после их просмотра. И бесплатность здесь – плюс: даже если учеба не придется по вкусу, можно забросить ее без переживаний о потраченных деньгах.

Бесплатные курсы Python для детей помогут ребенку стать программистом?

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

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

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

Зачем онлайн-школы распространяют курсы Python для школьников бесплатно?

Считаем, что это больше и в первую очередь маркетинговый инструмент. Дело в том, что free-уроки в формате видеокурсов или подборок роликов на видеохостингах – средство демонстрации того, какие образовательные программы реализуются на курсах.

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

Связаны ли Scratch и Python для детей?

В образовательном плане и в контексте дополнительного обучения детей в направлении IT – да, но как частные и обособленные языки – нет.

Дело в том, что Скретч – визуально-блочная и событийно-ориентированная среда, считающаяся вводной. Код здесь представлен набором последовательно соединенных блоков с текстовыми командами, а сам процесс приближен к сути сборки конструктора Lego, что гарантирует максимальную простоту. В онлайн- и офлайн-школах программирования для детей Скретч используется преимущественно на курсах, ориентированных на ребят без опыта, скажем, пока не до конца понимающих базовые принципы программирования, распространенные конструкции, их использование и т. д.

Если говорить об образовательной связи Скретча с «Питоном», то стоит отметить, что первый помогает готовиться к освоению второго. То есть в ситуации, когда Scratch изучен, переход к Python станет максимально простым и даже беспроблемным. Это на практике становится следствием того, что ребенок по мере работы со Скретчем получил базу, разобрался в основных терминах, понятиях и конструкциях, благодаря чему текстовое программирование почти точно будет восприниматься школьником куда более просто.

Реклама ООО «ПИКСЕЛЬ.СТАДИ», ИНН: 5074078988

Показать полностью 4
Обучение Программирование Образование IT Программа Python Задача Урок Учеба Занимательная арифметика Тестирование Postgresql Linux Программист Блоги компаний Длиннопост
Посты не найдены