В статье https://medium.com/nerd-for-tech/how-uber-handles-millions-of-ride-food-requests-efficiently-part-2-270f84d2c3c0 рассказывается о применении принципа Сага в Uber для организации сборных транзакций в NoSQL-базе данных, не поддерживающей транзакционность. И дана ссылка на описание самого принципа в https://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf. Там авторы рассказывают, что длинная транзакция, например бронирования перелёта с рядом пересадок, вовсе не обязана блокировать на всё своё время возможность выбрать место в выбранных клиентом самолётах. Эту возможность можно блокировать лишь на то время, когда клиент собственно сам выбирает очередное место. Пока выбирает - надо бы заблокировать другим выбрать место, чтоб не возникло ситуации, кода двое выбрали оно и то же. Но до того, когда начал и после того как выбрал, блокировка выбора мест другими клиентами в данном самолёте не нужна. Однако если он после откажется от затеи, занятое им место нужно будет таки освободить. Они предлагают такие длинные транзакции, которые могут быть разбиты на несколько под-транзакций, называть сагами. Они говорят, что такие саги можно делать, если для каждой под-транзакции регистрировать команды отката, компенсирующие изменения, сделанные откатываемой под-транзакцией (компенсирующая под-транзакция). И тогда, когда выяснится, что сагу нужно откатить, эти команды можно будет выполнить, и сага будет откачена. При этом, команды отката должны быть такими, чтоб их можно было выполнять даже если после выполнения под-транзакции база данных неоднократно менялась. Если это возможно для участвующих в процессе данных, то подход с сагами оказывается применим.
А мне тут подумалось накануне, что каждый эпизод работы с базой знаний (текстовым мозгом) должен быть чем-то вроде отдельной транзакции, чтоб его можно было откатить - точнее, не принимать во внимание в дальнейшем развитии этой базы. А ещё точнее, иметь возможность после развивать мозг как принимая во внимание этот эпизод, так и не принимая. Таким образом, после каждого подобного эпизода развитие мозга может идти по двум направлениям - через него, и мимо него. И линия развития мозга, таким образом, становится деревом разных итоговых состояний мозга, прошедшего через разные ветви эпизодов. Некий блокчейн выходит, где блок - это вот эпизод, но отброшенные блоки не обязательно отбрасывать окончательно, ибо целевых состояний можно разрешить более одного.
И кажется такой подход с эпизодами весьма похож на тот подход с сагами.
В статье https://medium.com/nerd-for-tech/how-uber-handles-millions-of-ride-food-requests-efficiently-part-2-270f84d2c3c0 рассказывается о применении принципа Сага в Uber для организации сборных транзакций в NoSQL-базе данных, не поддерживающей транзакционность. И дана ссылка на описание самого принципа в https://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf. Там авторы рассказывают, что длинная транзакция, например бронирования перелёта с рядом пересадок, вовсе не обязана блокировать на всё своё время возможность выбрать место в выбранных клиентом самолётах. Эту возможность можно блокировать лишь на то время, когда клиент собственно сам выбирает очередное место. Пока выбирает - надо бы заблокировать другим выбрать место, чтоб не возникло ситуации, кода двое выбрали оно и то же. Но до того, когда начал и после того как выбрал, блокировка выбора мест другими клиентами в данном самолёте не нужна. Однако если он после откажется от затеи, занятое им место нужно будет таки освободить. Они предлагают такие длинные транзакции, которые могут быть разбиты на несколько под-транзакций, называть сагами. Они говорят, что такие саги можно делать, если для каждой под-транзакции регистрировать команды отката, компенсирующие изменения, сделанные откатываемой под-транзакцией (компенсирующая под-транзакция). И тогда, когда выяснится, что сагу нужно откатить, эти команды можно будет выполнить, и сага будет откачена. При этом, команды отката должны быть такими, чтоб их можно было выполнять даже если после выполнения под-транзакции база данных неоднократно менялась. Если это возможно для участвующих в процессе данных, то подход с сагами оказывается применим.
А мне тут подумалось накануне, что каждый эпизод работы с базой знаний (текстовым мозгом) должен быть чем-то вроде отдельной транзакции, чтоб его можно было откатить - точнее, не принимать во внимание в дальнейшем развитии этой базы. А ещё точнее, иметь возможность после развивать мозг как принимая во внимание этот эпизод, так и не принимая. Таким образом, после каждого подобного эпизода развитие мозга может идти по двум направлениям - через него, и мимо него. И линия развития мозга, таким образом, становится деревом разных итоговых состояний мозга, прошедшего через разные ветви эпизодов. Некий блокчейн выходит, где блок - это вот эпизод, но отброшенные блоки не обязательно отбрасывать окончательно, ибо целевых состояний можно разрешить более одного.
И кажется такой подход с эпизодами весьма похож на тот подход с сагами.