Я вижу, ни на какие конкретные вопросы вы ответить не хотите, и ветка в оффтоп все-таки скатилась. Жаль-жаль... Было бы реально интересно узнать, в какую сумму оценивает свои убеждения столь непримиримый "борец с HR". Или противник "ИТ в РФ" вообще, выступающий на площадке, этим же "ИТ в РФ" порожденной?..
Нет, вы написали "чьи", а не "какие". Мне интересно, в какие конкретно суммы вы для себя оцениваете границу между "быть курьером-гастарбайтером" и "доход здесь, сейчас и сразу".
Понятно, что вся дальнейшая ветка - оффтоп, но мне даже интересно, что вы хотите увидеть, какие конкретно цифры и зачем. Даже если написать "джун без опыта получает миллион" - всегда можно найти пример курьера в Мск, который носит бриллианты в кейсе (а может и что-то еще) и получает два.
"Для молодых и здоровых есть более выгодные предложения" - это не про разработку, хотя есть и такие сферы, конечно.
Джун - это не только вложения человека в собственное развитие, но и компании в него. Но с позицией "доход здесь, сейчас и сразу" не может быть никакого развития, никаких взаимных долгосрочных инвестиций.
Зависит от реализации. Если все команды льются просто вперемешку в одно подключение, то блокировки будут самой мелкой из проблем, если запросы хоть чуть сложнее атомарных SELECT.
Если речь про pgbouncer, то в session mode - нет, каждому клиентскому подключению будет выдаваться свое серверное на все время. Если не забывать разблокировать свое - проблем не будет. В transaction mode - запросто при не-xact-функциях.
Разумно будет предпочесть hash, только если вы экономите место на диске - тут в лекции чуть подробнее. Во всех остальных случаях "умолчательный" btree будет не хуже.
Стандартная цитата разрабов и манагеров - "мы уперлись в СУБД". ... Почему, то считается, что если приложение тормозит надо портить нервы и стоять над душой у DBA ...
Это существующая, но порочная практика, увы.
"с СУБД аномалий нет , разбирайтесь с кривым приложением и проблемами инфраструктуры"
Это, правда, не менее порочная, с точки зрения бизнеса, которому важно "чтоб работало", а не "перевод стрелок".
Для исследования вопросов производительности приложения "в целом" правильно или команду специалистов собирать, или нужен "человек-оркестр"/performance engeneer, который проследит цепочку вызова от браузера через БЛ до БД и выявит конкретную проблему в конкретном месте.
В логах обновляемых данных нет, а в аналитике - есть.
"Золотой молоток"? Это пугает.
Мы не фанатики. Но сейчас у меня есть на руках инструмент для хорошего мониторинга/анализа работы PG, а для CH такого же по функционалу - нету. И усложнять клиентскую инфраструктуру для локального разворота нашего решения тоже не хочется.
В логах обновляемых данных нет, а в аналитике - есть.
"Золотой молоток"? Это пугает.
Мы не фанатики. Но сейчас у меня есть на руках инструмент для хорошего мониторинга/анализа работы PG, а для CH такого же по функционалу - нету. И усложнять клиентскую инфраструктуру для локального разворота нашего решения тоже не хочется.
У нас миллионы корпоративных аккаунтов. То есть потенциально неудачное решение может смасштабироваться на всех пользователей всех этих аккаунтов - тут за каждую миллисекунду имеет смысл биться, чтобы не завозить "железо" в ЦОД КАМАЗами.
удручающе низкий уровень разработки
Для его повышения я и пишу-пишу статьи - присоединяйтесь!
CH не особо заточен на обновляемые данных. У нас в общей инфраструктуре он тоже используется для некоторых задач, и у него есть и плюсы (я в курсе про *MergeTree-движки), и минусы, как и у любой СУБД.
Нам для анализа работы PG - пока не подошел. В том числе, и потому что наша собственная экспертиза в области PG, а не CH.
Тут нет параметра "бюджета" - в нашем случае это баланс между затратами на ФОТ разработки против затрат на оборудование.
Банальный пример: разработчик написал запрос к БД, но забыл сделать под него подходящий индекс. Это приводит к увеличению нагрузки по cpu, памяти, диску хоста, кол-ву вычитываемых/отфильтровываемых записей, вычитываемых страниц.
Можно вложить 100 рублей в выделение больших аппаратных ресурсов, а можно за 1 рубль заставить разработчика добавить индекс, после чего оценить изменение описанных выше метрик.
Возможностей в PG очень много - и применять их можно как с пользой, так и for fun. Например, можете еще позалипать над решателем "Небоскребов" или генератором лабиринтов.
А вы его отправляйте на анализ вместе с запросом - тогда нужные узлы будут увязаны с его элементами.
Используйте подходящий визуализатор планов.
Я уж не стал выносить комбинации условий в отдельный массив, который можно передать параметром извне... иначе даже для этого хаба будет чересчур.
Для комментария получилось многовато, оформил альтернативный вариант постом.
Потому что "написать программу для решения" - это тоже головоломка.
Я вижу, ни на какие конкретные вопросы вы ответить не хотите, и ветка в оффтоп все-таки скатилась. Жаль-жаль... Было бы реально интересно узнать, в какую сумму оценивает свои убеждения столь непримиримый "борец с HR". Или противник "ИТ в РФ" вообще, выступающий на площадке, этим же "ИТ в РФ" порожденной?..
Нет, вы написали "чьи", а не "какие". Мне интересно, в какие конкретно суммы вы для себя оцениваете границу между "быть курьером-гастарбайтером" и "доход здесь, сейчас и сразу".
Понятно, что вся дальнейшая ветка - оффтоп, но мне даже интересно, что вы хотите увидеть, какие конкретно цифры и зачем. Даже если написать "джун без опыта получает миллион" - всегда можно найти пример курьера в Мск, который носит бриллианты в кейсе (а может и что-то еще) и получает два.
"Для молодых и здоровых есть более выгодные предложения" - это не про разработку, хотя есть и такие сферы, конечно.
Джун - это не только вложения человека в собственное развитие, но и компании в него. Но с позицией "доход здесь, сейчас и сразу" не может быть никакого развития, никаких взаимных долгосрочных инвестиций.
Зависит от реализации. Если все команды льются просто вперемешку в одно подключение, то блокировки будут самой мелкой из проблем, если запросы хоть чуть сложнее атомарных SELECT.
LIMIT 1 + обязательное наличие индекса
Если речь про pgbouncer, то в session mode - нет, каждому клиентскому подключению будет выдаваться свое серверное на все время. Если не забывать разблокировать свое - проблем не будет. В transaction mode - запросто при не-xact-функциях.
Такая конструкция выполняет WHERE-условие до первой найденной (т.е. на которую смогла-таки наложиться блокировка) записи, точнее, ее ID.
Разумно будет предпочесть hash, только если вы экономите место на диске - тут в лекции чуть подробнее. Во всех остальных случаях "умолчательный" btree будет не хуже.
Это существующая, но порочная практика, увы.
Это, правда, не менее порочная, с точки зрения бизнеса, которому важно "чтоб работало", а не "перевод стрелок".
Для исследования вопросов производительности приложения "в целом" правильно или команду специалистов собирать, или нужен "человек-оркестр"/performance engeneer, который проследит цепочку вызова от браузера через БЛ до БД и выявит конкретную проблему в конкретном месте.
В логах обновляемых данных нет, а в аналитике - есть.
Мы не фанатики. Но сейчас у меня есть на руках инструмент для хорошего мониторинга/анализа работы PG, а для CH такого же по функционалу - нету. И усложнять клиентскую инфраструктуру для локального разворота нашего решения тоже не хочется.
В логах обновляемых данных нет, а в аналитике - есть.
Мы не фанатики. Но сейчас у меня есть на руках инструмент для хорошего мониторинга/анализа работы PG, а для CH такого же по функционалу - нету. И усложнять клиентскую инфраструктуру для локального разворота нашего решения тоже не хочется.
У нас миллионы корпоративных аккаунтов. То есть потенциально неудачное решение может смасштабироваться на всех пользователей всех этих аккаунтов - тут за каждую миллисекунду имеет смысл биться, чтобы не завозить "железо" в ЦОД КАМАЗами.
Для его повышения я и пишу-пишу статьи - присоединяйтесь!
CH не особо заточен на обновляемые данных. У нас в общей инфраструктуре он тоже используется для некоторых задач, и у него есть и плюсы (я в курсе про *MergeTree-движки), и минусы, как и у любой СУБД.
Нам для анализа работы PG - пока не подошел. В том числе, и потому что наша собственная экспертиза в области PG, а не CH.
Тут нет параметра "бюджета" - в нашем случае это баланс между затратами на ФОТ разработки против затрат на оборудование.
Банальный пример: разработчик написал запрос к БД, но забыл сделать под него подходящий индекс. Это приводит к увеличению нагрузки по cpu, памяти, диску хоста, кол-ву вычитываемых/отфильтровываемых записей, вычитываемых страниц.
Можно вложить 100 рублей в выделение больших аппаратных ресурсов, а можно за 1 рубль заставить разработчика добавить индекс, после чего оценить изменение описанных выше метрик.