N
Для Control Plane используется свой проприетарный протокол, для копирования данных сам S3 и используется. Все остальные подробности не доступны…. ;)
А лидер есть ?
Size: a a a
2020 December 03
VP
Я надеялся, что вкупе с мульти-таргет и строгой консистентностью, добавят флажок "синхронная репликация"
если ты понимаешь ограничения физики то как даже в теории мог допустить, что когда-нибудь появится синхронная репликация… Ответ, нет никогда не завезут, ни AWS ни кто-либо другой. Без убивания производительности это не возможно
KT
если ты понимаешь ограничения физики то как даже в теории мог допустить, что когда-нибудь появится синхронная репликация… Ответ, нет никогда не завезут, ни AWS ни кто-либо другой. Без убивания производительности это не возможно
Последнее предложение решает в твоем сообщении
KT
Я прекрасно осознаю, что говоря "я хочу replication factor + 1 и этот +1 должен быть в другом регилнк", я должен подписаться под то что 1) если реплика не прошла, запись провалится с ошибкой 2) транзакция займет больше времени
KT
Мой вопрос из рода кейсов когда я готов жертвовать производительностью
KT
Проще говоря, мне ОК писать килобайтовый файл не микросекунду, а 2 секунды
VP
Проще говоря, мне ОК писать килобайтовый файл не микросекунду, а 2 секунды
Как ты думаешь, почему при включении CRR или SRR копируются только новые объекты, а старые нет? На самом деле технической проблемы нет, запустить репликацию можно (большой секрет, мы это делаем в очень специальных случаях)… только если даже небольшой процент пользователей в регионе включит плюс-минус одновременное копирование сотен миллиардов объектов, то даже нашей сети станет мега-плохо…. тоже самое с синхронной репликацией…. представь себе, мы открываем сотни миллионов коннектов и держим их многие минуты ожидая окончания записи…. такая репилкация убъет не только твою пользовательскую производительность, но и повлияет на нашу производительность, что почувствуют другие пользователи облака…
KT
Понятно же, что я не прошу о вещах уровня книг Айзека Азимова
KT
Как ты думаешь, почему при включении CRR или SRR копируются только новые объекты, а старые нет? На самом деле технической проблемы нет, запустить репликацию можно (большой секрет, мы это делаем в очень специальных случаях)… только если даже небольшой процент пользователей в регионе включит плюс-минус одновременное копирование сотен миллиардов объектов, то даже нашей сети станет мега-плохо…. тоже самое с синхронной репликацией…. представь себе, мы открываем сотни миллионов коннектов и держим их многие минуты ожидая окончания записи…. такая репилкация убъет не только твою пользовательскую производительность, но и повлияет на нашу производительность, что почувствуют другие пользователи облака…
То что ты сейчас пишешь, звучит как оправдание, что этого сделать нельзя. По факту это можно, но дорого, неэффективно и далеко не факт что нужно
KT
Я более чем уверен, что такая "фича" будет стоить космических денег и наврядли будет востребована
KT
Но я говорил не про crr с acid из коробки, а про crr с возможностью включить acid (хоть отдельным флажком)
KT
То что этого сделать нельзя, я уже понял
VP
Nikolay
А лидер есть ?
Я честно не знаю…. но во многих наших системах используется Paxos
KT
Почему этого нет, меня, как потребителя, сам понимаешь, не интересует, ибо на то я и потребитель.
KT
И если честно, ответ "если все это включат у нас сетка ляжет" еще хуже чем "ну иди физику учить" :(
N
Интересно читать . Но вроде нет в s3 acid же ?
VP
Nikolay
Интересно читать . Но вроде нет в s3 acid же ?
ACID нет, конечно. Read-after-write на все операции с объектами теперь уже есть.
KT
Нет, разумеется
KT
С с3 раньше была история что при GET после PUT была вероятность получить старую версию объекта
KT
Сейчас этой вероятности нет, завезли строгую консистентность