Видео

Оптимизатор это давно хорошо отруливает

Pycharm или WebStorm, точно не помню (

Спасибо за поддержку! Хорошо, запишу в задачи для себя

Seq scan - последовательное сканирование без использование индекса. Любой индекс надо тестировать на своих данных, так и обоснуете перед начальством и командой 😉

Вы про WITH Queries (Common Table Expressions), CREATE TEMPORARY TABLE или что-то иное?

@@lets_goto_it cte в видео видела, использую другую субд sql server, там есть возможность создать лок таблицы # или глобал ##, они же тоже помогают в оптимизации или отличий нет от cte в плане производительности? в Pg я так поняла редко используют таблицы типа #, ## (CREATE TEMPORARY TABLE)?

@@lets_goto_it про TEMPORARY TABLE. cte и TEMPORARY TABLE есть отличия в контексте производительности?

Для всего свой инструмент, конечно. Одного правильного решения нет и пока не предвидится. При этом для большинства обычных проектов контейнеризация это, ИМХО, скорее благо. Если речь идет про сайты и подобное. А деплой по FTP скорее не благо. Для деплоя баз данных и подобного я бы сильно подумал из--за оверхедов на io диск,а например, но плюсы все равно будут, например для dev стендов. Всегда нужно смотреть на конкретную ситуацию и контекст.

@@lets_goto_it а для сайтов где благо? Вот берём lamp. Что, для каждого сайта/версии упаковывать всю структуру в докер? 🤦‍♂️ Что за бред? Никогда такого не делали. Любой нормально настроенный apache или nginx обслуживает десятки-сотни сайтов быстрее, чем весь фарш запихивать в контейнер для одного лиш инстанса. Так же и любая нормально настроенная СУБД будет десятки баз тянуть быстрее. Распределённая технология для этого и существует уже много лет. Что за больная панацея с этими докерами? Никого не смущает, что помимо всего фарша контейнер несёт в себе ещё минимальную ОС? Это получается куча виртуалок всего лишь для одного приложения ещё в рамках другой виртуалки. Мы аппаратными ресурсами будем так расплевываться? Или я что-то не понимаю 🤷‍♂️ Как и сказал выше, докеры - это глупая панацея для новых айтишников. Сторожилы, кто сам вручную конфигурил дисковые полки, массивы, гипервизоры, поднимал кластеры и в них виртуалки потом (для каждой из которых в зависимости от нужд была своя конфигурация, вплоть до проброса физ. лунов), смотрит на бессмысленное использование докеров с подозрением.

Спасибо! Да, если такая проблема к сожалению и готовый видос не поправить к сожалению. ( В более свежих звука или нет или он оч тихо сделан. Может быть попозже сниму ремейк =)

Спасибо за комментарий 👍 Таймкоды там есть, но, видать низковато, поднял выше

@@lets_goto_it аа, вижу в комментариях, в видео искал :)

☺️

В каких-то случаях, да, конечно. Одного правильного инструмента под всё никогда нет. Polars скорее всего может быть оправдан, если у вас датасайнс сложный и вам нужна гибкость или нет возможности подключиться к БД (или она под дикой нагрузкой) или делать join или группировку неэффективно. В обычных же случаях лично я предпочел бы простой join, группировку прямо в БД или ее реплике.

Привет! Тут одного правильного ответа нет, к сожалению. Для меня это издревле был хабр + мануал самого PG. Сейчас появилось много интересного, обращу внимание на документы ребят из postgrespro (они одна из разработчиков постргресса) postgrespro.ru/education/books и postgrespro.ru/education/courses

Да, вы правы, без null мир был бы лучше! Тем не менее у людей в реальных проектах вполне себе может быть такая ситуация и это связано с разными причинами: кто-то хочет работать с более явным пониманием заполнены ли данные или нет, чем сравнение с условным 1970-01-01 00:00:00, у кого-то есть необходимость такого хранения например по ТЗ или еще как-то. Кажется, что стоит рассказывать как справляться с такой проблемой, если она возникла. Тем не менее, я с вами согласен - важно помнить, что наличие NULL может усложнить обработку данных и привести к различным проблемам. Поэтому, при принятии решения об использовании NULL, необходимо тщательно взвесить все за и против.

Спасибо 😊. Готовлю новые выпуски

для всего свои инструменты, это точно

Здорово! Если время позволяет, то это супер просто!

Монолит также в целом можно и нужно запускать в несколько инстансов. Однако это может быть нетривиальной задачей по сравнению с более компактным микросервисом. Однако с микросервисами отдельная боль - за ними надо отдельно следить (monitoring и observability) и вообще следить вся всеми их *bility отдельно по каждому. Мультиинстанс и распределенные блокировки я делал и с монолитом и с микросервисами

Пожалста! COPY IN позволяет оч быстро потоково загружать данные в БД, COPY OUT оч быстро выгружать также потоково. Вы нашли в explain для этих методов что-то интересное? Про оптимизацию долдих апдейтов можно, кстати, видос записать отдельный - спасибо за идею! В целом обычно стратегия такая же как и с delete-ами, а именно - разбить группу строк на подгруппы и обновлять/удалять по отдельности пачками.

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

