Исправление aist1, (текущая версия) :
Потому что система и ее утилиты написаны на C/C++, и потому программировать такую систему будет очень сложно.
Потому что есть зависимости по данным. И чем более мелкие шарды ты делаешь, тем больше у тебя влияние высоколатентных каналов связи и дорогостоящих протоколов распределенных транзакций.
Примерно как Virtual DOM в React.js, ЕВПОЧЯ.
Я понимаю, о чем ты. Ты понимаешь, что ФСД не являются lock-free в строгом смысле? В самом лучшем случае там будет куча блокировок/атомиков в сборщике мусора. Ты можешь реализовать распределенный сборщик мусора на идемпотентных распределенных атомарных счетчиках, но это уже довольно большое пространство разделяемого состояния. И уж ты точно не можешь реализовать распределенный децентрализованный сборщик мусора. По организационным соображениям.
Ну и в большинстве случаев тебе понадобится блокировка (строгая консистентность) на «голове» истории, как минимум. Если не на всей истории версий.
Все преимущество ФСД/ПСД в том, что как только новая версия создана, дальше вся работа будет идти уже в wait-free режиме, т.е. вообще без блокировок и атомиков до самого коммита, а данные версий могут свободно кэшироваться как угодно, потому что они иммутабельные. Но работа воркеров с историей требует транзакций. Метаданные версий должны становиться известными воркерам, и тут без транзакций не обойтись.
А так — да. Я даже такую распределенную систему делал. Где заменял в реакт-подобной («распределенный flux/redux») системе immutable.js на Меморию. И оно работало именно так, как ты говорил, только с теми нюансами, которые я привел))
Исправление aist1, :
Потому что система и ее утилиты написаны на C/C++, и потому программировать такую систему будет очень сложно.
Потому что есть зависимости по данным. И чем более мелкие шарды ты делаешь, тем больше у тебя влияние высоколатентных каналов связи и дорогостоящих протоколов распределенных транзакций.
Примерно как Virtual DOM в React.js, ЕВПОЧЯ.
Я понимаю, о чем ты. Ты понимаешь, что ФСД не являются lock-free в строгом смысле? В самом лучшем случае там будет куча блокировок/атомиков в сборщике мусора. Ты можешь реализовать распределенный сборщик мусора на идемпотентных распределенных атомарных счетчиках, но это уже довольно большое пространство разделяемого состояния.
Ну и в большинстве случаев тебе понадобится блокировка (строгая консистентность) на «голове» истории, как минимум. Если не на всей истории версий.
Все преимущество ФСД/ПСД в том, что как только новая версия создана, дальше вся работа будет идти уже в wait-free режиме, т.е. вообще без блокировок и атомиков до самого коммита, а данные версий могут свободно кэшироваться как угодно, потому что они иммутабельные. Но работа воркеров с историей требует транзакций. Метаданные версий должны становиться известными воркерам, и тут без транзакций не обойтись.
А так — да. Я даже такую распределенную систему делал. Где заменял в реакт-подобной («распределенный flux/redux») системе immutable.js на Меморию. И оно работало именно так, как ты говорил, только с теми нюансами, которые я привел))
Исходная версия aist1, :
Потому что система и ее утилиты написаны на C/C++, и потому программировать такую систему будет очень сложно.
Потому что есть зависимости по данным. И чем более мелкие шарды ты делаешь, тем больше у тебя влияние высоколатентных каналов связи и дорогостоящих протоколов распределенных транзакций.
Примерно как Virtual DOM в React.js, ЕВПОЧЯ.
Я понимаю, о чем ты. Ты понимаешь, что ФСД не являются lock-free в строгом смысле? В самом лучшем случае там будет куча блокировок/атомиков в сборщике мусора. Ты можешь реализовать распределенный сборщик мусора на идемпотентных распределенных атомарных счетчиках, но это уже довольно большое пространство разделяемого состояния.
Ну и в большинстве случаев тебе понадобится блокировка (строгая консистентность) на «голове» истории, как минимум. Если не на всей истории версий.
Все преимущество ФСД/ПСД в том, что как только новая версия создана, дальше вся работа будет идти уже в wait-free режиме, т.е. вообще без блокировок и атомиков до самого коммита, а данные версий могут свободно кэшироваться как угодно, потому что они иммутабельные. Но работа воркеров с историей требует транзакций. Метаданные версий должны становиться известными воркерам, и тут без транзакций не обойтись.
А так — да. Я даже такую распределенную систему делал. Где заменял в реакт-подобной системе immutable.js на Меморию. И оно работало именно так, как ты говорил, только с теми нюансами, которые я привел))