А вот не знаю, честно говоря, я в таких деталях не разбираюсь 💁♂️ Знаю что при хайлоаде и стримах в обычный s3 раньше можно напороться на проблемы из за eventual consistency, но судя по апдейтам вот тут в 2021 во всех стораждах все хорошо с consistency: https://spark.apache.org/docs/latest/cloud-integration.html#consistency
Ну это вроде уже починили некоторое время как, года три, наверное.
Strict serializable это же про транзакции более чем над одним обьектом т.е с multi-object operations , а в S3 таких нет. Или уже сделали?
Хм, одиночность объекта - сложное понятие. В БД это типа атом какой-то. А что это такое в фс? Я бы сказал что запись нескольких блоков на диске...
Strong ISR = serializability + linearizability, второе это самое строгая целостность для операций по одному объекту
Не ISR, а 1SR 1 - это one-copy. Linearizable - это не самая строгая. Есть есть strict consistency.
у меня римская единица) я знаю что это значит
Хм... может вам в яндекс написать, а то они там считают, что они сделали strict consistency БД под названием YDB. А вообще я легко могу сделать такую БД. Ну смотрите сами: в один поток обрабатываем все операции в транзакции, при этом внутри транзакции убираем любую интерактивность с пользователем. Т.е. другими словами пользователь готовит набор действий в транзакции и комитит их, а сервер за один раз их применяет.
наверное у них не то определение что используется в академии, strict consistency подразумевает моментальную доступность для всех читателей, что невозможно (скорость света мешает)
Видимо это для случая распределённости. Окей, давайте добавим реплики к моей выдуманной БД, которые будут применять транзакции. Будем отдвать ответ пользователю тогда, когда записалось на все реплики. Появилась распределённая штуковина.
Under this model, a write to a variable by any processor needs to be seen instantaneously by all processors. Вот это невозможно
в каждый дц поставить атомные часы и не отдавать ок, пока не стукнет это время и транзакция станет видимой для всех в один момент? Вроде spanner на похожих принципах основан
когда в распределенных системах рассуждают про "доступность", оно относится к processors, то есть всем участникам распределенной системы (серверам, читателям и писателям)
Как-то незамечал раньше такого в определении strict consistency. Так выглядит невозможным. НО вот ниже написано следующее: The strict model diagram and non-strict model diagrams describe the time constraint – instantaneous. It can be better understood as though a global clock is present in which every write should be reflected in all processor caches by the end of that clock period. The next operation must happen only in the next clock period. Т.е. как будто бы время можно поделить на интервалы и в течении определённого интервала должна выполнится операция на всех узлах. Меняем нашу выдуманную базу следующим образом: При получении запроса рассылаем его на все узлы и все узлы одновременно выполняют запрос за определённый квант времени. Тут есть нюансы: 1. где-то запрос может выполняться дольше (медленнее) 2. где-то запрос по сети может идти дольше Получается, чтобы поддержать это свойство, нужно иметь определённые гарантии на сеть и на то, что доступ к памяти на сохранение и чтение одинаковый. Наверное в худшем случае такое обеспечить нельзя. Вот хорошо бы у Яндекса узнать теперь ответы на эти вопросы...
Обсуждают сегодня