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