From c26dabb98d1322f4f7e5db1ff9a2050cd1a7280b Mon Sep 17 00:00:00 2001 From: Nikolay Poida Date: Sun, 29 Mar 2020 14:56:18 +0600 Subject: [PATCH] Update ru.md --- translations/ru.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/translations/ru.md b/translations/ru.md index d200ba8..65a336d 100644 --- a/translations/ru.md +++ b/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.