Size: a a a

2020 December 07

AB

Anton Bryzgalov in AWS_RU
Рекомендую к прочтению тем, кто пробовал NoSQL: https://medium.com/@nabtechblog/advanced-design-patterns-for-amazon-dynamodb-354f97c96c2 — эта статья буквально расширила границы моего сознания!

Здесь рассказывается про то, как проектировать таблицы в NoSQL БД на примере (и с большой привязкой к) AWS DynamoDB.

Расширение сознания вызвано тем, что основной рассмотренный прием — это хранение в одной таблице совершенно разных данных, относящихся к одном объекту, чтобы ускорить к ним доступ. В реляционных СУБД в одной таблице лежат данные «одной грани» каждой сущности, и это логично, привычно и оправданно. А вот идея хранить в одной таблице разные по сути данные звучит провокационно, однако статья вполне обосновывает такой подход.

В конце статьи дан пример, как шесть таблиц реляционной СУБД упихали в одну NoSQL таблицу, обеспечив доступ к разным «срезам» с помощью глобального индекса (Global Secondary Index). И это звучит обоснованно и модно 😉

Почитать про основные аспекты NoSQL и конкретно DynamoDB можно в первой части статьи: https://medium.com/@nabtechblog/advanced-design-patterns-for-amazon-dynamodb-c31d65d2e3de
источник

DS

Dmitriy Solodukha in AWS_RU
Коллеги
У S3 есть Intelligent-Tiering, когда они сами меняют storage tier по паттерну доступа к объектам.

Я так понимаю, что в Glacier там все тоже автоматически переносится, что не может вызывать опасений, ибо... здесь возникнут либо высокие retrieval fees, либо файлы просто будут долго недоступны.

Как это вообще работает, кто-то понимает? Читал документацию, но там про это ни слова.
источник

LK

L K in AWS_RU
Dmitriy Solodukha
Коллеги
У S3 есть Intelligent-Tiering, когда они сами меняют storage tier по паттерну доступа к объектам.

Я так понимаю, что в Glacier там все тоже автоматически переносится, что не может вызывать опасений, ибо... здесь возникнут либо высокие retrieval fees, либо файлы просто будут долго недоступны.

Как это вообще работает, кто-то понимает? Читал документацию, но там про это ни слова.
источник

DS

Dmitriy Solodukha in AWS_RU
Да, оно
источник

DS

Dmitriy Solodukha in AWS_RU
Но там нет ответа на вопрос, как и когда они переносят в Glacier. И как потом оттуда все это достается, если вдруг и ах
источник

АП

Агент Печенька... in AWS_RU
and you can also use S3’s Lifecycle Policies to tell S3 to transition objects from Standard to Standard-IA, One Zone-IA, or Glacier based on their creation date.
источник

АП

Агент Печенька... in AWS_RU
Dmitriy Solodukha
Но там нет ответа на вопрос, как и когда они переносят в Glacier. И как потом оттуда все это достается, если вдруг и ах
Ты контролируешь.
источник

АП

Агент Печенька... in AWS_RU
источник

DS

Dmitriy Solodukha in AWS_RU
Это Lifecycle, да. Я говорю про то, могу ли я безопасно для всех бакетов включить Intelligence-Tier и не боятся, что в какой-то момент мои клиенты не получат вдруг свои файлы
источник

DS

Dmitriy Solodukha in AWS_RU
Ответ на мой вопрос
https://aws.amazon.com/blogs/aws/s3-intelligent-tiering-adds-archive-access-tiers/

Если я правильно понял, то это как бы гибрид между Lifecycle Policy и автоматическим переносом данных, т.е. как я вижу, перемещение в Archival tiers уже задается отдельным параметром при включении Intelligence Tier
источник

AT

Al T in AWS_RU
можете включить, но если у вас будут часто перемещаться файлы между tiers то стоимость хранения может вырасти по сравнению с обычным on-demand
источник

☁️ AWStatus in AWS_RU
Service: Amazon Elastic Compute Cloud
Region: 🇧🇷South America (São Paulo)
URL: http://status.aws.amazon.com/#ec2-sa-east-1_1607344379

We can confirm connectivity and power issues affecting some instances in a single Availability Zone (sae1-az3) in the SA-EAST-1 Region. We have identified the cause of the issue and are working towards resolution.

#ec2 #saeast1
источник

☁️ AWStatus in AWS_RU
Service: Amazon Elastic Compute Cloud
Region: 🇧🇷South America (São Paulo)
URL: http://status.aws.amazon.com/#ec2-sa-east-1_1607346237

At 11:10 PM PST on December 6 a small number of underlying hosts experienced power loss, affecting some customers in sae1-az3 in the SA-EAST-1 Region. Impacted customers were automatically notified via the Personal Health Dashboard. We quickly identified root cause and began working toward recovery. At 2:25 AM PST on December 7 additional hosts were impacted. Shortly after that we began to successfully mitigate impact and as of 4:00 AM PST we have begun to see recovery. We continue to work toward full resolution.

#ec2 #saeast1
источник

MV

Maxim Vynogradov in AWS_RU
Привет!
Я тут небольшую около AWS-ную статью  написал. Можно вам её дать на оценку / растерзание =)?

https://medium.com/dailyjs/six-reasons-why-you-shouldnt-run-express-js-inside-aws-lambda-102e3a50f355
источник

AS

Alexey Stekov in AWS_RU
конечно!
источник

MV

Maxim Vynogradov in AWS_RU
Alexey Stekov
конечно!
Спасибо!
я недавно начал писать, меня всё ещё за мой англиский ругают )
но я пытаюсь!
источник

MV

Maxim Vynogradov in AWS_RU
Тогда вот вторая , чуть старше =)
Правда  эту писал для своей компании - не знаю почему но у неё прям очень много  просмотров
https://medium.com/brocoders-team/what-we-have-learned-while-using-aws-lambda-in-our-production-cycles-for-more-than-one-year-dbf79faa441b
Для скиловых людей врядли что-то интересное будет, но вот неофиты могут узнать что-то полезное.
источник

A

Alex in AWS_RU
мое имхо: было бы интереснее: как правильно упаковывать нежели как избегать
источник

MV

Maxim Vynogradov in AWS_RU
Alex
мое имхо: было бы интереснее: как правильно упаковывать нежели как избегать
в общем лямбду или в контексте експресса?
источник

RR

Roman Roman in AWS_RU
я бы не юзал Express в принципе негде
источник