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

"Яндекс" в партнерстве с девелопером MR Group запускает пилотный проект в жилом комплексе Slava в Москве, где голосовой помощник "Алиса" не просто включает музыку, а управляет домофоном, видеонаблюдением, шлагбаумом и выдает гостевые пропуска.

По сути, "Алиса" становится цифровым консьержем. Отличный пример сокращения низкопроизводительных рабочих мест! Проект реализуется через платформу Ujin, а цель амбициозная – занять до трети рынка цифровых решений в новостройках уже к 2030 году. Рынок немаленький – порядка 20 млрд рублей. И это только начало: в июне стартует отдельный проект по интеграции в дома вторичного жилья – через платформу "Наш дом" и оператора домофонов "Спутник".

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

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

Еще больше интересных материалов в моем telegram-канале "Константин Двинский"

Не забываем ставить лайк :)
Подписывайтесь, чтобы ничего не пропустить!

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

А как это влияет на производительность СУБД ?

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

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

2. Использовать сбор метрик производительности СУБД, иметь информацию о причинах изменения производительности и учитывать влияние сбора метрик .

Или проще говоря

• в первом случае: меньше знаешь - крепче спишь ,

• во-втором : за все надо платить.

С точки зрения физики - СУБД не является исключением и эффект наблюдателя , конечно же имеет место и да, любой сбор метрик производительности СУБД - влияет на производительность СУБД .

И это влияние можно оценить не только качественно но и количественно и обязательно нужно учитывать при анализе производительности СУБД:

PG_HAZEL : Влияние расчета медианного времени на производительность СУБД.

Взято с основного технического канала Postgres DBA

Начало экспериментов :

PG_HAZEL : ожидания СУБД PostgreSQL при отсутствии индексов.

Задача эксперимента

Определение и анализ характерных ожиданий, вызванных использованием индексов при массовых операциях INSERT.

Сравнительные эксперименты

Эксперимент-1 : Стандартный сценарий "Insert only"

Эксперимент-2 : Cценарий "Insert only" с использование индексов на таблице.

Сценарий "Insert only"

INSERT INTO pgbench_history (tid, bid, aid, delta, mtime)

VALUES ( current_tid , current_bid , current_aid , current_delta , CURRENT_TIMESTAMP );

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

Table "public.pgbench_history"

Column | Type | Collation | Nullable | Default

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

tid | integer | | |

bid | integer | | |

aid | integer | | |

delta | integer | | |

mtime | timestamp without time zone | | |

filler | character(22) | | |

Foreign-key constraints:

"pgbench_history_aid_fkey" FOREIGN KEY (aid) EFERENCES pgbench_accounts(aid)

"pgbench_history_bid_fkey" FOREIGN KEY (bid) REFERENCES pgbench_branches(bid)

"pgbench_history_tid_fkey" FOREIGN KEY (tid) REFERENCES pgbench_tellers(tid)

Тестовая таблица с добавленными индексами (индексы по столбцам aid , delta, mtime)

Table "public.pgbench_history"

Column | Type | Collation | Nullable | Default

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

tid | integer | | |

bid | integer | | |

aid | integer | | |

delta | integer | | |

mtime | timestamp without time zone | | |

filler | character(22) | | |

Indexes:

"pgbench_history_idx1" btree (aid)

"pgbench_history_idx2" btree (delta)

"pgbench_history_idx3" btree (mtime)

Foreign-key constraints:

"pgbench_history_aid_fkey" FOREIGN KEY (aid) REFERENCES pgbench_accounts(aid)

"pgbench_history_bid_fkey" FOREIGN KEY (bid) REFERENCES pgbench_branches(bid)

"pgbench_history_tid_fkey" FOREIGN KEY (tid) REFERENCES pgbench_tellers(tid)

Операционная скорость и медианное время тестового SQL запроса

Результат

Создание дополнительных индексов ухудшило скорость на 16-18% и увеличило время на 24-28%.

Корреляция между типами ожиданий и ожиданиями СУБД

Результат

1. Использование индексов резко увеличивает ожидания типа IO и LWLock.

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

Тип ожидания "IO"

Результат

• Резкий рост корреляции с ожиданием DataFileRead

Тип ожидания "Lock"

Тип ожидания "LWLock"

Результат

Резкий рост корреляции с событием ожидания CheckpointerComm.

Итог и результаты анализа

Отключение индексов при массовых операциях вставки данных дает прирост операционной скорости 16-18% .

Характерными признаками наличия лишних индексов при преобладании операция вставки по таблице являются:

1. Высокое значение коэффициента корреляции с событием ожидания IO/DataFileRead , LWLock/BufferMapping и LWLock/CheckpointerComm

BufferMapping : Ожидание при связывании блока данных с буфером в пуле буферов.

CheckpointerComm : Ожидание при управлении запросами fsync.