2 жыл бұрын
2 жыл бұрын
Пікірлер
@ЕвгенийПеревалов-ч1т Ай бұрын
Жаль что поздно набрел на твой канал. Очень понятно все рассказываешь по sql. Даже появилось желание от орм отказаться.
@A1_TR_812 Ай бұрын
красава спасибо
@hr_in_kz 3 ай бұрын
Хороший урок. Видно через видео что урок взят из продакшен опыта. Как будто на работе побывал.
@ДмитрийПитаков-я9ы 3 ай бұрын
По поводу cost оно отрабатывает на функциях immutable и stable желательно со свойством leakproof, postgresql может для immutable заменить вызов функции константой и передать это в executor, а для stable тоже заменить константой но уже в ексекьютере. Короче говоря нужно смотреть категорию изменчивости функции в комплексе с cost.
@МарияКолесова-н9ф 4 ай бұрын
Здравствуйте, а можно как-то сохранить explain из pgAdmin. Необходимо план запроса отправить разработчикам, а как его сохранить не понятно и есть ли вообще такая возможность?
@LudaMihko 4 ай бұрын
Не понятно что в конце с is и is not?
@blackman852 4 ай бұрын
Полностью согласен. Мне 21, работаю в ит в офисе, каждый день выхожу с офиса на полчаса походить по району.
@Dima-Teplov 5 ай бұрын
Отличный урок! Огромное спасибо!
@user-tt9hx4kh1e 6 ай бұрын
с самых азов учили наперед просчитывать все так, чтобы лишний раз не было никакой лишней нагрузки на систему
@leilailolo4736 6 ай бұрын
и зачем спрашивается тебе левый джойн, если ты в условии фильтруешь по этому полю из таблицы, котороую присоеденил, нужно было ставить обычный джойн, а условие писать в джойне, а не в where, что бы не создавать мегатаблицу
@lets_goto_it 6 ай бұрын
Оптимизатор это давно хорошо отруливает
@sofiya41. 6 ай бұрын
Здравствуйте, расскажите пожалуйста про хранимые пользовательские функции в постгрес🙏
@Seraf_ 6 ай бұрын
Просто СУБД не преисполнилась еще
@brainlesspolitican743 6 ай бұрын
Слишком простые случаи вы рассматриваете) Помимо атомарности в acid еще 3 буквы. Но и помимо ACID, система транзакционности, это довольно глубокая тема, которая перетекает в mvcc , mvcc перетекает в изолированность и тд. Но документацию про доку соглашусь))
@Aleksey-t9b 7 ай бұрын
Это топовое объяснение🔥
@selub1058 7 ай бұрын
Круто ❤. Спасибо что делитесь опытом.
@crawner6198 7 ай бұрын
Очень полезное видео! Автор красавчик, все структурировано, понятно и голос приятный! Спасибо, помогли
@kura3327 8 ай бұрын
это goland что ли?)
@lets_goto_it 8 ай бұрын
Pycharm или WebStorm, точно не помню (
@habib_sultan 8 ай бұрын
Благодарим! Очень полезно основательно и без воды. Можно еще записать видос про лучшие практики по работе с большими БД (с подробным пояснением).
@lets_goto_it 8 ай бұрын
Спасибо за поддержку! Хорошо, запишу в задачи для себя
@scum9180 8 ай бұрын
Что такое Seq Scan? Не повлияет ли новосозданный индекс на дальнейшую работу с таблицей? И не уволят ли с работы, если создать такой индекс 😂
@arturgspb 8 ай бұрын
Seq scan - последовательное сканирование без использование индекса. Любой индекс надо тестировать на своих данных, так и обоснуете перед начальством и командой 😉
@wasabi_fox 9 ай бұрын
спасибо!
@karinalazareva6123 9 ай бұрын
жаль, нет примеров с временными таблицами( например, в субд MS SQL - таблицы через #, ##
@lets_goto_it 9 ай бұрын
Вы про WITH Queries (Common Table Expressions), CREATE TEMPORARY TABLE или что-то иное?
@karinalazareva6123 9 ай бұрын
@@lets_goto_it cte в видео видела, использую другую субд sql server, там есть возможность создать лок таблицы # или глобал ##, они же тоже помогают в оптимизации или отличий нет от cte в плане производительности? в Pg я так поняла редко используют таблицы типа #, ## (CREATE TEMPORARY TABLE)?
@karinalazareva6123 9 ай бұрын
@@lets_goto_it про TEMPORARY TABLE. cte и TEMPORARY TABLE есть отличия в контексте производительности?
@Chirickk 9 ай бұрын
Опять не понял. Для чего мне вообще паковать все в контейнеры? Я так понимаю, это всё для молодых, кто в it недавно.
@lets_goto_it 9 ай бұрын
Для всего свой инструмент, конечно. Одного правильного решения нет и пока не предвидится. При этом для большинства обычных проектов контейнеризация это, ИМХО, скорее благо. Если речь идет про сайты и подобное. А деплой по FTP скорее не благо. Для деплоя баз данных и подобного я бы сильно подумал из--за оверхедов на io диск,а например, но плюсы все равно будут, например для dev стендов. Всегда нужно смотреть на конкретную ситуацию и контекст.
@Chirickk 9 ай бұрын
@@lets_goto_it а для сайтов где благо? Вот берём lamp. Что, для каждого сайта/версии упаковывать всю структуру в докер? 🤦♂️ Что за бред? Никогда такого не делали. Любой нормально настроенный apache или nginx обслуживает десятки-сотни сайтов быстрее, чем весь фарш запихивать в контейнер для одного лиш инстанса. Так же и любая нормально настроенная СУБД будет десятки баз тянуть быстрее. Распределённая технология для этого и существует уже много лет. Что за больная панацея с этими докерами? Никого не смущает, что помимо всего фарша контейнер несёт в себе ещё минимальную ОС? Это получается куча виртуалок всего лишь для одного приложения ещё в рамках другой виртуалки. Мы аппаратными ресурсами будем так расплевываться? Или я что-то не понимаю 🤷♂️ Как и сказал выше, докеры - это глупая панацея для новых айтишников. Сторожилы, кто сам вручную конфигурил дисковые полки, массивы, гипервизоры, поднимал кластеры и в них виртуалки потом (для каждой из которых в зависимости от нужд была своя конфигурация, вплоть до проброса физ. лунов), смотрит на бессмысленное использование докеров с подозрением.
@Яшар-ш3ж 9 ай бұрын
Все превосходно но бро, прошу убери звук на фоне. сильно мешает понять контент((
@lets_goto_it 9 ай бұрын
Спасибо! Да, если такая проблема к сожалению и готовый видос не поправить к сожалению. ( В более свежих звука или нет или он оч тихо сделан. Может быть попозже сниму ремейк =)
@vakrokodil 10 ай бұрын
спасибо!😊
@edmundslukasevics4623 10 ай бұрын
Спасибо, но пригодились бы таймкоды в видео :)
@lets_goto_it 10 ай бұрын
Спасибо за комментарий 👍 Таймкоды там есть, но, видать низковато, поднял выше
@edmundslukasevics4623 10 ай бұрын
@@lets_goto_it аа, вижу в комментариях, в видео искал :)
@anniesunny8398 10 ай бұрын
Мемы - топ😂
@lets_goto_it 10 ай бұрын
☺️
@CarpeDiemDolceVita 10 ай бұрын
Polars мб лучше для джойнов
@lets_goto_it 10 ай бұрын
В каких-то случаях, да, конечно. Одного правильного инструмента под всё никогда нет. Polars скорее всего может быть оправдан, если у вас датасайнс сложный и вам нужна гибкость или нет возможности подключиться к БД (или она под дикой нагрузкой) или делать join или группировку неэффективно. В обычных же случаях лично я предпочел бы простой join, группировку прямо в БД или ее реплике.
@CarpeDiemDolceVita 10 ай бұрын
Спасибо
@fedordostoevskiy4209 10 ай бұрын
Привет! Если есть возможность пробежать по литературе полезной.
@lets_goto_it 10 ай бұрын
Привет! Тут одного правильного ответа нет, к сожалению. Для меня это издревле был хабр + мануал самого PG. Сейчас появилось много интересного, обращу внимание на документы ребят из postgrespro (они одна из разработчиков постргресса) postgrespro.ru/education/books и postgrespro.ru/education/courses
@evgenievgeni2016 10 ай бұрын
А не кажется ли вам, что это борьба не с причиной, а со следствием? Зачем оставлять null в колонке? Чтобы что? Понятно, что цель показать частичный индекс, но пример не особо.
@lets_goto_it 10 ай бұрын
Да, вы правы, без null мир был бы лучше! Тем не менее у людей в реальных проектах вполне себе может быть такая ситуация и это связано с разными причинами: кто-то хочет работать с более явным пониманием заполнены ли данные или нет, чем сравнение с условным 1970-01-01 00:00:00, у кого-то есть необходимость такого хранения например по ТЗ или еще как-то. Кажется, что стоит рассказывать как справляться с такой проблемой, если она возникла. Тем не менее, я с вами согласен - важно помнить, что наличие NULL может усложнить обработку данных и привести к различным проблемам. Поэтому, при принятии решения об использовании NULL, необходимо тщательно взвесить все за и против.
@binbinbinbin123 10 ай бұрын
Просто, кратко, ясно и практично! Спасибо большое))) Первый раз за много лет пишу коммент в youtube)))
@uliavvvvvvvvvv 11 ай бұрын
Большое спасибо за ваш курс,за ваш труд!Вас очень интересно слушать,а главное полезно)
@lets_goto_it 11 ай бұрын
Спасибо 😊. Готовлю новые выпуски
@felakos1568 11 ай бұрын
Даже если ЯП разрешает "запивать водку пивом", я вежливо отказываюсь. Ну, вы меня поняли)
@lets_goto_it 11 ай бұрын
для всего свои инструменты, это точно
@felakos1568 11 ай бұрын
Бро, ты красавчик. Спасибо за помощь.
@yarik83men51 11 ай бұрын
Тоже работаю на удаленке, удобно, гуляю по 3 км после рабочего дня.
@lets_goto_it 11 ай бұрын
Здорово! Если время позволяет, то это супер просто!
@fedordostoevskiy4209 11 ай бұрын
Это одно и тоже приложение-монолит на разных серверах или микро сервисы?
@lets_goto_it 11 ай бұрын
Монолит также в целом можно и нужно запускать в несколько инстансов. Однако это может быть нетривиальной задачей по сравнению с более компактным микросервисом. Однако с микросервисами отдельная боль - за ними надо отдельно следить (monitoring и observability) и вообще следить вся всеми их *bility отдельно по каждому. Мультиинстанс и распределенные блокировки я делал и с монолитом и с микросервисами
@gudjihn 11 ай бұрын
Спасибо за видео! Но причём тут ссылка на Доку про copy?) Не делали explain своей вставки?) Как на уровне приложения изменить долгие строковые update на batchb update?
@lets_goto_it 11 ай бұрын
Пожалста! COPY IN позволяет оч быстро потоково загружать данные в БД, COPY OUT оч быстро выгружать также потоково. Вы нашли в explain для этих методов что-то интересное? Про оптимизацию долдих апдейтов можно, кстати, видос записать отдельный - спасибо за идею! В целом обычно стратегия такая же как и с delete-ами, а именно - разбить группу строк на подгруппы и обновлять/удалять по отдельности пачками.
@eb6006 11 ай бұрын
Интересная вещь! Не знал про такое! Выглядит как класная идея!
@user-uu8hc9hj4c 11 ай бұрын
1С можете покурить?
@lets_goto_it 11 ай бұрын
Ну там совсем свой мир со своими инструментами и подходами, не подскажу, к сожалению, вообще
@АлексейБеляев-у7щ Жыл бұрын
не прав насчет сравнениия тeхт и варчар есть разница.
@lets_goto_it Жыл бұрын
Вы зоркий глаз ;) Спасибо за комментарий. Да, она есть, но как по мне несущественная. Если строки у вас не будут конскими, то они не попадут в TOAST. В доке ( postgrespro.ru/docs/postgrespro/current/datatype-character ) написано "По быстродействию эти три типа практически не отличаются друг от друга, не считая большего размера хранения для типа с дополняющими пробелами и нескольких машинных операций для проверки длины при сохранении строк в столбце с ограниченной длиной. Хотя в некоторых СУБД тип character(n) работает быстрее других, в Postgres Pro это не так; на деле character(n) обычно оказывается медленнее остальных типов из-за большего размера данных и более медленной сортировки. В большинстве случаев вместо него лучше применять text или character varying."
@ibrahimoglu Жыл бұрын
👍
@passerist Жыл бұрын
Я плакал и ждал, когда автор нажмет Shif+F7, а так же увидит, что он выбирает всю таблицу, при этом ждет от слона использования индекса. лицорука
@lets_goto_it Жыл бұрын
Можете указать тайминг, чтобы я проверил?
@РоманБледнов-ъ9и Жыл бұрын
9ая минута, думаю
@lets_goto_it Жыл бұрын
Спасибо за ваш коммент, я проверил - все хорошо. Это просто стиль подачи информации - от оч плохого наивного решения с разбором почему не работает до поиска лучшего решения. Собственно ровно так, как и бывает у всех в жизни. Посмотрите до 18й минуты и вы увидите все заранее подготовленные патчи и запросы - я их использую для следующих итераций оптимизации с разбором того как все же заставить базу нормально выполнять всё.
@andreimikhalkevich5633 Жыл бұрын
спасибо автору, отличная подача информации, видео очень помогают в работе, переодически просматриваю, когда нужно оптимизировать или ускорить запросы
@TheDavBag Жыл бұрын
хотелось про эскплейн, конечно
@lets_goto_it Жыл бұрын
Как-то не сложилось у меня чтение в текстовом формате. Вы же про это? Если да, то для чего вам именно текстом? В pg admin есть пара кнопок для нормальной визуализации. Я тут только про одну рассказываю.
@TheDavBag Жыл бұрын
@@lets_goto_it хотелось про планировщик, почему индексы не всегда работают (процентаж выборки), про буферы, почему важно иметь кеш запросов, про характер выборки и первоначальную цель запроса, как с помощью EXPLAIN можно изменить понимание тог, что должен делать запрос. Даже простое объяснение отличия EXPLAIN от ANALYZE
@TheDavBag Жыл бұрын
прикольно, всякие "фишечки" типа ORDER BY в функциях не знал
@omg-go4vf Жыл бұрын
еще как я понимаю можно использовать inner join как средство фильтрации, то есть сокращения выборки для удешевления последующих фильтраций. Соответственно порядок inner join будет иметь значение. Я верно понимаю? комментарий в поддержку
@lets_goto_it Жыл бұрын
Да можно, но в отчетах как-то проблемы с ним часто возникают на реальных данных. LEFT join при отсутствии данных вернет null и вы этот null увидите и пойдете разбираться, в inner join срежет и всё =) Конечно, ситуации бывают разные, но опят показывает, что часто лучше себя показывает LEFT - так как если данные в порядке, то и все норм, а если не в порядке, то приложение упадет в худшем случае или, если вы знаете, что там может упасть, то запишете warning лог и будете обрабатывать следующую запись. Вот вам еще тру стори - всегда, когда у вас в приложении есть метод fetchOne, который должен вернуть одну строку или null, если ее нет, обязательно поставьте проверку, на случай, если вернулось больше одной строки и или падайте в том месте или пишите error лог, так как скорее всего что-то не так. Если подытожить - и left join и история с fetchOne призваны спасти вас от неправильной работы приложения / утере или порче данных.
@omg-go4vf Жыл бұрын
пример с json впечатляющий! Вы говорите что он накладный, а вот по сравнению с тем, как это будет делать python? как я понимаю, python помедленее будет...
@lets_goto_it Жыл бұрын
Все будет зависеть от того, что у вас еще на это БД выполняется. Питон очень легко горизонтально масштабировать под нагрузкой - запускаете еще pod-ов в Kubernetes с приложенькой и всё, а с БД так не пойдет. Т.е. надо смотреть характер нагрузки и общий тренд по использованию вашей БД, мб вам просто нужны асинхронная реплика БД для того, чтобы гонять там аналитические запросы на чтение - в этом случае это просто масштабируется и основное приложение вообще глючить не будет. В целом же я сторонник обрабатывать данные там, где они хранятся и поменьше выгребать в приложение. При этом если у вас БД будет не считать, а заниматься json encode / json decode все время, то тоже наверное ничего хорошего) Это не самая простая операция для PG, а еще хуже становиться, когда у вас JSON больше 2Kb - это вообще караул. Давно хочу про JSON и JSONB видос записать
@omg-go4vf Жыл бұрын
Возможно ранний вопрос, но не ясно как оценить расходы на запрос самой бд. Понятно что она быстрая и мощная и явно лучше написать сложный запрос, чем в питоне гонять из словаря в словарь, однако, все равно, не ясно. Вот например фильтр where created_at + interval '60 day' >= NOW() Кажется эта функция тяжелая на больших данных, так как надо делать много вычислений налету помимо остального. Как я понимаю функция которая делает выборку where created_at >= NOW() AND created_at < NOW() + INTERVAL'30 day' применяет вычисление лишь однажды и получает ответ значительно быстрее
@lets_goto_it Жыл бұрын
Ход мыслей у вас в нужном направлении, но на самом деле точнее всего вам скажет Explain. У меня есть видео на эту тему - kzbin.info/www/bejne/mJivhKFoaMxqbJo При этом всем будет важна версия БД, так как тут как в ЯП - их разработчики не сидят без дела и вносят правки в планировщик запросов и делают другие эвристические оптимизации. Поэтому конкретно на вашем примере created_at + interval '60 day' >= NOW() БД вполне может решить перекинуть действия с интервалом в правую часть выражения со знаком минус. В общем каждый тяжелый запрос хорошо бы проверить, но вы правы - лучше всего не добавлять БД работы и помогать ей проще находить константные выражения.
@omg-go4vf Жыл бұрын
начну смотреть и конспектировать. Не так уж и просто было вас найти. Думаю отличный курс. За выходные справлюсь!
@Deletedeletedelete Жыл бұрын
какой операционкой ползуетесь?
@arturgspb Жыл бұрын
macos
@lets_goto_it Жыл бұрын
MacOs с 2013-го. Начинал в 2008 на Windows, потом было много разных линуксов, потом пересел на macos и она для меня вне конкуренции теперь. Там и красиво и нормальный терминал и это все же unix-овое семейство, что чуть упрощает некоторые дела. Есть много коллег, которые на Windows работают и у них тоже все норм, ра исключением того, что не все ПО нормально под windows работает, но конкретно у них все пучком уже. На серверах только linux
@Pacs31 5 ай бұрын
@@lets_goto_itwsl используется?