Тяжело воспринимать статью, т.к. отсутствуют единицы измерений для характеристик, как на графике, так и в тексте.Не описаны сами характеристики, например, что такое "Точка наблюдения".
Странное распределение ответственности. Например, я разработчик, спроектировал базу данных, создал таблицу, в которую запихал все справочники организации, общий размер несколько терабайт, и потом прихожу к админу и предъявляю претензию, что-то у тебя база тормозит, когда я хочу получить, какой-то справочник. Т.е. админ несет ответственность за конструктивные ошибки разработчика.
Первый вопрос. Не понятно, в чём именно помощь админу от этого инструмента. Приведенный пример я так понял, что какой-то админ запустил REINDEX, а другой админ это выявил. Одни админы следят за другими админами? Второй вопрос. Если СУБД висит не по причине блокировок, а по причине загрузки процессора или ввода/вывода. Как тогда ответить на вопрос "Ваша база висела и мы не могли работать, разберитесь". Третий вопрос. Если управлением блокировок занимаются прикладные программисты, которые не достаточно глубоко понимают внутреннее устройство и в этой связи возникают проблемы. То тогда вопрос, как организована ревью кода прежде чем, это использовать в эксплуатации?
А как выполнить миграцию базы данных postgres старой версии zabbix на новую? А то я один раз это сделал и оказалось, что новая версия сервера zabbix падала, потому что в новой версии базы данных postgres требовалось на какое-то поле ограничение NOT NULL и значение по умолчанию в этом поле, а в старой версии сервера zabbix этих условий не требовалось.
На вашем сайте в документации сказано - цитата "Вышеупомянутые функции выполняет кластерное ПО для СУБД Postgres Pro такое, как Patroni от Zalando." Я так понимаю, что Вами используется решение Patroni от Zalando.
Идеального мира не существует. Курсы - это в первую очередь коммерция. Рассчитывать на курсы - это скажем дообучение. В первую очередь необходимы базовые знания с широкими горизонтами, естественные науки, умение решать задачи, не те, что-то типа ЕГЭ, а те новые задачи, когда надо что-то придумывать. То что заказчик не знает чего хочет, это нормально и не надо от него, что-то требовать, какой-то конкретики. Вы должны сами предлагать и даже не предлагать (потому что заказчик все равно ничего не поймет), а решать задачу и показывать ему результат. Вот когда появится результат, тогда и начнется то обсуждения и понимание чего хочет заказчик, возможно даже придется всё переделать. Хорошо когда Вы сможете работу разделить на роли, но этому тоже надо учится организовывать людей, создавать конвейер. Но для этого надо много чего знать и постоянно обучаться, обмениваться опытом и не рассчитывать на курсы. Это приходит с опытом. Главное не боятся браться за задачи, которые еще не знаете, как решать.
1.Есть уже достаточно давно выпущенная книга Е.Рогов "Postgesql изнутри", в которой вся механики расписана достаточно подробно. Данная стать по-сути является дублем. 2.Было сказано, что операция UPDATE будут увеличивать объем физической памяти, но не было сказано, что если настроен VACUUM, то увеличение объема может и не быть вообще, за счет переиспользования освободившегося пространства, либо до некоторого размера объем увеличится, в дальше стабилизируется. 3.На счёт изменения производительности при длинных цепочках, не сказано на сколько это критично, если это какие-то доли секунд (мили, микросекунд), по отношение к общему времени выполнения запроса, то стоит ли на это вообще обращать внимание.
1.В PostgreSQL есть конфигурационнык параметры для настройки планировщика запроса. Некоторые из них учитывают конфигурацию железа. Насколько правильно проводить сравнительный анализ без тонкой настройки под конфигурацию железа является один из вопросов. 2.Как было отмечено, статья методически выдержана с точки зрения проведения исследований. Но не хватает оценки практической ценности проведенного исследования.
Почему для отечественного продукта документация сначала создается на английском, а потом переводится на русский язык, а не наоборот? Внешний рынок в приоритете?
Тяжело воспринимать статью, т.к. отсутствуют единицы измерений для характеристик, как на графике, так и в тексте.Не описаны сами характеристики, например, что такое "Точка наблюдения".
В чем преимущество Вашего подхода по сравнению с восстановление на заданный момент времени штатным подходом и после этого восстановить данные?
Я именно так и делал. Но дело в том, что новая версия zabbix использует другую структуру базы данных. В этом то и проблема.
Насколько я понял из статьи, что архив создается после порчи данных. Если это так, то тогда не понятно, как получить данные до их порчи.
Странное распределение ответственности. Например, я разработчик, спроектировал базу данных, создал таблицу, в которую запихал все справочники организации, общий размер несколько терабайт, и потом прихожу к админу и предъявляю претензию, что-то у тебя база тормозит, когда я хочу получить, какой-то справочник. Т.е. админ несет ответственность за конструктивные ошибки разработчика.
Первый вопрос. Не понятно, в чём именно помощь админу от этого инструмента. Приведенный пример я так понял, что какой-то админ запустил REINDEX, а другой админ это выявил. Одни админы следят за другими админами?
Второй вопрос. Если СУБД висит не по причине блокировок, а по причине загрузки процессора или ввода/вывода. Как тогда ответить на вопрос "Ваша база висела и мы не могли работать, разберитесь".
Третий вопрос. Если управлением блокировок занимаются прикладные программисты, которые не достаточно глубоко понимают внутреннее устройство и в этой связи возникают проблемы. То тогда вопрос, как организована ревью кода прежде чем, это использовать в эксплуатации?
Речь о другом, не как поднять версию postgres, а как перенести базу данных для новой версии zabbix. Причем здесь апгрейд. Попробую еще раз объяснить. Есть старая версия zabbix, которая работает со своей версией postgres и база данных заточена под старую версию zabbix. Теперь я беру новую версию zabbix, которая работает с новой версией postgres. Вопрос, как перенести старую схему и данные в новую схему базы данных? Новая версия zabbix работает на новой схеме базы данных. А то что схема поменялась, я обозначил в самом начале.Вот ссылка на bugs - https://support.zabbix.com/browse/ZBX-26998?_gl=1*j7sk07*_gcl_au*MTQzMTQ4NTIwNy4xNzU4MDIxNjE3*_ga*MTM2NjY3Mjk2Ni4xNzQyMzk1MDcw*_ga_1F6WJN99ZG*czE3NjUyOTQxMDYkbzIyJGcxJHQxNzY1Mjk0MjMxJGo1NiRsMCRoMA..
А как выполнить миграцию базы данных 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 и подготовленные запросы?