DATA API для Amazon Aurora Serverless

Как работает подключение к традиционной базе данных? Вы открываете соединение, используете его для обработки одного или нескольких запросов SQL или других операторов, а затем закрываете соединение. Вы, вероятно, использовали клиентскую библиотеку, специфичную для вашей операционной системы, языка программирования и базы данных. В какой-то момент вы поняли, что создание соединений занимало много времени и занимало память на ядре базы данных.

DATA API заботится об управлении и масштабировании долгосрочных соединений с базой данных и возвращает данные в форме JSON для простого анализа. Весь трафик криптован и происходит через HTTPS.

Итак, что из себя представляет DATA API?

ExecuteStatement — выполнить один SQL запрос.
BatchExecuteStatement — выполнить один SQL запрос для массива данных.
BeginTransaction — начать транзакцию и вернуть идентификатор транзакции.
CommitTransaction — завершить транзакцию и зафиксировать SQL операции, которые были в ней выполнены.
RollbackTransaction — откатить транзакцию.

Единственное ограничение в том, что каждая функция должна завершиться в течение минуты и может вернуть до 1 мегабайта данных.

Читать подробнее.

— Арт Тоноян arttonoyan, Database Administrator в Provectus

Amazon Kinesis Data Analytics now allows you to assign AWS resource tags to your real-time applications

С увеличением потока данных, повышается и необходимость особым образом обрабатывать и анализировать эти данные. Amazon Kinesis Data Analytics — один из таких сервисов, который дает вам возможность, написав SQL или Java код (используя Apache Flink), начать собирать данные с разных источников, а также обрабатывать и анализировать их в реальном режиме времени. Теперь, получив более полную и многомерную картину ваших данных, вы с легкостью можете извлечь новую полезную информацию, а также оперативно реагировать на потребности бизнеса и клиентов.

С ростом количества таких приложений, растет и необходимость грамотно управлять ими. Не так давно компания Amazon объявила о том, что теперь появилась возможность добавлять теги ресурсов вашим приложениям в Amazon Kinesis Data Analytics, подобно другим AWS ресурсам. Тег представляет собой пару “ключ-значение”, где значение является необязательной частью. Использование тегов — это простой, но эффективный способ управления AWS ресурсами и организации данных. Примеры возможных тегов:

Environment: Staging
Application: Application name
Project: Project name

С помощью тегов вы можете добавить приложению больше контекста. В случае с приложениями Amazon Kinesis Data Analytics теги могут быть использованы:
Для определения биллинга под конкретные приложения Amazon Kinesis Data Analytics.
Для управления доступом к ресурсам приложения.
Для целей, определяемые самим пользователем — вы можете определить функциональность приложений, основываясь на наличии пользовательских тегов.
Более подробную информацию о тегах для приложений Amazon Kinesis Data Analytics вы можете найти здесь.

— Булат Гайнеев grbulat, Software Engineer в Provectus

Amazon S3 Path Deprecation Plan – The Rest of the Story

В одном из самых популярных сервисов S3 от Amazon Web Services (AWS) в скором времени устареет способ получения файлов с помощью указания пути (path-style), например, s3.amazonaws.com/usmanovbf/docs/Bulat_Usmanov_CV.pdf или с регионом — s3-us-east-2.amazonaws.com/usmanovbf/docs/Bulat_Usmanov_CV.pdf, где usmanovbf — это бакет, а /docs/Bulat_Usmanov_CV.pdf — ключ до файла на этом бакете.

Предпочтение будет отдано другому способу — с помощью виртуального хоста (virtual-hosted style), например, usmanovbf.s3.amazonaws.com/docs/Bulat_Usmanov_CV.pdf или так же с регионом — usmanovbf.s3-us-east-2.amazonaws.com/docs/Bulat_Usmanov_CV.pdf

Переход ожидается сделать 30 сентября 2020 года. Благодаря открытости инженеров AWS к сообществу все path-style ссылки, созданные до этой даты включительно, не будут удалены. То есть они останутся полностью рабочими, просто после этой даты можно будет использовать только второй способ — virtual-hosted style.

Данное изменение продиктовано двумя главными причинами:
1. Более централизованная модель, которым является обращение к файлам с помощью path-style, ограничивает эффективное масштабирование, так как весь трафик приходит на небольшой набор входных точек: субдомены третьего уровня s3, s3-us-east-2, s3-us-east-1 и так далее. По этой же причине становится неудобной работа с разрешением DNS имен, с безопасностью, отражением DDOS атак.
Virtual-hosted style позволяет более гибко управлять потоком данных благодаря привязке уже к отдельному субдомену-бакету и к региону, например, usmanovbf и s3-us-east-2 как в примере выше.

2. Инженеры из AWS не стоят на месте, и для введения нового функционала и отказа от старого им необходимо перейти на virtual-hosted style. К примеру, планируется отказаться от старых методов шифрования.

Более подробную информацию о миграции на новый способ вы можете найти на официальном блоге AWS.

— Булат Усманов usmanovbf, Software Engineer в Provectus

Узнай больше о новых сервисах и продуктах от Amazon на AWS Dev Day Moscow!

#AWSDevDayMoscow — это однодневная бесплатная конференция для Machine Learning Engineers, Data Scientists, DevOps Engineers, Solution Architects и Software Engineers, котоые интересуются или уже работают с сервисами AWS.

Обсудим самые горячие темы с сфере облачных технологий с единомышленниками и командой AWS уже совсем скоро!

Когда: 18 июня
Где: Пространство «Весна»
Спартаковский переулок 2с1, подъезд №7

Регистрация

Встретимся на AWS Dev Day Moscow!