Да, но это мастер. Уже мы вынуждены делать фейловер. Причём после фейловера запросы смерти могут продолжать прилетать и класть теперь уже нового мастера. Но если имелось в виду что только 1 шард ложится то да, другие живут, если в них не прилетает такой же плохой запрос но с другими данными.
Делаем например запрос который приводит к seqscan на большой таблице, бд ложится, остальные сервисы не могут использовать бд. Т.е. один сервис ошибся и убил бд - ложатся все сервисы.
У вас в алгоритме GC есть проблема конкурентности. Проверка статуса и пометка/удаление происходит неатомарно так что можно потерять данные. Например кто-то вставляет чанк параллельно удалению такого же чанка, случай редкий но на вашем масштабе возможен.
GC посмотрел время последнего статуса, посмотрел что ссылок нет, далее параллельно идёт вставка новой ссылки на чанк, статус и его время меняется, gc делает удаление так как он не видел новую ссылку, данные потеряны. Тут надо атомарно проверять статус и удалить типа delete if version == vOld.
Раз уж данных много и пришлось шардировать то почему бы для этих данных не взять например Cassandra? Там уже всё украдено до нас, не надо вручную закатывать солнце.
Не очень новый подход на самом деле. См. например https://habr.com/ru/companies/jugru/articles/447308 раздел "Организация по модулям, а не слоям" (2019). И это наверняка не самый ранний источник. Только меняем ненавистный контроллер на минимал апи
Ну тут классическая анекдотичная ситуация "И вы говорите" Я скорее о том что столько читать и понимать в день очень сложно. А еще у него встречи наверное были и другие дела и он не чиллил с книжкой весь день на диване. Википедия того же мнения https://ru.wikipedia.org/wiki/Круг_чтения_Сталина#Режим_чтения
Причем забавно что автор с одной стороны смеётся над адептами заряженный воды а с другой свято верит что Сталин читал по 300-500 страниц в день (ещё и не художественной литературы)
Открыли, но запрос смерти мог прилететь более чем в одном экземпляре. В сумме получили больше чем есть ресурсов, бд ложится.
Да и в целом такой параметр не так то просто подобрать чтобы работало всегда
Да, но это мастер. Уже мы вынуждены делать фейловер. Причём после фейловера запросы смерти могут продолжать прилетать и класть теперь уже нового мастера. Но если имелось в виду что только 1 шард ложится то да, другие живут, если в них не прилетает такой же плохой запрос но с другими данными.
Делаем например запрос который приводит к seqscan на большой таблице, бд ложится, остальные сервисы не могут использовать бд. Т.е. один сервис ошибся и убил бд - ложатся все сервисы.
В одном сервисе накосячили с запросом, ложатся все
Можно сделать колонку и класть туда 64 битный "xmin здорового человека" используя txid_current()
Про перф наверное стрельнуть может какой нибудь цикл с логированием внутри. Например где-то в конце итерации всплыл Warn.
Идея прикольная но это не работает для всей распределенной трассировки. Ещё бывает надо копать сценарий когда нет Error'ов/Warn'ов.
В плане перфа вижу проблему что мы в ToString потенциально создаем большие строки которые могут засерать LOH
У вас в алгоритме GC есть проблема конкурентности. Проверка статуса и пометка/удаление происходит неатомарно так что можно потерять данные. Например кто-то вставляет чанк параллельно удалению такого же чанка, случай редкий но на вашем масштабе возможен.
GC посмотрел время последнего статуса, посмотрел что ссылок нет, далее параллельно идёт вставка новой ссылки на чанк, статус и его время меняется, gc делает удаление так как он не видел новую ссылку, данные потеряны. Тут надо атомарно проверять статус и удалить типа delete if version == vOld.
Имел честь проводить собеседования. Обычно кандидаты из таких вот госконтор являются очень слабыми, так что статья кажется не знает о чем говорит
Файлы в бд это конечно не бесит практис.
Наверное ещё можно было бы "шардировать" сайты на разные инстансы SharePoint (с ним не работал, не знаю)?
Не совсем понятно что плохого в репликации, это ведь ещё и дефолтная вещь для отказоустойчивости. Данное решение кажется очень сложным.
Раз уж данных много и пришлось шардировать то почему бы для этих данных не взять например Cassandra? Там уже всё украдено до нас, не надо вручную закатывать солнце.
На созвоне по удаленке обычно никто не держит руку у уха, не уверен что такая привычка существует
Скорее всего нет. Ишью давно висит. Там ответили что лучше не трогать а кому надо тот знает.
https://github.com/dotnet/roslyn/issues/20777#issuecomment-1379582634
Не очень новый подход на самом деле. См. например https://habr.com/ru/companies/jugru/articles/447308 раздел "Организация по модулям, а не слоям" (2019). И это наверняка не самый ранний источник. Только меняем ненавистный контроллер на минимал апи
Если ходить во время встреч то работать вполне возможно
Ну тут классическая анекдотичная ситуация "И вы говорите"
Я скорее о том что столько читать и понимать в день очень сложно. А еще у него встречи наверное были и другие дела и он не чиллил с книжкой весь день на диване. Википедия того же мнения
https://ru.wikipedia.org/wiki/Круг_чтения_Сталина#Режим_чтения
Причем забавно что автор с одной стороны смеётся над адептами заряженный воды а с другой свято верит что Сталин читал по 300-500 страниц в день (ещё и не художественной литературы)
В опере мобильной прекрасно всё работает. Ещё и блокировка рекламы есть
Все там меняется легко в настройках. Например https://operaru.ru/faq/how-to-change-search-engine-in-opera