Устроиться в корпорацию где 200 тысяч сотрудников или больше... Кстати можно, это же как раз будет российская армия. Вот только вместо компьютера вам там дадут что-то другое. :) Но можете попробовать. Курсор и процедура не прокатит. В таких задачах на собеседовании использование процедур запрещают, надо уложиться в один запрос. Так это специально было сделано, чтобы все данные были в памяти. Машина 128 ОЗУ, shared_buffers 32GB, все в памяти с большим запасом. Ведь идея была в том, чтобы проверить алгоритмы, а не то, как работает с винчестерами postgres в виртуалке под виндой.
Это не поправочка, а придирочка. Да, в DDL последнее слово означает language, т.е. язык. Использовать ddl для обозначения запросов задающих структуру данных - обычный жаргон.
Вы правы. Если не заморачиваться над оптимизацией именно этого запроса (а смысл собеседования был именно в том, чтобы заморочиться, чтобы написать его "правильным и крутым") и специального индекса не создавать, то индекс по department_id как по foreign key там должен быть, обычная практика.
Можно, чего только не сделаешь для любимых читателей: method | execution_time --------+-------------------- rank | 0.7331189993619919 max | 0.5216920003294945 window | 0.6920570016503335 Хм, опять, чтобы пройти собеседование и устроиться на работу, надо предложить самое худшее решение. Да что такое-то?
Ну так в этом и есть обратная сила собеседования. Узнаешь еще и какой начальник, насколько разумный. :) Что же касается ваших предложений по расчёту сотрудников с максимальной зарплатой в отделе, так задачу не я придумал. Сами предложите это на собеседовании.
Вы правы. Похоже по старости лет я перепутал. Это же получается, 30 лет назад всё было. Да, берётся среднеарифметическое и среднеквадратичное отклонение. Для нормального распределения две трети попадает в сигму. https://old.mipt.ru/upload/medialibrary/111/main.pdf RMS тоже употребляется в физике, но в другом контексте.
11 версия вышла в 2018м году. т.е. 6 лет назад. :) Вы неправильно себе представляете процесс разработки. Разработкой занимается не одна могущественная корпорация со строгими корпоративными стандартами качества. Это Open Source, в котором участвуют как несколько корпораций, так и обычные любители. Так что всё что вы считаете обязательным, совсем не обязательно. Что-нибудь сделать и забыть задокументировать так это вообще обычное дело. Но работа ведётся и каждый может внести свой вклад. И может быть не совсем прямым путём, но в целом PostgreSQL движется в лучшую сторону.
Хм, кстати, хороший вопрос. Тут смотря кто где и на кого учился. Большинство учились только в школе и брать среднее арифметическое для них естественно, никакие P05 или P50 они не знают. Я учился на физика в МФТИ и поэтому для меня естественно было бы взять среднеквадратичное (меня учили, что только так правильно). Но среди агрегатных функций PostgreSQL я не нашел функцию которая вычисляет среднеквадратичное или по английский Root mean square (RMS). Поэтому, за неимением лучшего, я беру среднее арифметическое, всё равно эти эксперименты не несут в себе какого-то научного значения, скорее они служат для оценки, что лучше/хуже. И с этим вполне себе справляются. Были бы там случайные выбросы, то при 1000 замерах они бы всё равно сгладились бы.
Именно эту ссылку я и привел в своей статье. Про сами операторы там ничего. А это и означает, что они таинственные. Ясность вы внесли, но не совсем понятно, чем эти операторы лучше/хуже, чем обычные, но с COLLATION "'C". Нет, не достаточно. Я читал ваши статьи про индексы в PostgreSQL, очень хорошие. Так что не останавливайтесь. :)
То что он оказался быстрее, выяснили только сейчас. А про операторы ~>=~ и ~<~ благодаря которым они работает быстрее, до сих пор ничего не известно. В то же время в ChangeLog было заявлено, что starts_with() и индекс SP Gist гораздо эффективнее, чем LIKE и btree. Так что ваше утверждение, что "все знают" уже не верно. И в будущем может быть неверно. Вот если устроюсь в Postgres Pro, может перепишу starts_with(). :) Как появляются "упоминания в документации", это не так работает. :) Если смотреть документацию на сайте, внизу есть форма отправить ваши предложения и замечания. Их реально читают, правда не всегда реагируют. Так что документация к PostgreSQL настолько хороша (искренне, я не видел тех.документации лучше), потому что это результат коллективного труда и с фидбэком от читателей.
Смущает. Сложная система с рутовым доступом написанная веб программистами. :) Чего вы хотели? Я старался обращать на это внимание, например цитата из моей статьи:
Я думал о том, чтобы список таких пользователей оформить в виде параметра. Технически это возможно. Но есть опасность, потому что тогда пользователь, обладающий правами редактировать конфигурацию Zabbix, сможет настроить так, что начнёт видеть запросы от суперпользователя. Поэтому список нежелательных пользователей прописан в коде в конфигурационном файле в UserParameter, и изменить его может только сисадмин с правами редактирования этого файла (обычно root) на этом сервере.
Печально. Раньше аргументировали своё решение тем, что оно "быстро и надёжно", сейчас тем что "модно и молодёжно". Ну типа штанов с промежностью на уровне колен. И все эти танцы с бубнами и определение таблиц через java annotation чтобы было кому отвечать на http запросы. На которые уже можно повесить JS интерфейс. Получается если научить SQL сервер напрямую отвечать на http запросы, какой-нибудь бездумный плагин, который бы автоматический конвертил http в SQL и обратно, то все эти модно-молодёжные технологии будут не нужны. Можно будет по старинке писать процедуры, которые работают внутри транзакций.
Хочу поблагодарить вас за ваши комментарии. Это сподвигло меня еще раз поискать способ, как сделать так чтобы и ошибок не было и чтобы база нулями не забивалась для бездействующих баз данных. И, оказалось, в Zabbix есть этот функционал, сложность была только его найти. Шаблон в конце статьи переписал на новую версию.
А, это не баг, а фича. Я писал об этом в статье. Сейчас напишу еще раз, подробнее. Конечно, всегда есть запросы в любую базу, например от заббикс, но я же их отрезаю. Поэтому, если в базе нет нагрузки, то и запросов в pg_stat_statements нет. И данные при запросе не возвращаются в заббикс. Тут есть два варианта, как тут поступить. Один из них - как реализовали вы, вставлять в таком случае пустые значения вместо текстовых данных и 0 вместо цифровых. В этом случае база заббикса будет заполняться строчками содержащими нули и пустоту для простаивающих баз. Второй вариант, это оставлять такие данные null, которые заббикс не понимает и выдает ошибку. Но в таком случае строчки в заббикс попросту не появляются. Такое будет для тех "простаивающих баз" у которых в течении суток не было ни одного запроса. Например базы postgres. Идеальным было бы найти такое значение для этого случая, чтобы и сообщений об ошибке не было и ненужные строчки в базе заббикса не возникали. Мне мой вариант показался предпочтительнее, чтобы сэкономить место в и так большой базе данных заббикса. Но если это вам портит ощущение прекрасного, можете исправлять. Нет нужды это править в SQL запросе, он всегда отрабатывает нормально и там вы можете выскочить за предел максимальной длины запроса. И нормально все это попадает в json поле. Можете временно включить его запись в историю, чтобы видеть, как он выглядит. Ошибки возникают в depended item, которые забирают данные из json и преобразуют в числа. Если бы такое делал я, то я бы это делал где-то в разделе preprocessing у соответствующих item.
Смотрите <аргументы...> подразумевает, что их может быть несколько. :) А может быть ни одного. В custom query такой же механизм как и в UserParameters. Может быть любое количество аргументов, которые потом подставляются в нужные места запроса.
Обратите внимание. Вот есть два мнения. У нас базы данных для общего пользования ставятся на железе. Конечно, если нужно было тестировать какую-то экзотику, я ставил их у себя в виртуалках. И я могу свидетельствовать о том, что базы работают стабильно если не годами, то точно месяцами, пока не будут перезагружены, например, для обновления или изменения конфига (добавить модули). Да, бывают проблемы с ошибками веб программистов, но сам postgresql работает стабильно, без нареканий. (За исключением ранних 9.6 версий). А есть второе мнение, о том как это хорошо и правильно ставить их в виртуалках. И этот же самый сисадмин сетует, что якобы PostgreSQL "заблокировал все записи" и "захапал коннекты", хотя postgresql захапать коннекты никак не может. Если только речь не идет о связи между двумя БД, типа логической репликации, fdw, dblink и т.д. Такое совпадение, что PostgreSQL работает нестабильно именно у того сисадмина, который считает правильным ставить его в виртуалках, говорит о том что проблема вовсе не в PostgreSQL, а либо в виртуалке либо в сисадмине. Highly likely последнее, потому что по симптомам больше похоже на тривиальную жопорукость. У нас было что-то вроде дублирования сетевых пакетов в Кубернетис, но тут другое.
Поставил дизлайк. Потому что все ваши аргументы построены на демагогии и оскорблении личности. Ничего, буквально ни одного аргумента вы не привели, который стоило бы обсудить. Все что вы написали характеризуется вашими же словами "Типичный бессознательный бред". Сплошные эмоции, без капли здравого смысла. Например фраза "Буквально неделю назад 15.4 остановил все записи, нахапал коннекшнов до лимита, и его пришлось убивать ручками." говорит о том, что вы в принципе не понимаете ни того как работает база данных, ни то как надо диагностировать или исправлять ошибки. Это не сервер PostgreSQL "хапает" коннешины, а наоборот, приложение. Вы даже не поняли что является источником проблемы, как следствие даже не пытались обнаружить её и исправить. И проблема с коннекшинами, точно такая же, ждёт вас еще не раз. И главный ваш талант это врать начальству, что это виноваты не вы, а PostgreSQL. Видимо, пока у вас это делать получается. И раз вы не понимаете даже такие элементарные вещи, то эта статья не для вас. Обратите внимание, что уровень сложности выставлен как "сложный".
А так вы сейчас пишите про девелоперовский контур. Тут я вас поддерживаю, кстати. Я считаю что у каждого разработчика должна быть своя БД для отлаживания разработки. И я себе всегда такую делал. Впрочем и от общих баз данных для разработки тоже есть польза, в них объединяется труд разных разработчиков и окончательно проверяется перед выкаткой в продакшин. И с них я делал себе копию, если разрабатывал что-то своё. А основная идея этой стати была в том, что бы такой мониторинг повесить именно что на продакшин с целью чтобы у разработчиков был доступ к информации о проблемах производительности и проблемных запросах на продакшине.
Типичная манипуляция общественным сознанием, использование слово "совковый", хотя оно тут совершенно неприемлемо. Современные средства виртуализации и конвейнеризации настолько глючные, что большинство поломок приходится именно на них. Сам по себе PostgreSQL очень стабилен и с самим PostgreSQL как с софтом никогда не бывает проблем, если только он не размещен на средствах виртуализации и конвейнеризации. Более того. Отказоустойчивость веб сервисов основана на том, что в самих контейнерах не должно быть никакой информации относящейся к состоянию системы. Прочитайте, это в любом учебнике написано. Поэтому в случае выхода одного контейнера из строя или узла, легко можно поднять запасной. Это достигается как раз тем, что вся информация о состоянии системы находится в базах данных, например на базе PostgreSQL, а вот они находятся как раз не в контейнерах и их отказоустойчивость достигается другими методами. Плюс потери производительности при виртуализации. Про потерю надежности уже говорил. Ну и, конечно, вопрос денег. Если молятся на модную микросервисную архитектуру это означает что баз данных очень много, но они небольшие и по сложности и по объему. У нас в компании несколько сотен баз данных. Арендовать под каждую виртуалку на точке обмена трафиком это еще и накладно, как по деньгам, так и по потерям производительности. Базы на железных машинах.
Впервые использовал этот тип данных. А использование random() для заполнения имён людей вас не смущает?
Устроиться в корпорацию где 200 тысяч сотрудников или больше... Кстати можно, это же как раз будет российская армия. Вот только вместо компьютера вам там дадут что-то другое. :) Но можете попробовать.
Курсор и процедура не прокатит. В таких задачах на собеседовании использование процедур запрещают, надо уложиться в один запрос.
Так это специально было сделано, чтобы все данные были в памяти. Машина 128 ОЗУ, shared_buffers 32GB, все в памяти с большим запасом. Ведь идея была в том, чтобы проверить алгоритмы, а не то, как работает с винчестерами postgres в виртуалке под виндой.
Это не поправочка, а придирочка. Да, в DDL последнее слово означает language, т.е. язык. Использовать ddl для обозначения запросов задающих структуру данных - обычный жаргон.
Вы правы. Если не заморачиваться над оптимизацией именно этого запроса (а смысл собеседования был именно в том, чтобы заморочиться, чтобы написать его "правильным и крутым") и специального индекса не создавать, то индекс по department_id как по foreign key там должен быть, обычная практика.
Можно, чего только не сделаешь для любимых читателей:
method | execution_time
--------+--------------------
rank | 0.7331189993619919
max | 0.5216920003294945
window | 0.6920570016503335
Хм, опять, чтобы пройти собеседование и устроиться на работу, надо предложить самое худшее решение. Да что такое-то?
Ну так в этом и есть обратная сила собеседования. Узнаешь еще и какой начальник, насколько разумный. :)
Что же касается ваших предложений по расчёту сотрудников с максимальной зарплатой в отделе, так задачу не я придумал. Сами предложите это на собеседовании.
Вы правы. Похоже по старости лет я перепутал. Это же получается, 30 лет назад всё было. Да, берётся среднеарифметическое и среднеквадратичное отклонение. Для нормального распределения две трети попадает в сигму.
https://old.mipt.ru/upload/medialibrary/111/main.pdf
RMS тоже употребляется в физике, но в другом контексте.
11 версия вышла в 2018м году. т.е. 6 лет назад. :) Вы неправильно себе представляете процесс разработки. Разработкой занимается не одна могущественная корпорация со строгими корпоративными стандартами качества. Это Open Source, в котором участвуют как несколько корпораций, так и обычные любители. Так что всё что вы считаете обязательным, совсем не обязательно. Что-нибудь сделать и забыть задокументировать так это вообще обычное дело. Но работа ведётся и каждый может внести свой вклад. И может быть не совсем прямым путём, но в целом PostgreSQL движется в лучшую сторону.
Хм, кстати, хороший вопрос. Тут смотря кто где и на кого учился. Большинство учились только в школе и брать среднее арифметическое для них естественно, никакие P05 или P50 они не знают. Я учился на физика в МФТИ и поэтому для меня естественно было бы взять среднеквадратичное (меня учили, что только так правильно). Но среди агрегатных функций PostgreSQL я не нашел функцию которая вычисляет среднеквадратичное или по английский Root mean square (RMS). Поэтому, за неимением лучшего, я беру среднее арифметическое, всё равно эти эксперименты не несут в себе какого-то научного значения, скорее они служат для оценки, что лучше/хуже. И с этим вполне себе справляются. Были бы там случайные выбросы, то при 1000 замерах они бы всё равно сгладились бы.
Именно эту ссылку я и привел в своей статье. Про сами операторы там ничего. А это и означает, что они таинственные. Ясность вы внесли, но не совсем понятно, чем эти операторы лучше/хуже, чем обычные, но с COLLATION "'C".
Нет, не достаточно. Я читал ваши статьи про индексы в PostgreSQL, очень хорошие. Так что не останавливайтесь. :)
То что он оказался быстрее, выяснили только сейчас. А про операторы ~>=~ и ~<~ благодаря которым они работает быстрее, до сих пор ничего не известно. В то же время в ChangeLog было заявлено, что starts_with() и индекс SP Gist гораздо эффективнее, чем LIKE и btree. Так что ваше утверждение, что "все знают" уже не верно. И в будущем может быть неверно. Вот если устроюсь в Postgres Pro, может перепишу starts_with(). :)
Как появляются "упоминания в документации", это не так работает. :) Если смотреть документацию на сайте, внизу есть форма отправить ваши предложения и замечания. Их реально читают, правда не всегда реагируют. Так что документация к PostgreSQL настолько хороша (искренне, я не видел тех.документации лучше), потому что это результат коллективного труда и с фидбэком от читателей.
Смущает. Сложная система с рутовым доступом написанная веб программистами. :) Чего вы хотели? Я старался обращать на это внимание, например цитата из моей статьи:
Я думал о том, чтобы список таких пользователей оформить в виде параметра. Технически это возможно. Но есть опасность, потому что тогда пользователь, обладающий правами редактировать конфигурацию Zabbix, сможет настроить так, что начнёт видеть запросы от суперпользователя. Поэтому список нежелательных пользователей прописан в коде в конфигурационном файле в UserParameter, и изменить его может только сисадмин с правами редактирования этого файла (обычно root) на этом сервере.
Печально. Раньше аргументировали своё решение тем, что оно "быстро и надёжно", сейчас тем что "модно и молодёжно". Ну типа штанов с промежностью на уровне колен. И все эти танцы с бубнами и определение таблиц через java annotation чтобы было кому отвечать на http запросы. На которые уже можно повесить JS интерфейс. Получается если научить SQL сервер напрямую отвечать на http запросы, какой-нибудь бездумный плагин, который бы автоматический конвертил http в SQL и обратно, то все эти модно-молодёжные технологии будут не нужны. Можно будет по старинке писать процедуры, которые работают внутри транзакций.
Хочу поблагодарить вас за ваши комментарии. Это сподвигло меня еще раз поискать способ, как сделать так чтобы и ошибок не было и чтобы база нулями не забивалась для бездействующих баз данных. И, оказалось, в Zabbix есть этот функционал, сложность была только его найти. Шаблон в конце статьи переписал на новую версию.
И возможно вы не прочитали мой предыдущий ответ. 6 параметров это нормально и ошибки выдавать не должно. :)
А, это не баг, а фича. Я писал об этом в статье. Сейчас напишу еще раз, подробнее. Конечно, всегда есть запросы в любую базу, например от заббикс, но я же их отрезаю. Поэтому, если в базе нет нагрузки, то и запросов в pg_stat_statements нет. И данные при запросе не возвращаются в заббикс. Тут есть два варианта, как тут поступить. Один из них - как реализовали вы, вставлять в таком случае пустые значения вместо текстовых данных и 0 вместо цифровых. В этом случае база заббикса будет заполняться строчками содержащими нули и пустоту для простаивающих баз. Второй вариант, это оставлять такие данные null, которые заббикс не понимает и выдает ошибку. Но в таком случае строчки в заббикс попросту не появляются. Такое будет для тех "простаивающих баз" у которых в течении суток не было ни одного запроса. Например базы postgres. Идеальным было бы найти такое значение для этого случая, чтобы и сообщений об ошибке не было и ненужные строчки в базе заббикса не возникали.
Мне мой вариант показался предпочтительнее, чтобы сэкономить место в и так большой базе данных заббикса. Но если это вам портит ощущение прекрасного, можете исправлять. Нет нужды это править в SQL запросе, он всегда отрабатывает нормально и там вы можете выскочить за предел максимальной длины запроса. И нормально все это попадает в json поле. Можете временно включить его запись в историю, чтобы видеть, как он выглядит. Ошибки возникают в depended item, которые забирают данные из json и преобразуют в числа. Если бы такое делал я, то я бы это делал где-то в разделе preprocessing у соответствующих item.
Смотрите <аргументы...> подразумевает, что их может быть несколько. :) А может быть ни одного. В custom query такой же механизм как и в UserParameters. Может быть любое количество аргументов, которые потом подставляются в нужные места запроса.
Обратите внимание. Вот есть два мнения. У нас базы данных для общего пользования ставятся на железе. Конечно, если нужно было тестировать какую-то экзотику, я ставил их у себя в виртуалках. И я могу свидетельствовать о том, что базы работают стабильно если не годами, то точно месяцами, пока не будут перезагружены, например, для обновления или изменения конфига (добавить модули). Да, бывают проблемы с ошибками веб программистов, но сам postgresql работает стабильно, без нареканий. (За исключением ранних 9.6 версий).
А есть второе мнение, о том как это хорошо и правильно ставить их в виртуалках. И этот же самый сисадмин сетует, что якобы PostgreSQL "заблокировал все записи" и "захапал коннекты", хотя postgresql захапать коннекты никак не может. Если только речь не идет о связи между двумя БД, типа логической репликации, fdw, dblink и т.д. Такое совпадение, что PostgreSQL работает нестабильно именно у того сисадмина, который считает правильным ставить его в виртуалках, говорит о том что проблема вовсе не в PostgreSQL, а либо в виртуалке либо в сисадмине. Highly likely последнее, потому что по симптомам больше похоже на тривиальную жопорукость. У нас было что-то вроде дублирования сетевых пакетов в Кубернетис, но тут другое.
Поставил дизлайк. Потому что все ваши аргументы построены на демагогии и оскорблении личности. Ничего, буквально ни одного аргумента вы не привели, который стоило бы обсудить. Все что вы написали характеризуется вашими же словами "Типичный бессознательный бред". Сплошные эмоции, без капли здравого смысла. Например фраза "Буквально неделю назад 15.4 остановил все записи, нахапал коннекшнов до лимита, и его пришлось убивать ручками." говорит о том, что вы в принципе не понимаете ни того как работает база данных, ни то как надо диагностировать или исправлять ошибки. Это не сервер PostgreSQL "хапает" коннешины, а наоборот, приложение. Вы даже не поняли что является источником проблемы, как следствие даже не пытались обнаружить её и исправить. И проблема с коннекшинами, точно такая же, ждёт вас еще не раз. И главный ваш талант это врать начальству, что это виноваты не вы, а PostgreSQL. Видимо, пока у вас это делать получается.
И раз вы не понимаете даже такие элементарные вещи, то эта статья не для вас. Обратите внимание, что уровень сложности выставлен как "сложный".
А так вы сейчас пишите про девелоперовский контур. Тут я вас поддерживаю, кстати. Я считаю что у каждого разработчика должна быть своя БД для отлаживания разработки. И я себе всегда такую делал. Впрочем и от общих баз данных для разработки тоже есть польза, в них объединяется труд разных разработчиков и окончательно проверяется перед выкаткой в продакшин. И с них я делал себе копию, если разрабатывал что-то своё.
А основная идея этой стати была в том, что бы такой мониторинг повесить именно что на продакшин с целью чтобы у разработчиков был доступ к информации о проблемах производительности и проблемных запросах на продакшине.
Типичная манипуляция общественным сознанием, использование слово "совковый", хотя оно тут совершенно неприемлемо. Современные средства виртуализации и конвейнеризации настолько глючные, что большинство поломок приходится именно на них. Сам по себе PostgreSQL очень стабилен и с самим PostgreSQL как с софтом никогда не бывает проблем, если только он не размещен на средствах виртуализации и конвейнеризации.
Более того. Отказоустойчивость веб сервисов основана на том, что в самих контейнерах не должно быть никакой информации относящейся к состоянию системы. Прочитайте, это в любом учебнике написано. Поэтому в случае выхода одного контейнера из строя или узла, легко можно поднять запасной. Это достигается как раз тем, что вся информация о состоянии системы находится в базах данных, например на базе PostgreSQL, а вот они находятся как раз не в контейнерах и их отказоустойчивость достигается другими методами.
Плюс потери производительности при виртуализации. Про потерю надежности уже говорил. Ну и, конечно, вопрос денег. Если молятся на модную микросервисную архитектуру это означает что баз данных очень много, но они небольшие и по сложности и по объему. У нас в компании несколько сотен баз данных. Арендовать под каждую виртуалку на точке обмена трафиком это еще и накладно, как по деньгам, так и по потерям производительности. Базы на железных машинах.