Проблема в том что на сегодняшнем рынке устроиться джуном по вероятности равносильно срыву джекпота на миллионы $$$
Так он устраиваться идёт не джуном, а опытным разработчиком. А вместо себя уже отправляет работать возможно джунов. Сами бы они не справились, но он помогает советом. И вот
Это всё не новости. Но только если 10 приложений делают каждое по 10 соединений, через которые постоянно делаются запросы, им для работы нужно 100 живых соединений с постгресом. И если постгрес может обслуживать только, допустим 50 соединений, то чем тут поможет pgBouncer?
Если приложения нормально работают с коннекшнами, то когда они упрутся в лимиты БД, pgBouncer ничем не поможет. Потому что приложениям для нормальной работы всё равно нужно больше коннекшнов, чем им выдаёт база данных.
Ну разве что приложению никто не скажет, что соединение не удалось установить. Просто ответы на запросы начнут приходить гораздо медленнее, чем раньше.
Да впринципе такой режим работы, который нужен приложению, появился в pgBouncer года полтора назад. До этого вообще нельзя было использовать его для таких случаев. Я лично не уверен, что за полтора года получилось отловить все баги.
Как только у вас будет запущен не один процесс приложения, а сотня-другая, все это превратится в тыкву
Для того, чтобы всё превратилось в тыкву, нужно, чтобы приложение было написано откровенно плохо. Оно должно забирать соединение из коннекшн пула и не возвращать его туда как можно дольше, при этом не делая через это соединение запросов.
Придется иметь и то, и другое.
Для того, чтобы возникла такая необходимость, нужно, чтобы разработчики не понимали, как нужно работать с базой данных и при этом, чтобы используемый технологический стек не поддерживал автоматичекий возврать соединения в пул, когда соединение больше не нужно. Тогда да, придётся ((
Он не интегрирован в приложение. А в приложении нужен коннешн пул, для того, чтобы приложение не тратило время на установку соединения. Ведь даже если у вас есть pgBouncer, с ним тоже надо устанавливать соединение и его потом разрывать. А раз коннекшн пул в приложении всё равно будет, то зачем дополнительный pgBouncer
Единственное что этот процесс занял примерно лет десять, так как при этом нужно было сохранить обратную совместимость. Так что да, решили заимплементить, но это было не очень просто )))
Да, по смыслу похоже на это. Единственное что я не уверен, что в С# в ссылке на структуру не может быть null.
Плюс стереть границы между примитивными типами из коробки и тем, что пользователь может сделать сам. Плюс по-моему специализация дженериков там же прилагается.
Самые крутые заминусованные статьи давно удалены. Но можете прочитать вот эту заплюсованную статью и ответный комментарий на неё https://habr.com/ru/articles/335876/comments/#comment_10370454 . Комментарию поставили 51 минус. После этого автор опубликовал ответный пост. Там было минусов более двухсот ))
Насколько я понимаю, Школа 21 обучает профессии с нуля и если автор уже работал разработчиком, то что он делал в этой школе? Может быть обучался на менеджера?
В оффере написана должность Руководитель направления. Я лично знаю троих Руководителей направленяи из Сбера. Они разработчики уровня Мидл, руководством не занимаются, занимаются тем, что пишут код. Но может быть Руководитель направления это просто какой-то слот, чтобы указать зарплатную вилку, а по факту человек на этой позиции может даже прокладкой кабелей заниматься, не знаю.
Но вот ещё есть такой момент, что Руководитель направления это вроде 10 (десятый) грейд, а 12 (двенадцатый) это уже Исполнительный директор. Роль будет - АЙТИ лидер кластера или как-то так.
P. S. На всякий случай, я сам в Сбере не работаю, мои представления о внутренней системе сложились в результате общения с друзьями и знакомыми
И что, человека берут крутым менеджером и не могут две недели подождать
Тут странная штука. В оффере написано "Руководитель направления" по сберовской системе это разработчик уровня где-то мидл. Который будет писать код, а не руководить
Mysql, SQLServer ведут себя согласно Стандарту [в них будет грязное чтение на уровне изоляции READ UNCOMMITED]
Насколько я себе представляю, Стандарт требует, чтобы феноменов не было, но не требует, чтобы феномены обязательно воспроизводились на каких-то уровнях изоляции. Поэтому Postgresql тоже ведёт себя согласно Стандарту
Вы хотите сказать, что сейчас опытный разработчик даже не сможет попасть на собеседование?
Так он устраиваться идёт не джуном, а опытным разработчиком. А вместо себя уже отправляет работать возможно джунов. Сами бы они не справились, но он помогает советом. И вот
Речь о поддержке prepared statements . Вот про этот пул рекест
https://github.com/pgbouncer/pgbouncer/pull/845
Жалко, что вы не знаете, чем pgBouncer может помочь в такой ситуации. Если разберётесь, напишите, пожалуйста, я буду очень благодарен
Это всё не новости. Но только если 10 приложений делают каждое по 10 соединений, через которые постоянно делаются запросы, им для работы нужно 100 живых соединений с постгресом. И если постгрес может обслуживать только, допустим 50 соединений, то чем тут поможет pgBouncer?
Если приложения нормально работают с коннекшнами, то когда они упрутся в лимиты БД, pgBouncer ничем не поможет. Потому что приложениям для нормальной работы всё равно нужно больше коннекшнов, чем им выдаёт база данных.
Ну разве что приложению никто не скажет, что соединение не удалось установить. Просто ответы на запросы начнут приходить гораздо медленнее, чем раньше.
Да впринципе такой режим работы, который нужен приложению, появился в pgBouncer года полтора назад. До этого вообще нельзя было использовать его для таких случаев. Я лично не уверен, что за полтора года получилось отловить все баги.
Для того, чтобы всё превратилось в тыкву, нужно, чтобы приложение было написано откровенно плохо. Оно должно забирать соединение из коннекшн пула и не возвращать его туда как можно дольше, при этом не делая через это соединение запросов.
Для того, чтобы возникла такая необходимость, нужно, чтобы разработчики не понимали, как нужно работать с базой данных и при этом, чтобы используемый технологический стек не поддерживал автоматичекий возврать соединения в пул, когда соединение больше не нужно. Тогда да, придётся ((
Он не интегрирован в приложение. А в приложении нужен коннешн пул, для того, чтобы приложение не тратило время на установку соединения. Ведь даже если у вас есть pgBouncer, с ним тоже надо устанавливать соединение и его потом разрывать. А раз коннекшн пул в приложении всё равно будет, то зачем дополнительный pgBouncer
С вами сложно поспорить, но почему именно в 2? Интересно как вы это рассчитываете
Автор познал дзен?
А как насчёт проекта, где фигурная скобка, с которой начинается тело метода, находится на той же строке, что и названием метода?
Или проекта, в котором названия методов начинаются с маленькой буквы?
Ну или там, не знаю, где табами отступы надо делать? ))
Единственное что этот процесс занял примерно лет десять, так как при этом нужно было сохранить обратную совместимость. Так что да, решили заимплементить, но это было не очень просто )))
Да, по смыслу похоже на это. Единственное что я не уверен, что в С# в ссылке на структуру не может быть null.
Плюс стереть границы между примитивными типами из коробки и тем, что пользователь может сделать сам. Плюс по-моему специализация дженериков там же прилагается.
Самые крутые заминусованные статьи давно удалены. Но можете прочитать вот эту заплюсованную статью и ответный комментарий на неё https://habr.com/ru/articles/335876/comments/#comment_10370454 . Комментарию поставили 51 минус. После этого автор опубликовал ответный пост. Там было минусов более двухсот ))
Погодите. Траты Linux Foundation на разработку ядра это 2% от общих трат? Это как? Может тут ошибка какая-то?
Нет, Руководитель направления это должность, роль в команде может быть при это, например, разработчик
Уточнил, действительно так, спасибо
Странная получается история.
Насколько я понимаю, Школа 21 обучает профессии с нуля и если автор уже работал разработчиком, то что он делал в этой школе? Может быть обучался на менеджера?
В оффере написана должность Руководитель направления. Я лично знаю троих Руководителей направленяи из Сбера. Они разработчики уровня Мидл, руководством не занимаются, занимаются тем, что пишут код. Но может быть Руководитель направления это просто какой-то слот, чтобы указать зарплатную вилку, а по факту человек на этой позиции может даже прокладкой кабелей заниматься, не знаю.
Но вот ещё есть такой момент, что Руководитель направления это вроде 10 (десятый) грейд, а 12 (двенадцатый) это уже Исполнительный директор. Роль будет - АЙТИ лидер кластера или как-то так.
P. S. На всякий случай, я сам в Сбере не работаю, мои представления о внутренней системе сложились в результате общения с друзьями и знакомыми
Тут странная штука. В оффере написано "Руководитель направления" по сберовской системе это разработчик уровня где-то мидл. Который будет писать код, а не руководить
Насколько я понимаю, не подразумевает. Possible в английском означает, что что-то может произойти. но не обязательно.
Из-за MVCC в Постгресе как раз получается, что грязные чтения вообще никак производительность не увеличивают. Возможно даже уменьшают, не уверен.
Насколько я себе представляю, Стандарт требует, чтобы феноменов не было, но не требует, чтобы феномены обязательно воспроизводились на каких-то уровнях изоляции. Поэтому Postgresql тоже ведёт себя согласно Стандарту