Two-phase commit allows transactions to be "prepared" on several computers, and once all computers have successfully prepared their transactions (none failed), all transactions can be committed. Even if a machine crashes after a prepare, the prepared transaction can be committed after the machine is restarted. New syntax includes PREPARE TRANSACTION and COMMIT/ROLLBACK PREPARED. A new system view pg_prepared_xacts has also been added.
сделали eventual consistency постоянным режимом, хотя она должна включаться только при сетевых сбоях,
А проблема в том, что ты ДО начала транзакции должен знать - нужна ли её консистентность или нет, ждем ли подтвержение кворума для коммита или нет? А сетевые сбои они такие - непредсказуемые.
Это не моя больная фантазия, это реальность отечественных корпораций. Там пиар-отделам все еще ставят план по числу публикаций в год с упоминанием компании. Знаете, кто еще очень любил планы, а потом распался?
И вас уже все лежит в базе, и данные и процедура и оркестратор. Осталось положить туда конфигурацию и все будет вместе и синхронно. А все эти внешние файлы - это всегда точка отказа для любой базы
ну и как? если в реальности надо выбрать - инвестиции в 5g или в новые дороги с мостами, или может в зп преподавателей, или может в космическую программу, ну или может в новые стадионы?. И то и то и то и то полезно, но ресурсы всегда ограничены. Суть в сравнении, определить пользу в цифрах
я работаю как раз архитектором в большой компании. Но честно говоря код-ревью занимаюсь очень редко. Это задача тимлидов. От архитектора требуется нарисовать архитектуру и продать ее бизнесу.
Вопрос в том, как данной таксономией воспользоваться.
да очень просто. Вот делаешь ты систему бронирования билетов в кино(поезд, отель и т.д.) и думаешь. А ведь пользователи-то могут паралельно одно и тоже забукать, вот беда. Что же делать? Ну и тут приходи на ум эта статья: ба, так вариантов всего три, или оптимистиная блокировка (двое выбрали место, потом думают, потом кто раньше оплатил тот молодец, остальные получают ошибку и отваливаются) или пессимистичная - (кто первый выбрал место, то для остальных оно уже недоступно, так что второй увидит надпись - "мест нет". Хотя они могут потом и появится, т.к. блок снимится если не будет оплаты в течении получаса. Ну или третий вариант (кто поледний тот и получил билет) но для реального букинга это конечно не серьезно. ибо первый приедет в аэропорт, а ему - "извините, ваш билет продали другому, не повезло"
все просто, олимпиада - это спорт. А любой спорт он к реальной жизни применения мало находит. Тем не менее популярность спорта сейчас супер высока. Ну и проблема допинга в спорте была, есть и будет
а ассемблер в топ 20?
Архитектор в принципе может вообще код не писать. На практике это дай бог 20%.
Ну еще есть архитекторские должности. Я вот часто работаю архитектором на проекте вообще формально без подчиненных,
а в постгрес двухфазный комит подвезли в 8-й версии
нет еще в 2000- лохматом году у mssql субд был Failover Clustering с полным acid и и двухфазными коммитами внутри субд, без всяких application layer
Ну да, так и есть. Это вообще называется двухфазный комит, и он существует уже лет 30 как в разных в субд
А проблема в том, что ты ДО начала транзакции должен знать - нужна ли её консистентность или нет, ждем ли подтвержение кворума для коммита или нет? А сетевые сбои они такие - непредсказуемые.
про маркетинг все уже сказано у классиков:
https://www.youtube.com/watch?v=MZFIZOei4Gw
И вас уже все лежит в базе, и данные и процедура и оркестратор. Осталось положить туда конфигурацию и все будет вместе и синхронно. А все эти внешние файлы - это всегда точка отказа для любой базы
Хранить справочник или конфигурацию в таблице гораздо лучше чем в файле
Теги: bigdata
ну и как? если в реальности надо выбрать - инвестиции в 5g или в новые дороги с мостами, или может в зп преподавателей, или может в космическую программу, ну или может в новые стадионы?. И то и то и то и то полезно, но ресурсы всегда ограничены. Суть в сравнении, определить пользу в цифрах
такой же результат будет и при оптимистичном варианте блокировок. Если пока ты думал, кто-то другой быстрее этот же билет оплатил
я работаю как раз архитектором в большой компании. Но честно говоря код-ревью занимаюсь очень редко. Это задача тимлидов. От архитектора требуется нарисовать архитектуру и продать ее бизнесу.
а как наука может пользу определить? Если это не экономика
ну здрасьте
нет. это все от типа личности зависит: оптимист ты, пессимист, ну или пох...ист
ну справедливости ради, овербукинг это всегда ОСОЗНАННОЕ бизнес решение владельцев бизнеса для увеличения прибыли. А не выбор программиста
да очень просто. Вот делаешь ты систему бронирования билетов в кино(поезд, отель и т.д.) и думаешь. А ведь пользователи-то могут паралельно одно и тоже забукать, вот беда. Что же делать? Ну и тут приходи на ум эта статья: ба, так вариантов всего три, или оптимистиная блокировка (двое выбрали место, потом думают, потом кто раньше оплатил тот молодец, остальные получают ошибку и отваливаются) или пессимистичная - (кто первый выбрал место, то для остальных оно уже недоступно, так что второй увидит надпись - "мест нет". Хотя они могут потом и появится, т.к. блок снимится если не будет оплаты в течении получаса. Ну или третий вариант (кто поледний тот и получил билет) но для реального букинга это конечно не серьезно. ибо первый приедет в аэропорт, а ему - "извините, ваш билет продали другому, не повезло"
все просто, олимпиада - это спорт. А любой спорт он к реальной жизни применения мало находит. Тем не менее популярность спорта сейчас супер высока. Ну и проблема допинга в спорте была, есть и будет