Update ru.md

translations/ru.md

@@ -771,16 +771,16 @@ S3
 	-	🔸Если подумать об этом заранее - это поможет избежать многих проблем в будущем. Очень сложно чистить большие наборы файлов созданные многими инженерами с разными жизненными циклами и отсутствием какой-либо цельной организации.
 	-	Также вы можете настроить политику жизненного цикла для архивации старых данных в Glacier. [Будьте аккуратны](https://alestic.com/2012/12/s3-glacier-costs/) при архивации большого количества маленьких объектов в Glacier, так как это может стоить еще дороже.
 	-	Также существует класс хранения, называемый [**Нечастый доступ(Infrequent Access)**](https://aws.amazon.com/s3/storage-classes/#Infrequent_Access) который имеет тот же уровень сохранности данных, как и стандартный S3, но стоит дешевле за GB. Он подходит для объектов, к которым редко обращаются.
--	**Целостность данных:** Понимание [целостности данных](https://docs.aws.amazon.com/AmazonS3/latest/dev/Introduction.html#ConsistencyModel) крайне важно для любого использования S3, так как тут есть несколько производителей и потребителей данных.
+-	**Согласованность данных:** Понимание [согласованности данных](https://docs.aws.amazon.com/AmazonS3/latest/dev/Introduction.html#ConsistencyModel) крайне важно для любого использования S3, так как тут есть несколько производителей и потребителей данных.
 	-	Создание и обновление индивидуальных объектов в S3 **атомарное(atomic)**, таким образом у вас никогда не будет ситуации, что вы обновляете иил загружаете новый объект, а другой клиент видит только часть изменений. 
 	- Неопределенность заключается в том, *когда* вы и ваши клиенты увидят обновления.
-	-	**New objects:** If you create a new object, you’ll be able to read it instantly, which is called **read-after-write consistency**.
-		-	Well, with the additional caveat that if you do a read on an object before it exists, then create it, [you get eventual consistency](https://docs.aws.amazon.com/AmazonS3/latest/dev/Introduction.html#ConsistencyModel) (not read-after-write).
-		-	This does not apply to any list operations; newly created objects are [not guaranteed to appear in a list operation right away](https://docs.aws.amazon.com/AmazonS3/latest/dev/Introduction.html#ConsistencyModel)
-	-	**Updates to objects:** If you overwrite or delete an object, you’re only guaranteed **eventual consistency**, i.e. the change will happen but you have no guarantee of when.
-	- 🔹For many use cases, treating S3 objects as **immutable** (i.e. deciding by convention they will be created or deleted but not updated) can greatly simplify the code that uses them, avoiding complex state management.
-	-	🔹Note that [until 2015](https://aws.amazon.com/about-aws/whats-new/2015/08/amazon-s3-introduces-new-usability-enhancements/), 'us-standard' region had had a weaker eventual consistency model, and the other (newer) regions were read-after-write. This was finally corrected — but watch for many old blogs mentioning this!
-	-	**Slow updates:** In practice, “eventual consistency” usually means within seconds, but expect rare cases of minutes or [hours](http://www.stackdriver.com/eventual-consistency-really-eventual/).
+	-	**Новые объекты:** Если вы создаете новый объект, вы сможете немедленно его прочитать, что называется **согласованность чтения-после-записи(read-after-write consistency)**.
+		-	К слову, дополнительно необходимо предупредить, что если вы пытаетесь прочесть объект до его создания, а потом создаете его [вы получаете возможную согласованность](https://docs.aws.amazon.com/AmazonS3/latest/dev/Introduction.html#ConsistencyModel) (не чтения-после-записи).
+		-	Это не относится к операциям просмотра; впервые созданные объекты [не гарантированно сразу появятся при операциях просмотра содержимого бакетов](https://docs.aws.amazon.com/AmazonS3/latest/dev/Introduction.html#ConsistencyModel)
+	-	**Обновления объектов:** Если вы перезаписываете или удаляете объект, вы получаете только гарантированную **возможноую согласованность(eventual consistency)**, то есть изменение будет применено, но нет никаких гарантий когда.
+	- 🔹Для большинства случаев использования, принятие решения об использовании объектов S3, как **неизменных** (то есть предварительно приняв решение, что объекты будут либо создаваться, либо удаляться, но не обновляться) может крайне сильно упростить код, использующий объекты, путем исключения сложного управления состоянием объектов.
+	-	🔹Имейте ввиду, что [до 2015 года](https://aws.amazon.com/about-aws/whats-new/2015/08/amazon-s3-introduces-new-usability-enhancements/), регион'us-standard' имел более слабую модель возможной согласованности, а другие (более новые) регионы могли считывать после записи. Это наконец-то было исправлено - но вы можете почитать множество старых блогов, рассказывающих об этом.
+	-	**Медленные обновления:** На практике, “возможная согласованность” обычно означает получение результата через секунд, за исключением редких случаев, когда согласованность возникает через минуты или даже [часы](http://www.stackdriver.com/eventual-consistency-really-eventual/).
 -	**S3 as a filesystem:**
 	-	In general S3’s APIs have inherent limitations that make S3 hard to use directly as a POSIX-style filesystem while still preserving S3’s own object format. For example, appending to a file requires rewriting, which cripples performance, and atomic rename of directories, mutual exclusion on opening files, and hardlinks are impossible.
 	-	[s3fs](https://github.com/s3fs-fuse/s3fs-fuse) is a FUSE filesystem that goes ahead and tries anyway, but it has performance limitations and surprises for these reasons.