05:31 Планирование и мониторинг 18:20 про масштабирование 23:23 Про долгие транзакции 28:35 Про фоновые задачи 33:20 Автоматизация 37:35 Контейнеры и оркестрация
люто плюсую! только вопрос насчет самописных очередей, PgQ - это же не про замену Redis и прочего? сорян за возможно некорректный вопрос, пока просто тегово знаком с терминами
У меня вопрос про репликации. В одну базу пишем, с другой читаем. Но ведь сами базы должны постоянно реплицироваться, и это ведь тоже нагрузка на железо? И как часто они синхронизируют данные? Во т приложение записало данные пользователя, и тут же пытается их считать из другой базы, они там уже есть или будет в этот момент тормозить, пока данные обновятся во второй базе? Короче насколько репликации затратный процесс?
Если коротко отвечать, то зависит все от рабочей нагрузки на мастер. Если запросы хорошо оптимизированы, накладные расходы конечно есть, но незначительные
Не понял момент на 27 минуте - если приложение откроет транзацию, что-то запишет в базу, а потом крашнется - разве этой транзации не будет приозведен роллбэк автоматически?
не совсем так. приложение открыло транзакцию, записало что-то в базу, затем не закрыв транзакцию решило обратиться к другой базе/api/etc... и если это обращение (не связанное с постгресом) завершилось с ошибкой и ошибку забыли обработать, то транзакция останется висеть т.к. с точки зрения работы с постгресом ошибки не было.
Нет, это был пример в начале доклада, типо кто то хранил нафиг не нужный мусор с большим объемом в этом поле. И гоняя запросы, создавал нагрузку на сеть/диск/память...
6:50 неужели многие разработчики сносят папочки с сочетанием букв log чтобы просто очистить место? У нас такие люди называются не разработчиками, а другими словами.
Последний вопрос, то что я сам бы хотел задать, на кой хер делать очереди на постгресе? На постгресе очереди делают только на деве, чтобы дебажить легче было.
Послушал. Как говорится спасибо за доклад, но увы ничего нового не услышал кроме огромного количества обобщений. "Все разработчики хотят ... ", "нет такого админа который бы не пользовался ... ". У нас вот постгрес работает уже много лет, кластер, серьёзная наагрузка. Но высказанные обобщения на 90% - мимо. Никогда обозначенных желаний не возникало, почти ни одного из описанных эксцессов не случалось, разработчики ВСЕ знают основы работы с постгресом (вакуум, долгие транзакции и вот это всё), никто никогда не ковырялся руками в служебных каталогах не посмотрев что есть что. Хотя... мы и никогда не пользовались услугами консультантов. Сами консультировать можем если вопросы вот такие... ) И ещё в какой-то момент появилось очень много англицизмов, причём совершенно ненужных (для которых есть устоявшиеся русские термины) ещё и с неправильным произношением, . Сáппорт (вариант сáппортинг) - вообще слух режет. Ударение на второй слог на самом деле. И почему бы просто не сказать "поддержка"?
Это вообще что доклад для разработчиков? Да насрать разработчикам на место на диске . У него вообще нет доступа к проду. Вообще вы что это же все детские проблемы про них все давно известно .
у постгрес к сожалению имеется крайне отвратитеьное место, напрочь убивающее все его остальные преимущества. это крайне тупой и медленный движок, ничтожность которого приходится компенсировать крайне ненадежными (вопреки глупым заявлениям, ну просрете вы все свои данные не раз в год а раз в 2 года.) физическими устройствами типа ССД. для решения задач какого нибуть офиса на 5 компов пойдет.
у оряклы есть халевная версия. с обрезо по процам и памяти. для большинства бытовых задач с головой и выше хватает. но сам орякл не прост.@@vladislavstepanov7591
05:31 Планирование и мониторинг
18:20 про масштабирование
23:23 Про долгие транзакции
28:35 Про фоновые задачи
33:20 Автоматизация
37:35 Контейнеры и оркестрация
Отличный доклад, все в тему и без воды
Великолепный и полезнейший доклад! Спасибо!
Очень крутой. Приятно слушать, без воды, без соплей.
Толковый доклад, большое спасибо. Основная мысль, которую стоит отметить и вынести как вывод: надо понимать с чем и как работаешь.
Доклан оч крутой! а еще очень полезные вопросы и ответы на них, чуть ли лучший доклад с точки зрения вопросов-ответов
Отличный доклад, отличная манера изложения, все четко и по делу!
Для меня очень полезный доклад, спасибо)
Отличный спикер! Спасибо за выступление. Познавательно)
Алексей, спасибо, все очень упорядоченно и по полочкам
Интересный оратор, обязательно гляну ещё его лекции.
все четко и понятно, благодарю
Хороший доклад.
Ну наконец, что-то по делу сказал, тестировать и еще раз тестировать.
Вообще, советы подойдут, конечно, не только для постареса но и для любой субд
Ansible - это не головная боль, и не Bash на стероидах. Это очень удобный инструмент , не даром его забрал под крыло RedHat.
люто плюсую!
только вопрос насчет самописных очередей, PgQ - это же не про замену Redis и прочего? сорян за возможно некорректный вопрос, пока просто тегово знаком с терминами
Со Stolon работал как раз в связке с K8s, оч круто.
Ссылка на видео про мониторинг из этого видео:
ua-cam.com/video/Hbi2AFhd4nY/v-deo.html
Не могу понять как на 41 минуте, на слайде, может находиться ссылка на видео, которое опубликовано позже этого?
7:52 - Алексей, второго пришествия ещё не было. Фраза "второе пришествие" употребляется чтобы выразить отдаленное будущее.
волновался))
я при просмотре нашел еще пару моментов *рукалицо*
У меня вопрос про репликации. В одну базу пишем, с другой читаем. Но ведь сами базы должны постоянно реплицироваться, и это ведь тоже нагрузка на железо? И как часто они синхронизируют данные? Во т приложение записало данные пользователя, и тут же пытается их считать из другой базы, они там уже есть или будет в этот момент тормозить, пока данные обновятся во второй базе? Короче насколько репликации затратный процесс?
Если коротко отвечать, то зависит все от рабочей нагрузки на мастер. Если запросы хорошо оптимизированы, накладные расходы конечно есть, но незначительные
Не понял момент на 27 минуте - если приложение откроет транзацию, что-то запишет в базу, а потом крашнется - разве этой транзации не будет приозведен роллбэк автоматически?
не совсем так.
приложение открыло транзакцию, записало что-то в базу, затем не закрыв транзакцию решило обратиться к другой базе/api/etc... и если это обращение (не связанное с постгресом) завершилось с ошибкой и ошибку забыли обработать, то транзакция останется висеть т.к. с точки зрения работы с постгресом ошибки не было.
Про Postgres интересно, но про разработчиков странное мнение.
да, это конечно же субъективное мнение, возможно потому что я сам не являюсь разработчиком
@@alexeylesovsky2152 нормальное мнение. Когда ОРМ с 98 CRUD переписываешь на 8
Поясните, кто в курсе.. Если использовать поле типа JSON, то каждая запись этой таблицы будет занимать 8 Мб?
Нет, это был пример в начале доклада, типо кто то хранил нафиг не нужный мусор с большим объемом в этом поле. И гоняя запросы, создавал нагрузку на сеть/диск/память...
6:50 неужели многие разработчики сносят папочки с сочетанием букв log чтобы просто очистить место? У нас такие люди называются не разработчиками, а другими словами.
Отличный доклад. Но не могу найти видео про мониторинг, которое в докладе. Не могли бы ссылку прикрепить? Спасибо
ua-cam.com/video/Hbi2AFhd4nY/v-deo.html
Спасибо ))
ссылка на видео про мониторинг ua-cam.com/video/Hbi2AFhd4nY/v-deo.html
@@alexeylesovsky2152 Алексей, хочу выразить вам почтение - вы отличный докладчик :)
Последний вопрос, то что я сам бы хотел задать, на кой хер делать очереди на постгресе? На постгресе очереди делают только на деве, чтобы дебажить легче было.
Транзакционность, и низкие задержки
Оговорка на ua-cam.com/video/HjLnY0aPQZo/v-deo.html. Читатели не мешают писателям, а писатели - читателям.
А ну да DROP от DELETE наверно отличаются))))))))))))))))))
Ссылка на мониторинг ua-cam.com/video/Hbi2AFhd4nY/v-deo.html
Привет! Работаешь с Postgres?
Со второго пришествия😂может первого и до второго?😂
И под конец ломанулось неблагодарное безкультурное стадо...(
Послушал. Как говорится спасибо за доклад, но увы ничего нового не услышал кроме огромного количества обобщений. "Все разработчики хотят ... ", "нет такого админа который бы не пользовался ... ". У нас вот постгрес работает уже много лет, кластер, серьёзная наагрузка. Но высказанные обобщения на 90% - мимо. Никогда обозначенных желаний не возникало, почти ни одного из описанных эксцессов не случалось, разработчики ВСЕ знают основы работы с постгресом (вакуум, долгие транзакции и вот это всё), никто никогда не ковырялся руками в служебных каталогах не посмотрев что есть что. Хотя... мы и никогда не пользовались услугами консультантов. Сами консультировать можем если вопросы вот такие... )
И ещё в какой-то момент появилось очень много англицизмов, причём совершенно ненужных (для которых есть устоявшиеся русские термины) ещё и с неправильным произношением, . Сáппорт (вариант сáппортинг) - вообще слух режет. Ударение на второй слог на самом деле. И почему бы просто не сказать "поддержка"?
Это вообще что доклад для разработчиков? Да насрать разработчикам на место на диске . У него вообще нет доступа к проду. Вообще вы что это же все детские проблемы про них все давно известно .
у постгрес к сожалению имеется крайне отвратитеьное место, напрочь убивающее все его остальные преимущества. это крайне тупой и медленный движок, ничтожность которого приходится компенсировать крайне ненадежными (вопреки глупым заявлениям, ну просрете вы все свои данные не раз в год а раз в 2 года.) физическими устройствами типа ССД. для решения задач какого нибуть офиса на 5 компов пойдет.
А скажите, у Firebird 3.0 движок быстрее и умнее, чем у Постгреса или они сопоставимы?
А кто вам мешает взять оракл? Ой, а он платный
@@vladislavstepanov7591 ну настолько ли он круче, чтобы за него столько платить?
у оряклы есть халевная версия. с обрезо по процам и памяти. для большинства бытовых задач с головой и выше хватает. но сам орякл не прост.@@vladislavstepanov7591
ерундоаый доклад ни о чем и докладчик только по верхам знает, типа евангелиста