Иван, приятно, что вы так переживаете о наших читателях. За идею с дисклеймером спасибо, добавим в статью. Но мы не считаем аудиторию наших читателей настолько неопытными, чтобы она не отличила продакшен от авторского опыта с пометкой mvp.
Иван, здравствуйте. Мы не только проверяем статьи с внутренними экспертами, но и поддерживаем авторов, которые пишут самостоятельно без использования ИИ и хотят делиться не только суперидеальными проектами, но и промежуточными результатами своей работы, вроде mvp, о чем прямо говорят в статье. Делают это для того, чтобы иметь возможность получить профессиональные советы и конструктивную критику коллег. И дальше продолжить работу над проектом. О чем тоже было сказано в статье. Гитлаб автора, понятное дело, на совести автора.
В нашем случае deep buffer на Spine не был требованием первого дня. Это был задел под нормальную архитектуру площадки и унификацию с другими нашими локациями. На старте, честно говоря, Spine сам по себе был почти избыточен: при одном или двух Leaf фабрика ещё не раскрывается как полноценная Clos-топология. Но мы строили площадку с понятным путём роста.
Логика такая: Leaf у нас — это коммутатор доступа, shallow-buffer. К нему подключены гипервизоры, а модель подключения построена через L3 и ECMP. Для server-facing роли это нормально. Spine, наоборот, выбирался как deep-buffer-коммутатор, потому что в перспективе именно на нём сходятся потоки от разных Leaf. Там выше риск microbursts: коротких всплесков, когда несколько входящих направлений одновременно пытаются выгрузиться в один выходной порт. Большой буфер помогает переживать такие всплески без лишних потерь пакетов, особенно в сценариях с DCI, сетевыми хранилищами, бэкапами и другим bulk-трафиком. Поэтому на старте deep buffer действительно не был жизненно необходим. Но с учётом будущего роста, DCI и типовой архитектуры наших локаций мы предпочли сразу поставить Spine того класса, который не придётся менять при первом же расширении.
"Спасибо за комментарий! Да, при сравнении литерала varchar = bigint PostgreSQL выдаст ошибку. В примере я описывал ситуацию, которая чаще всего встречается в приложениях — когда значение приходит как параметр, и ORM передаёт его в «неправильном» типе (обычно как BIGINT). В этом случае PostgreSQL уже приводит колонку к типу параметра, и индекс перестаёт использоваться.
Действительно обновление статистики помогает, но не всегда спасает. Есть запросы, где планировщик в принципе не может выбрать идеальный план, и тогда без ручного вмешательства не обойтись. Просто в рамках гайда я сосредоточился на более типичных сценариях, с которыми чаще всего сталкиваются начинающие."
Спасибо за комментарий — вы верно подметили важный технический нюанс. В статье автор сознательно сосредоточился на базовых приёмах оптимизации: как по возможности уйти от Seq Scan к Index Scan, проверить актуальность статистики и сделать простой рефакторинг запросов. Эти шаги дают первые ощутимые улучшения без погружения в тонкости внутренних процессов СУБД. Тема Index Only Scan и его деградации из-за устаревшей visibility map, на мой взгляд, — уже более продвинутый уровень. Важность работы autovacuum автора отметил, но детали его механизмов оставил за рамками, чтобы не перегружать читателя на начальном этапе.
Спасибо за комментарий. В этой статье автор больше сфокусировался на инструментах поиска потенциально тяжёлых запросов, оставив оценку их реальной критичности на усмотрение разработчика или DBA. А так, вы верно подметили: медленный запрос не всегда является проблемой — например, в случае аналитических отчётов или batch-обработки длительное выполнение может быть ожидаемым.
Интересное замечание! Я использовал формулировку "слева направо" как общее упрощение для описания потока данных в конкретном примере, но вы правы: это не универсальное правило. Как я понял, порядок зависит от стратегии выполнения: при Hash Join первым часто отрабатывает правый узел (построение хэша), а при Nested Loop — левый. И соответственно, выполнение может идти в любую сторону в зависимости от выбранного планировщиком алгоритма. Спасибо, что затронули эту интересную техническую деталь!
Большое спасибо за внимательное чтение! Да, действительно, допущена неточность в формулировках "Bitmap Scan" и "Bitmap Index Scan". Исправили этот момент. Спасибо за помощь в улучшении статьи!
Большое спасибо за внимательное чтение! Вы абсолютно правы насчет опции SETTINGS. Она не меняет никакие параметры. Исправили этот абзац, чтобы не вводить читателей в заблуждение. Спасибо за помощь в улучшении статьи!
Отвечает автор текста: Хороший вопрос. Я сделал акцент на возможных случаях, когда из-за неточных оценок планировщик вынужден перебирать больше вариантов соединения таблиц, особенно в сложных запросах с большим количеством JOIN. Также, если он часто обращается к статистике, это может требовать декомпрессию данных из системных таблиц, что добавляет накладные расходы на этапе планирования. Но в целом, основное влияние статистики — это всё-таки время выполнения (качество плана). А вот на время планирования сильнее влияет сложность самого запроса.
Рады, что материал понравился :)
Спасибо, что читаете!
Иван, приятно, что вы так переживаете о наших читателях. За идею с дисклеймером спасибо, добавим в статью. Но мы не считаем аудиторию наших читателей настолько неопытными, чтобы она не отличила продакшен от авторского опыта с пометкой mvp.
Иван, здравствуйте. Мы не только проверяем статьи с внутренними экспертами, но и поддерживаем авторов, которые пишут самостоятельно без использования ИИ и хотят делиться не только суперидеальными проектами, но и промежуточными результатами своей работы, вроде mvp, о чем прямо говорят в статье. Делают это для того, чтобы иметь возможность получить профессиональные советы и конструктивную критику коллег. И дальше продолжить работу над проектом. О чем тоже было сказано в статье. Гитлаб автора, понятное дело, на совести автора.
Спасибо!
Здравствуйте. Вот, что передал автор статьи:
В нашем случае deep buffer на Spine не был требованием первого дня. Это был задел под нормальную архитектуру площадки и унификацию с другими нашими локациями. На старте, честно говоря, Spine сам по себе был почти избыточен: при одном или двух Leaf фабрика ещё не раскрывается как полноценная Clos-топология. Но мы строили площадку с понятным путём роста.
Логика такая: Leaf у нас — это коммутатор доступа, shallow-buffer. К нему подключены гипервизоры, а модель подключения построена через L3 и ECMP. Для server-facing роли это нормально. Spine, наоборот, выбирался как deep-buffer-коммутатор, потому что в перспективе именно на нём сходятся потоки от разных Leaf. Там выше риск microbursts: коротких всплесков, когда несколько входящих направлений одновременно пытаются выгрузиться в один выходной порт. Большой буфер помогает переживать такие всплески без лишних потерь пакетов, особенно в сценариях с DCI, сетевыми хранилищами, бэкапами и другим bulk-трафиком. Поэтому на старте deep buffer действительно не был жизненно необходим. Но с учётом будущего роста, DCI и типовой архитектуры наших локаций мы предпочли сразу поставить Spine того класса, который не придётся менять при первом же расширении.
Отвечает автор:
Благодарю за уточнение!
В дата-центре Qupra DC2 проблема с чиллерами. Устраняем. Следить за статусом можно тут — https://firstvds.live.
Спасибо за комментарий. Добавили ссылку.
Добрый день!
Отвечает автор:
"Спасибо за комментарий! Да, при сравнении литерала varchar = bigint PostgreSQL выдаст ошибку. В примере я описывал ситуацию, которая чаще всего встречается в приложениях — когда значение приходит как параметр, и ORM передаёт его в «неправильном» типе (обычно как BIGINT). В этом случае PostgreSQL уже приводит колонку к типу параметра, и индекс перестаёт использоваться.
Действительно обновление статистики помогает, но не всегда спасает. Есть запросы, где планировщик в принципе не может выбрать идеальный план, и тогда без ручного вмешательства не обойтись. Просто в рамках гайда я сосредоточился на более типичных сценариях, с которыми чаще всего сталкиваются начинающие."
Спасибо за комментарий — вы верно подметили важный технический нюанс. В статье автор сознательно сосредоточился на базовых приёмах оптимизации: как по возможности уйти от Seq Scan к Index Scan, проверить актуальность статистики и сделать простой рефакторинг запросов. Эти шаги дают первые ощутимые улучшения без погружения в тонкости внутренних процессов СУБД. Тема Index Only Scan и его деградации из-за устаревшей visibility map, на мой взгляд, — уже более продвинутый уровень. Важность работы autovacuum автора отметил, но детали его механизмов оставил за рамками, чтобы не перегружать читателя на начальном этапе.
так, вроде теперь должно заработать, посмотрите, пожалуйста)
Спасибо за комментарий. В этой статье автор больше сфокусировался на инструментах поиска потенциально тяжёлых запросов, оставив оценку их реальной критичности на усмотрение разработчика или DBA. А так, вы верно подметили: медленный запрос не всегда является проблемой — например, в случае аналитических отчётов или batch-обработки длительное выполнение может быть ожидаемым.
Добрый день!
Вроде ссылка работает, но вот еще продублирую на всякий случай)
https://habr.com/ru/companies/first/articles/1006278/
Спасибо, что обратили внимание! Внесли правку)
Отвечает автор текста:
Интересное замечание! Я использовал формулировку "слева направо" как общее упрощение для описания потока данных в конкретном примере, но вы правы: это не универсальное правило. Как я понял, порядок зависит от стратегии выполнения: при Hash Join первым часто отрабатывает правый узел (построение хэша), а при Nested Loop — левый. И соответственно, выполнение может идти в любую сторону в зависимости от выбранного планировщиком алгоритма. Спасибо, что затронули эту интересную техническую деталь!
Большое спасибо за внимательное чтение! Да, действительно, допущена неточность в формулировках "Bitmap Scan" и "Bitmap Index Scan". Исправили этот момент. Спасибо за помощь в улучшении статьи!
Большое спасибо за внимательное чтение! Вы абсолютно правы насчет опции SETTINGS. Она не меняет никакие параметры. Исправили этот абзац, чтобы не вводить читателей в заблуждение. Спасибо за помощь в улучшении статьи!
Отвечает автор текста:
Хороший вопрос. Я сделал акцент на возможных случаях, когда из-за неточных оценок планировщик вынужден перебирать больше вариантов соединения таблиц, особенно в сложных запросах с большим количеством JOIN. Также, если он часто обращается к статистике, это может требовать декомпрессию данных из системных таблиц, что добавляет накладные расходы на этапе планирования. Но в целом, основное влияние статистики — это всё-таки время выполнения (качество плана). А вот на время планирования сильнее влияет сложность самого запроса.
Спасибо за дополнения!