Обычно должность таких разработчиков имеет префикс Principal или Expert.
После Senior есть еще две ступени с общепринятыми названиями Principal и Distinguished.
И да, вот эти двое обычно и аналитики, и архитекторы, и немного консультвнты вообще везде, их зовут на все принципиальные совещания по развитию продукта.
Нужно выдохнуть и воспользоваться колесиком прокрутки страницы. Процент таких людей высок везде; SO тут — просто отражение интернета в целом. И тратить на всех нервные клетки — ну его в баню. См. картинку из статьи выше.
В такой формулировке ее нет, да, признаю́, разумеется.
Я имел в виду, что в этом конкретном примере этот условный человек засунет карточку снова (в реальном мире это сделает machinery, которая инициировала транзакцию).
Корректный отказ — это штатная ситуация, которую просто обработать.
А, я понял, наконец: вы подозреваете, что я слыхом не слыхивал про CAP, а я по умолчанию считаю, что CP — это единственный вариант для финтеха, и рассказываю, исходя из того, что об этом мы договорились :)
Но я настаиваю: оно не встало при отказе мастера. Мы продолжаем принимать запросы и адекватно на них отвечаем (типа, 201 :). network split приводит ровно к тому же: мы считаем, что консенсуса нет и переходим в режим буферизации.
что подразумевает консистентность данных тут и сейчас
У нас, грубо говоря, база инкрементна, и консистентна в любой момент времени. Вся бизнес логика на конечных автоматах.
Отвалился мастер. Мы откатили все запущенные на тот момент транзакции и начали буферизовать запросы, вотэверитминз. Подключился slave failover. Воркеры начали разбирать очередь и применять изменения. Конкуретность решается автоматами: не наш черед — перешли в конец очереди. Мы так пережили уже два отказа мастера.
Да, если одну, грубо говоря, строку в RDBMS по дизайну могут менять сразу из пяти разных мест — это не вариант, но тут вопросы, скорее, к архитектуре.
Я не понимаю, почему при наличие backpressure и eventually consistent данных (спасибо за это уточнение, я подразумевал его, но не озвучил, да, мы работаем с вариантом EventLog’а) — мы будем зависеть от latency. В смысле, если речь не идет про очень специфический случай «highdump», когда нужно записывать терабайты в секунду, или настоящий real-time.
То, что общается с внешним миром просто буферизует данные (да, например replication slaves) и спокойно ждет подтверждения от slave. Я не вижу, как тут нарушается ACID. Может быть, что-то упускаю.
Гугл недополучает прибыль, мы получим убытки (в непредсказуемом размере), поэтому у нас как раз в приоритете full fault tolerance, fifteen nines, вот это все.
первую очередь надо смотреть сколько будет стоить отказ
Карта не работает — это не про 24/7. Транзакция началась и не закончилась — я про это.
У нас иногда случаются транзакции на €100M. Там за два часа только на курсе может полтора миллиона влегкую набежать, особенно с эзотерическими валютами. Это не катастрофа, но дешевле ее избегать, особенно учитывая, что транзакций может быть сто, или тысяча.
Я нигде не утверждал, что всем важно быть онлайн 24/7. Я озвучил дихотомию. Конечно, это дороже. Я ровно это и говорил: надо выбрать, за что платить: за 24/7 деньгами, или за минус два часа прибылью, именно так.
Бизнес очень быстро соглашается с тем что даунтайм в пару часов раз в год это фигня.
Зависит от того, какой бизнес. На какой-то конференции недавно был доклад change.org, они гордились тем, что на их нагрузке теряют менее полпроцента реквестов. У нас в финтехе — иногда один реквест потерял — и бизнесу хана.
для транзакционных БД нельзя получить одновременно полный fault tolerance при разумной latency операций
Средствами БД — невозможно, но если приложение хоть немного готово поспособствовать — вполне возможно. Запись идет через FIFO очередь, и при отказе мастера менеджер очереди приостанавливает операции, пока slave не возтмет управление.
Давайте все-таки определимся. Если для бизнеса не критично встать колом на пару дней — тогда бэкап — самое оно, никто не спорит. Оптимизация расходов, то-се.
Но если вдруг бизнесу почему-то важно быть онлайн 24/7, то или облако в разных регионах, или извините. Даже три часа простоя — для многих не вариант, а если вариант — то и два дня можно потерпеть. Тут все просто же.
Смешно :)
После Senior есть еще две ступени с общепринятыми названиями Principal и Distinguished.
И да, вот эти двое обычно и аналитики, и архитекторы, и немного консультвнты вообще везде, их зовут на все принципиальные совещания по развитию продукта.
Я нашел рецепт :)
Нужно выдохнуть и воспользоваться колесиком прокрутки страницы. Процент таких людей высок везде; SO тут — просто отражение интернета в целом. И тратить на всех нервные клетки — ну его в баню. См. картинку из статьи выше.
Чисто ради интереса: а как вы относитесь к Габриэлю Гарсии Лорке? А к Йозефу Гайдну?
И, совсем уже из другой области, но тоже интересно: а к Мондриану?
Маяковский вызвал бы на литературную дуэль.
Есенин бы нажрался в дрова.
Пушкин написал бы едкую эпиграмму.
Лермонтов уехал бы с горя на Кавказ.
Не за что :)
Тут бинарное состояние: или mission-critical, или нет. Если нет — можно и два дня повисеть; неприятно, но бывает, мир жесток.
Если mission-critical — то что два дня, что десять минут, что пять секунд — все одно и то же.
В такой формулировке ее нет, да, признаю́, разумеется.
Я имел в виду, что в этом конкретном примере этот условный человек засунет карточку снова (в реальном мире это сделает machinery, которая инициировала транзакцию).
Корректный отказ — это штатная ситуация, которую просто обработать.
«Я Пастернака, конечно, не читал, но осуждаю.»
Ну хорошо, на 10 минут. Какая разница-то?
Я там выше описал сценарий:
Timeout / Rejected. И эта операция буферизована не будет.
А, я понял, наконец: вы подозреваете, что я слыхом не слыхивал про CAP, а я по умолчанию считаю, что CP — это единственный вариант для финтеха, и рассказываю, исходя из того, что об этом мы договорились :)
Но я настаиваю: оно не встало при отказе мастера. Мы продолжаем принимать запросы и адекватно на них отвечаем (типа, 201 :). network split приводит ровно к тому же: мы считаем, что консенсуса нет и переходим в режим буферизации.
Кофе мне, что ли, еще испить?
У нас, грубо говоря, база инкрементна, и консистентна в любой момент времени. Вся бизнес логика на конечных автоматах.
Отвалился мастер. Мы откатили все запущенные на тот момент транзакции и начали буферизовать запросы, вотэверитминз. Подключился slave failover. Воркеры начали разбирать очередь и применять изменения. Конкуретность решается автоматами: не наш черед — перешли в конец очереди. Мы так пережили уже два отказа мастера.
Да, если одну, грубо говоря, строку в RDBMS по дизайну могут менять сразу из пяти разных мест — это не вариант, но тут вопросы, скорее, к архитектуре.
Я не понимаю, почему при наличие backpressure и eventually consistent данных (спасибо за это уточнение, я подразумевал его, но не озвучил, да, мы работаем с вариантом EventLog’а) — мы будем зависеть от latency. В смысле, если речь не идет про очень специфический случай «highdump», когда нужно записывать терабайты в секунду, или настоящий real-time.
То, что общается с внешним миром просто буферизует данные (да, например replication slaves) и спокойно ждет подтверждения от slave. Я не вижу, как тут нарушается ACID. Может быть, что-то упускаю.
Гугл недополучает прибыль, мы получим убытки (в непредсказуемом размере), поэтому у нас как раз в приоритете full fault tolerance, fifteen nines, вот это все.
Я ровно это и написал в первом же комментарии :)
Карта не работает — это не про 24/7. Транзакция началась и не закончилась — я про это.
У нас иногда случаются транзакции на €100M. Там за два часа только на курсе может полтора миллиона влегкую набежать, особенно с эзотерическими валютами. Это не катастрофа, но дешевле ее избегать, особенно учитывая, что транзакций может быть сто, или тысяча.
Если на пару часов приляжет любой из вышеозвученных — катастрофы не случится. Ну на реддите оживление будет — и все.
Есть еще варианты, когда blackout в 10 секунд — не вариант.
Я нигде не утверждал, что всем важно быть онлайн 24/7. Я озвучил дихотомию. Конечно, это дороже. Я ровно это и говорил: надо выбрать, за что платить: за 24/7 деньгами, или за минус два часа прибылью, именно так.
Зависит от того, какой бизнес. На какой-то конференции недавно был доклад change.org, они гордились тем, что на их нагрузке теряют менее полпроцента реквестов. У нас в финтехе — иногда один реквест потерял — и бизнесу хана.
Средствами БД — невозможно, но если приложение хоть немного готово поспособствовать — вполне возможно. Запись идет через FIFO очередь, и при отказе мастера менеджер очереди приостанавливает операции, пока slave не возтмет управление.
Давайте все-таки определимся. Если для бизнеса не критично встать колом на пару дней — тогда бэкап — самое оно, никто не спорит. Оптимизация расходов, то-се.
Но если вдруг бизнесу почему-то важно быть онлайн 24/7, то или облако в разных регионах, или извините. Даже три часа простоя — для многих не вариант, а если вариант — то и два дня можно потерпеть. Тут все просто же.
amarao (смею предположить) имел в виду, что облако — подразумевает разные регионы, репликацию, failover, наконец.
А шаред он там, или прям целый выделенный VDS — никакого значения не имеет, все равно это как пентиум три под столом.