Вы зоркий глаз ;) Спасибо за комментарий. Да, она есть, но как по мне несущественная. Если строки у вас не будут конскими, то они не попадут в TOAST. В доке ( postgrespro.ru/docs/postgrespro/current/datatype-character ) написано "По быстродействию эти три типа практически не отличаются друг от друга, не считая большего размера хранения для типа с дополняющими пробелами и нескольких машинных операций для проверки длины при сохранении строк в столбце с ограниченной длиной. Хотя в некоторых СУБД тип character(n) работает быстрее других, в Postgres Pro это не так; на деле character(n) обычно оказывается медленнее остальных типов из-за большего размера данных и более медленной сортировки. В большинстве случаев вместо него лучше применять text или character varying."

Можете указать тайминг, чтобы я проверил?

9ая минута, думаю

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

Как-то не сложилось у меня чтение в текстовом формате. Вы же про это? Если да, то для чего вам именно текстом? В pg admin есть пара кнопок для нормальной визуализации. Я тут только про одну рассказываю.

@@lets_goto_it хотелось про планировщик, почему индексы не всегда работают (процентаж выборки), про буферы, почему важно иметь кеш запросов, про характер выборки и первоначальную цель запроса, как с помощью EXPLAIN можно изменить понимание тог, что должен делать запрос. Даже простое объяснение отличия EXPLAIN от ANALYZE

Да можно, но в отчетах как-то проблемы с ним часто возникают на реальных данных. LEFT join при отсутствии данных вернет null и вы этот null увидите и пойдете разбираться, в inner join срежет и всё =) Конечно, ситуации бывают разные, но опят показывает, что часто лучше себя показывает LEFT - так как если данные в порядке, то и все норм, а если не в порядке, то приложение упадет в худшем случае или, если вы знаете, что там может упасть, то запишете warning лог и будете обрабатывать следующую запись. Вот вам еще тру стори - всегда, когда у вас в приложении есть метод fetchOne, который должен вернуть одну строку или null, если ее нет, обязательно поставьте проверку, на случай, если вернулось больше одной строки и или падайте в том месте или пишите error лог, так как скорее всего что-то не так. Если подытожить - и left join и история с fetchOne призваны спасти вас от неправильной работы приложения / утере или порче данных.

Все будет зависеть от того, что у вас еще на это БД выполняется. Питон очень легко горизонтально масштабировать под нагрузкой - запускаете еще pod-ов в Kubernetes с приложенькой и всё, а с БД так не пойдет. Т.е. надо смотреть характер нагрузки и общий тренд по использованию вашей БД, мб вам просто нужны асинхронная реплика БД для того, чтобы гонять там аналитические запросы на чтение - в этом случае это просто масштабируется и основное приложение вообще глючить не будет. В целом же я сторонник обрабатывать данные там, где они хранятся и поменьше выгребать в приложение. При этом если у вас БД будет не считать, а заниматься json encode / json decode все время, то тоже наверное ничего хорошего) Это не самая простая операция для PG, а еще хуже становиться, когда у вас JSON больше 2Kb - это вообще караул. Давно хочу про JSON и JSONB видос записать

Ход мыслей у вас в нужном направлении, но на самом деле точнее всего вам скажет Explain. У меня есть видео на эту тему - ruclips.net/video/bgLSn23g768/видео.html При этом всем будет важна версия БД, так как тут как в ЯП - их разработчики не сидят без дела и вносят правки в планировщик запросов и делают другие эвристические оптимизации. Поэтому конкретно на вашем примере created_at + interval '60 day' >= NOW() БД вполне может решить перекинуть действия с интервалом в правую часть выражения со знаком минус. В общем каждый тяжелый запрос хорошо бы проверить, но вы правы - лучше всего не добавлять БД работы и помогать ей проще находить константные выражения.

macos

MacOs с 2013-го. Начинал в 2008 на Windows, потом было много разных линуксов, потом пересел на macos и она для меня вне конкуренции теперь. Там и красиво и нормальный терминал и это все же unix-овое семейство, что чуть упрощает некоторые дела. Есть много коллег, которые на Windows работают и у них тоже все норм, ра исключением того, что не все ПО нормально под windows работает, но конкретно у них все пучком уже. На серверах только linux

@@lets_goto_itwsl используется?

Спасибо! Вы все верно подметили. Бывает, что надо восстанавливать БД с отключенными триггерами, чтобы быстрее отработал pg_restore. Для этого у этой утилиты есть спец. параметр

Да, запишу обязательно. Тема оч сложная и глубокая на самом деле. Если в двух словах, то выбирать лучше jsonb, а не json. Не хранить там больше 2kb и всегда выносить первичный ключ отдельно, чтобы не было таблицы из одного поля. Индексы тоже не забывай - там можно

🤝👌

Посмотрите до конца