Если погиб по омм то гарантия не нарушается. Я про то что у нас могут возникать оба кейса и один из них решается большим таймаутом, а другой наоборот небольшим. В реальности встречаются оба кейса так что придётся выбирать какой из них для нас наименее значим
Тут уже будет трейдофф между "делаем большой таймаут == возможный долгий даунтайм, например если конзюмер погиб по ООМ" vs "гарантия нарушается" и придётся выбирать из двух зол.
Ох уж эта важная гарантия обработки партиции не более чем одним конзюмером, которая не является гарантией и будет довольно регулярно стрелять в ноги программистам. Чего только не придумали в кафке чтобы оно было почти гарантией, но распределенные системы не обманешь. Sad, but true. Тут надо интеграцию с системой хостинга чтобы кафка могла точно-точно прибивать старых конзюмеров и только тогда запускать новых. Ну или с помощью версии лидерства над партицией бороться со старыми конзюмерами.
Самое грустное когда люди ошибочно считают что кафка даёт эту гарантию и потом пишут код, полагаюсь на неё, ну а далее возникают различные весёлые кейсы, после которых очень приятно ночью сидеть на онколле.
Я не уверен что мы можем настолько гранулярно ограничивать во всех бд, например в постгресе. При этом могут существовать какие-нибудь демоны которые делают жирные запросы и у них лимиты завышены. В целом если на уровне одного инстанс бд мы можем хорошо ограничить то это не будет сильно отличаться, сэкономим ресурсы. Способ через отдельные инстансы будет работать для любых бд, даже если они сами не умеют управлять потреблением ресурсов
Надо делать оценку при проектировании, провести нагрузочное тестирование, взять с запасом. Ну и мониторить как оно в проде, когда надо добавить ресурсов. Тут главное что у нас в итоге будет изоляция бдшек сервисов друг от друга. Какие-то сервисы могут быть не критичными. Если такой сервис сильно нагрузит бд то и хрен с ним, зато не случилось такое что упало вообще всё.
Наверное оно не прям ложится так как в постгресе на каждое соединение свой процесс и если что упадёт он а не главный процесс бд. Но можно просто выжрать всю память так что дальше бд не сможет обслуживать другие запросы. Получится ситуация не сильно отличающаяся от состояния "бд упала"
А никто и не говорит что оно внезапно перестанет падать. Просто теперь при проблеме в одном сервисе лежит только этот сервис а не все сервисы системы вместе. В этом и есть выгода
Я уже отвечал на вопрос про ограничения ресурсов на сеанс. Не так просто подобрать нужные значения чтобы они работали во всех случаях, приложение ещё и развивается/меняется. И даже если мы это сделали то "сеансов" с плохим запросом может оказаться много так что суммарно они скушают все доступные ресурсы.
Причём тут "соединения стали тормозить"? Плохой запрос на то плохой что он не просто тормозит но и утилизирует кучу ресурсов, например оперативную память и диск. При этом в какой то момент могут быть утилизированы все доступные серверу бд ресурсы. В этом случае это не повлияет на остальных клиентов бд?
Да, но это мастер. Уже мы вынуждены делать фейловер. Причём после фейловера запросы смерти могут продолжать прилетать и класть теперь уже нового мастера. Но если имелось в виду что только 1 шард ложится то да, другие живут, если в них не прилетает такой же плохой запрос но с другими данными.
Делаем например запрос который приводит к seqscan на большой таблице, бд ложится, остальные сервисы не могут использовать бд. Т.е. один сервис ошибся и убил бд - ложатся все сервисы.
Если погиб по омм то гарантия не нарушается. Я про то что у нас могут возникать оба кейса и один из них решается большим таймаутом, а другой наоборот небольшим. В реальности встречаются оба кейса так что придётся выбирать какой из них для нас наименее значим
Тут уже будет трейдофф между "делаем большой таймаут == возможный долгий даунтайм, например если конзюмер погиб по ООМ" vs "гарантия нарушается" и придётся выбирать из двух зол.
Ох уж эта важная гарантия обработки партиции не более чем одним конзюмером, которая не является гарантией и будет довольно регулярно стрелять в ноги программистам. Чего только не придумали в кафке чтобы оно было почти гарантией, но распределенные системы не обманешь. Sad, but true. Тут надо интеграцию с системой хостинга чтобы кафка могла точно-точно прибивать старых конзюмеров и только тогда запускать новых. Ну или с помощью версии лидерства над партицией бороться со старыми конзюмерами.
Самое грустное когда люди ошибочно считают что кафка даёт эту гарантию и потом пишут код, полагаюсь на неё, ну а далее возникают различные весёлые кейсы, после которых очень приятно ночью сидеть на онколле.
Я не уверен что мы можем настолько гранулярно ограничивать во всех бд, например в постгресе. При этом могут существовать какие-нибудь демоны которые делают жирные запросы и у них лимиты завышены. В целом если на уровне одного инстанс бд мы можем хорошо ограничить то это не будет сильно отличаться, сэкономим ресурсы. Способ через отдельные инстансы будет работать для любых бд, даже если они сами не умеют управлять потреблением ресурсов
Надо делать оценку при проектировании, провести нагрузочное тестирование, взять с запасом. Ну и мониторить как оно в проде, когда надо добавить ресурсов. Тут главное что у нас в итоге будет изоляция бдшек сервисов друг от друга. Какие-то сервисы могут быть не критичными. Если такой сервис сильно нагрузит бд то и хрен с ним, зато не случилось такое что упало вообще всё.
Наверное оно не прям ложится так как в постгресе на каждое соединение свой процесс и если что упадёт он а не главный процесс бд. Но можно просто выжрать всю память так что дальше бд не сможет обслуживать другие запросы. Получится ситуация не сильно отличающаяся от состояния "бд упала"
С помощью технологий виртуализации/контейнеризации наверное
А никто и не говорит что оно внезапно перестанет падать. Просто теперь при проблеме в одном сервисе лежит только этот сервис а не все сервисы системы вместе. В этом и есть выгода
Я уже отвечал на вопрос про ограничения ресурсов на сеанс. Не так просто подобрать нужные значения чтобы они работали во всех случаях, приложение ещё и развивается/меняется. И даже если мы это сделали то "сеансов" с плохим запросом может оказаться много так что суммарно они скушают все доступные ресурсы.
Никто не утверждал что от одного запроса.
Причём тут "соединения стали тормозить"? Плохой запрос на то плохой что он не просто тормозит но и утилизирует кучу ресурсов, например оперативную память и диск. При этом в какой то момент могут быть утилизированы все доступные серверу бд ресурсы. В этом случае это не повлияет на остальных клиентов бд?
Почитайте рядом, уже обсуждали. Несколько клиентов могут сделать плохой запрос. Например забыли добавить индекс для новой функциональности
Потому что упали по оом например
Ок. Не знаком с таким термином. Там получается что у нас эта реплика ограничена по ресурсами и не повлияет на других?
Тогда это уже не shared database, а речь шла про неё
Ну тогда мы сначала одного мастера кладём а потом так как он упал мы переключаемся на другого и кладём его)
Открыли, но запрос смерти мог прилететь более чем в одном экземпляре. В сумме получили больше чем есть ресурсов, бд ложится.
Да и в целом такой параметр не так то просто подобрать чтобы работало всегда
Да, но это мастер. Уже мы вынуждены делать фейловер. Причём после фейловера запросы смерти могут продолжать прилетать и класть теперь уже нового мастера. Но если имелось в виду что только 1 шард ложится то да, другие живут, если в них не прилетает такой же плохой запрос но с другими данными.
Делаем например запрос который приводит к seqscan на большой таблице, бд ложится, остальные сервисы не могут использовать бд. Т.е. один сервис ошибся и убил бд - ложатся все сервисы.
В одном сервисе накосячили с запросом, ложатся все