А как выполнить миграцию базы данных postgres старой версии zabbix на новую? А то я один раз это сделал и оказалось, что новая версия сервера zabbix падала, потому что в новой версии базы данных postgres требовалось на какое-то поле ограничение NOT NULL и значение по умолчанию в этом поле, а в старой версии сервера zabbix этих условий не требовалось.
На вашем сайте в документации сказано - цитата "Вышеупомянутые функции выполняет кластерное ПО для СУБД Postgres Pro такое, как Patroni от Zalando." Я так понимаю, что Вами используется решение Patroni от Zalando.
Идеального мира не существует. Курсы - это в первую очередь коммерция. Рассчитывать на курсы - это скажем дообучение. В первую очередь необходимы базовые знания с широкими горизонтами, естественные науки, умение решать задачи, не те, что-то типа ЕГЭ, а те новые задачи, когда надо что-то придумывать. То что заказчик не знает чего хочет, это нормально и не надо от него, что-то требовать, какой-то конкретики. Вы должны сами предлагать и даже не предлагать (потому что заказчик все равно ничего не поймет), а решать задачу и показывать ему результат. Вот когда появится результат, тогда и начнется то обсуждения и понимание чего хочет заказчик, возможно даже придется всё переделать. Хорошо когда Вы сможете работу разделить на роли, но этому тоже надо учится организовывать людей, создавать конвейер. Но для этого надо много чего знать и постоянно обучаться, обмениваться опытом и не рассчитывать на курсы. Это приходит с опытом. Главное не боятся браться за задачи, которые еще не знаете, как решать.
1.Есть уже достаточно давно выпущенная книга Е.Рогов "Postgesql изнутри", в которой вся механики расписана достаточно подробно. Данная стать по-сути является дублем. 2.Было сказано, что операция UPDATE будут увеличивать объем физической памяти, но не было сказано, что если настроен VACUUM, то увеличение объема может и не быть вообще, за счет переиспользования освободившегося пространства, либо до некоторого размера объем увеличится, в дальше стабилизируется. 3.На счёт изменения производительности при длинных цепочках, не сказано на сколько это критично, если это какие-то доли секунд (мили, микросекунд), по отношение к общему времени выполнения запроса, то стоит ли на это вообще обращать внимание.
1.В PostgreSQL есть конфигурационнык параметры для настройки планировщика запроса. Некоторые из них учитывают конфигурацию железа. Насколько правильно проводить сравнительный анализ без тонкой настройки под конфигурацию железа является один из вопросов. 2.Как было отмечено, статья методически выдержана с точки зрения проведения исследований. Но не хватает оценки практической ценности проведенного исследования.
Почему для отечественного продукта документация сначала создается на английском, а потом переводится на русский язык, а не наоборот? Внешний рынок в приоритете?
1.Есть ряд обучающих материалов по изоляции транзакций за авторством Е.Рогова, например, https://habr.com/ru/company/postgrespro/blog/442804/. 2.В этих материалах автор предостерегает от ошибок связанных, с тем что в одном запросе идет проверка, а в другом запросе по результатам проверки, осуществляются действия с этой записью. Автор считает такой подход антипаттерном, т.к. между двумя этими запросами в параллельном потоке эта запись может быть изменена.
В статье сказано, что "Файлы журнализации нужны для того, чтобы обеспечить работоспособность реляционных баз данных в терминах ACID. Напомню, что ACID — это набор свойств реляционной базы данных, которые гарантируют в том числе надёжность транзакции". В соответствии с документацией файлы журнала прежде всего существуют для безопасного восстановления после краха сервера.
Правильно, ли я понимаю, что количество версий строк зависит, от интенсивности обновления строки и настроек автовакуума? И если это так, то при одной версии строки (вставили строку и после не было обновлений и удаления этой строки) речь о корреляции вообще не должна идти, потому что не с чем коррелировать, т.е. нет версий строк?
"Ситуация с доступом к таблице меняется, когда корреляция оказывается низкой. Создадим индекс по столбцу book_date, имеющему практически нулевую корреляцию с индексом, и посмотрим на запрос, выбирающий приблизительно ту же долю строк, что и в предыдущем примере. Индексный доступ оказывается настолько дорогим (56957 против 4639 в хорошем случае), что планировщик выбирает его, только если запретить ему все альтернативы"
Не совсем ясно, почему такая высокая стоимость. Правильно ли я понимаю, что такая ситуация может возникнуть, если для одной строки имеется достаточно большое количество версий строк, разбросанных по разным страницам и процедура очистки не выполнялась. Если выполнить очистку, то стоимость снизится до "хорошего случая".
А как выполнить миграцию базы данных postgres старой версии zabbix на новую? А то я один раз это сделал и оказалось, что новая версия сервера zabbix падала, потому что в новой версии базы данных postgres требовалось на какое-то поле ограничение NOT NULL и значение по умолчанию в этом поле, а в старой версии сервера zabbix этих условий не требовалось.
1.Как обеспечивается репликация, когда хранение файлов осуществляется в базе данных. Как это влияет на производительность?
2. СУБД работает с файлами на сервере, как загрузить файл в базу данных с клиентской машины?
На вашем сайте в документации сказано - цитата "Вышеупомянутые функции выполняет кластерное ПО для СУБД Postgres Pro такое, как Patroni от Zalando."
Я так понимаю, что Вами используется решение Patroni от Zalando.
Система отказоустойчивых кластеров - это самостоятельная разработка или в основу положены существующие решения, например, patroni?
Идеального мира не существует. Курсы - это в первую очередь коммерция. Рассчитывать на курсы - это скажем дообучение. В первую очередь необходимы базовые знания с широкими горизонтами, естественные науки, умение решать задачи, не те, что-то типа ЕГЭ, а те новые задачи, когда надо что-то придумывать. То что заказчик не знает чего хочет, это нормально и не надо от него, что-то требовать, какой-то конкретики. Вы должны сами предлагать и даже не предлагать (потому что заказчик все равно ничего не поймет), а решать задачу и показывать ему результат. Вот когда появится результат, тогда и начнется то обсуждения и понимание чего хочет заказчик, возможно даже придется всё переделать. Хорошо когда Вы сможете работу разделить на роли, но этому тоже надо учится организовывать людей, создавать конвейер. Но для этого надо много чего знать и постоянно обучаться, обмениваться опытом и не рассчитывать на курсы. Это приходит с опытом. Главное не боятся браться за задачи, которые еще не знаете, как решать.
1.Есть уже достаточно давно выпущенная книга Е.Рогов "Postgesql изнутри", в которой вся механики расписана достаточно подробно. Данная стать по-сути является дублем.
2.Было сказано, что операция UPDATE будут увеличивать объем физической памяти, но не было сказано, что если настроен VACUUM, то увеличение объема может и не быть вообще, за счет переиспользования освободившегося пространства, либо до некоторого размера объем увеличится, в дальше стабилизируется.
3.На счёт изменения производительности при длинных цепочках, не сказано на сколько это критично, если это какие-то доли секунд (мили, микросекунд), по отношение к общему времени выполнения запроса, то стоит ли на это вообще обращать внимание.
Можно дождаться фиксации транзакции, выполнить запрос данных и отправить их в брокер, а сам брокер разошлет данные всем подписчикам.
Интересно, как Олег Бартунов совмещает контрибьютерство и руководство компанией?
Интересно это коммерческий продукт или альтруистический?
1.В PostgreSQL есть конфигурационнык параметры для настройки планировщика запроса. Некоторые из них учитывают конфигурацию железа. Насколько правильно проводить сравнительный анализ без тонкой настройки под конфигурацию железа является один из вопросов.
2.Как было отмечено, статья методически выдержана с точки зрения проведения исследований. Но не хватает оценки практической ценности проведенного исследования.
Почему для отечественного продукта документация сначала создается на английском, а потом переводится на русский язык, а не наоборот? Внешний рынок в приоритете?
Насколько быстрее в итоге прошла миграция базы данных? Вы так и не сказали.
Интересно, как сочетается pgbouncer и подготовленные запросы?
+1
1.Есть ряд обучающих материалов по изоляции транзакций за авторством Е.Рогова, например, https://habr.com/ru/company/postgrespro/blog/442804/.
2.В этих материалах автор предостерегает от ошибок связанных, с тем что в одном запросе идет проверка, а в другом запросе по результатам проверки, осуществляются действия с этой записью. Автор считает такой подход антипаттерном, т.к. между двумя этими запросами в параллельном потоке эта запись может быть изменена.
В статье сказано, что
"Файлы журнализации нужны для того, чтобы обеспечить работоспособность реляционных баз данных в терминах ACID. Напомню, что ACID — это набор свойств реляционной базы данных, которые гарантируют в том числе надёжность транзакции".
В соответствии с документацией файлы журнала прежде всего существуют для безопасного восстановления после краха сервера.
Дополнительно, раз уж пошла речь про особенности работы с NULL, то есть видео
https://www.youtube.com/watch?v=2qTczke77q4
Правильно, ли я понимаю, что количество версий строк зависит, от интенсивности обновления строки и настроек автовакуума? И если это так, то при одной версии строки (вставили строку и после не было обновлений и удаления этой строки) речь о корреляции вообще не должна идти, потому что не с чем коррелировать, т.е. нет версий строк?
А что понимается под термином "версия табличной строки"? Это связано с MVCC?
"Ситуация с доступом к таблице меняется, когда корреляция оказывается низкой. Создадим индекс по столбцу
book_date, имеющему практически нулевую корреляцию с индексом, и посмотрим на запрос, выбирающий приблизительно ту же долю строк, что и в предыдущем примере. Индексный доступ оказывается настолько дорогим (56957 против 4639 в хорошем случае), что планировщик выбирает его, только если запретить ему все альтернативы"Не совсем ясно, почему такая высокая стоимость. Правильно ли я понимаю, что такая ситуация может возникнуть, если для одной строки имеется достаточно большое количество версий строк, разбросанных по разным страницам и процедура очистки не выполнялась. Если выполнить очистку, то стоимость снизится до "хорошего случая".