Транзакционные поисковые запросы — 2×2 Digital Agency

Перед внедрением любого маркетингового инструмента вы должны определиться с финальными задачами, которых хотите достигнуть через определенный промежуток времени. Когда разговор заходит за SEO продвижение, многие специалисты отчетливо видят задачу и в один голос отвечают – увеличения объема продаж и прибыли компании.

Ключевые слова играют важную роль в SEO оптимизации, но все ли они одинаково хорошо влияют на продажи? Не будем долго ходить вокруг да около и сразу ответим, что нет. Необходимо правильно оптимизировать контент на страницах и тщательно подготавливать его под конкретный этап воронки продаж, подробней об этом в отдельной статье нашего блога.

А сейчас мы поговорим о транзакционных поисковых запросах и клиентах, которые ищут возможность купить тот или иной продукт.

Что такое транзакционные поисковые запросы?

Транзакционный запрос – запрос пользователя, который стремится совершить целевое действие (купить, заказать, оформить, узнать стоимость и многое другое), но еще не знает где он хочет этот сделать.

Например, по запросу “купить переноску для котов”, пользователь уже отчетливо понимает, что он хочет, и все что ему остается – определиться с выбором среди доступных предложений.

Отличительной чертой транзакционных запросов являются слова маркеры: купить, заказать, оформить и так далее.

Однако, мы не советуем концентрировать внимание исключительно на них. Конкретные запросы с точным названием продукта, но не содержащие в себе слов, перечисленных выше, также относятся к транзакционным запросам.

Почему важно оптимизировать страницы под транзакционные запросы?

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

Принято считать, что подобные запросы являются наиболее ценными для предприятий, которые занимаются продажей товаров или услуг онлайн.

Сразу отметим, что не стоит концентрировать усилия исключительно на транзакционных запросах. Хоть они и являются наиболее конверсионными, их потенциал ограничивается существующим спросом на вашу продукцию.

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

Описанные выше сценарии – отличная возможность привлечь клиентов на разные этапы воронки продаж. Кстати, у нас есть полезная статья, которая более подробно расскажет о существующих типах поисковых запросов и их преимуществах.

Как продвигаться с помощью транзакционных запросов?

Убедитесь, что выбранное ключевое слово соответствует намерению пользователей

Наверное, главный принцип поискового продвижения – соответствие контента на странице запросу пользователей.

Перед тем, как делать ставку на ту или иную ключевую фразу, нужно проанализировать, что поисковые предлагают в ответ на подобный запрос. Просто введите в Яндексе или Google выбранный поисковой запрос и посмотрите на результаты выдачи, если она состоит из коммерческих страниц, то вы выбрали правильную фразу и она соответствует транзакционному запросу.

Внедряйте ключевую фразу в главные SEO элементы страницы

Этот этап подразумевает стандартные принципы SEO продвижения, которые подойдут для любого типа поисковых запросов. В условиях высокой конкуренции, их использование на странице является жизненно необходимым фактором. Коротко поговорим о каждом:

Оптимизируйте title и description страницы с включением в них транзакционного запроса

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

Description усиливает сниппет привлекательным описанием и дополнительно раскрывают информацию о странице для пользователей. Использование ключевых слов в этих элементах подсказывает потенциальным покупателям, что они могут ожидать на странице.

Используйте ключевые слова в структуре h заголовков

Не менее значимыми элементами на странице являются h2, h3 заголовки. Кроме того, что они структурируют контент на странице, они посылают важные сигналы поисковым роботам, влияющим на ранжирование. Не забудьте добавить выбранный транзакционный запрос в структуру h заголовков.

Оптимизируйте изображения на странице

Качественные изображения увеличивают вовлеченность покупателей, помогают им визуально представить продукт и приближают к покупке. Однако, в изображения кроется еще одна важная особенность – они способны передавать сигналы поисковым системам и могут быть найдены по запросам пользователей. Просто добавьте описательную ключевую фразу в alt атрибут изображения.

Заключительные мысли

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

В итоге, правильное использование транзакционных запросов помогает в привлечении “теплых” клиентов. К сожалению, это еще не гарант успеха. Ваш сайт и бизнес должен продавать и убеждать клиентов, но об этом мы поговорим в других статьях нашего блога.

Типы и виды поисковых запросов

Поисковый запрос – это слово или словосочетание, которое вводит пользователь поисковой системы, желая получить определенную информацию. После получения запроса система автоматически выводит наиболее подходящие страницы.

Поисковый запрос — это последовательность символов, которую пользователь вводит в поисковую строку, чтобы найти интересующую его информацию. Формат поискового запроса зависит как от устройства поисковой системы, так и от типа информации для поиска. Чаще всего, поисковый запрос задаётся в виде набора слов или фразы, иногда — используя расширенные возможности языка запросов поисковой системы.

Типы поисковых запросов

Разделяют на четыре типа цели поиска (иначе — тип намерений поиска, тип поисковых запросов):

Информационный

Искатель ищет информацию. Это может быть ответом на простой вопрос или что-то, что требует более подробного ответа. Однако не все информационные поиски формулируются в виде вопросов. То есть это запросы несущие информационный характер. Наиболее популярный в поисковых системах тип. Отвечает на вопросы «как», «для чего», «каким образом» и т. д. 

Пример: «как наклеить обои?».

Для многих простых информационных запросов, Яндекс и Google не только возвращает релевантные результаты, но и показывает ответ в результатах поиска.

Навигационный

Искатель ищет конкретный веб-сайт. Искатель уже знает, куда хочет перейти. Вероятно, им просто быстрее и проще ввести это в Яндекс или Google, чем вводить весь URL — адрес в адресной строке. Они также могут не знать точный URL.

Пример: «веб-студия webtend».

Но навигационный поиск — это не всегда просто  названия брендов. Если кто-то ищет «iphone 12 ozon», возможно, это также поиск по навигации. Хотя искатель ищет конкретный продукт, он уже решил, где он будет его покупать — на Ozon.

Транзакционный

Искатель хочет совершить покупку. Он в режиме покупки. Скорее всего, он уже знает, что хочет купить. Он ищет, где это купить. Иначе — к данному типу относятся те запросы, что предполагают совершение какого-либо действия.

Транзакционный поиск — это когда кто-то хочет купить что-то конкретное, но еще не решил, где это купить.

Пример: «купить ноутбук».

Глядя на результаты поиска, еще становится ясно, что Яндекс и Google понимают это, потому что все страницы с самым высоким рейтингом являются страницами категорий с сайтов электронной коммерции.

Коммерческое расследование

Искатель ищет конкретный продукт или услугу, но еще не принял окончательного решения о том, какое решение подходит для него. Скорее всего, он ищет обзоры и сравнения, отзывы. Он все еще взвешивает варианты.

Пример: «лучший бар с едой».

Многие местные поиски преследуют коммерческие цели.

Пример: «барбершоп рядом со мной».

Мультимедийный

Предполагает поиск мультимедийной информации: музыки, фильмов, изображений.

Разные (общие)

К данному типу относятся запросы, которые тяжело однозначно отнести к любому из вышеописанных типов. Как правило, такие запросы состоят из нескольких слов.

Как определить каждый тип поиска

Исторически сложилось так, что специалисты по SEO искали определенные слова или фразы в запросе, чтобы сделать вывод о типе поиска. Они известны как модификаторы ключевых слов. Например, если запрос содержит такие модификаторы, как «купить», это почти наверняка транзакционный запрос.

Что многие люди используют:

Информационная	Навигационный	Транзакционный
кто	[название бренда]	купить
какие	[наименование товара]	купон
когда	[наименование услуги]	дешевый
куда		покупка
почему		цена
как		заказать
руководство		вызвать

Виды поисковых запросов

Виды поисковых запросов можно условно разделить на 4 категории.

1. По частотности

• ВЧ – высокочастотные. Слово «высокочастотный» уже дает точное определение данной подкатегории – высокая частота запроса. Высокочастотные запросы обычно состоят из 1–2 слов. Как правило, вывести сайт в ТОП по ВЧ очень сложно, т. к. конкуренция по ним высока.
• СЧ – среднечастотные. Среднечастотные запросы менее конкурентные, нежели ВЧ, но они также способны давать неплохую посещаемость. Что касается показателя конверсии, то он варьируется от среднего до высокого значения.
• НЧ – низкочастотные. НЧ – это редко запрашиваемые слова. Однако и они играют важную роль в оптимизации сайта, так как помогают продвинуть сайт по низкочастотным запросам и повысить целевой трафик. Наиболее любимы НЧ среди владельцев интернет-магазинов.

Существуют также «нулевые» или их ещё называют «супер низкочастотные запросы». Частота их колеблется в пределах 0–2 в месяц, а потому для продвижения они не имеют особой ценности.

2. По конкурентности

• ВК – высококонкурентные;
• СК – среднеконкурентные;
• НК – низкоконкурентные.

При работе над новым проектом предпочтение лучше отдать низко- и среднеконкурентным запросам.

3. По степени ценности

• Коммерческие. К данной категории относятся запросы, прямо или косвенно призывающие купить некоторый продукт.
• Некоммерческие. В противовес коммерческим, к покупке не побуждают, а носят скорее информационный характер. Соответственно, активно используются на информационных и развлекательных порталах.

4. По геозависимости

• Геозависимые. Важная подкатегория, которая регулирует выдачу по географическому расположению. Например, «заказать пиццу». Поисковая система автоматически определяет ваше географическое расположение (например, Москва) и выдает результаты, которые относятся исключительно к московскому региону. Таким образом, поисковая выдача для разных регионов будет существенно отличаться.
• Геонезависимые. Данный вид запросов не привязывается к географическому расположению человека, запрашивающего информацию. Поисковая выдача будет с большой долей вероятности одинакова для разных стран и регионов.

5. Другие виды поисковых запросов

Кроме вышеперечисленных параметров на выдачу в поисковых системах влияют четкость формулировки и постоянство запроса. 

По четкости формулировки все поисковые запросы условно делят на четкие и нечеткие. Четкими считают те запросы, которые содержат точные названия и описания объекта. Нечеткие носят размытый характер и имеют вариативность в выдаче. К примеру, запрос «роман» выдаст минимум два варианта — мужское имя и литературный жанр. Свой запрос в поисковике нужно конкретизировать, чтобы избежать нецелевой выдачи.  

Существуют также и другие виды поисковых запросов: сезонные, по времени суток и т.д. Но большинство оптимизаторов не выносит их в отдельную категорию при построении стратегии развития проекта.

Для владельцев и оптимизаторов сайтов данная информация является обязательной к пониманию и изучению, т. к. основным источником трафика для большинства ресурсов по-прежнему остаются поисковики. Именно поэтому серьезное продвижение того или иного сайта требует серьезного подхода и ряда действий: составления семантического ядра и определения всех типов поисковых фраз, на которые стоит ориентироваться.

Высокое ранжирование в Яндекс и Google — это секрет получения постоянного поискового трафика на ваши материалы (услуги, товары).

Типы поисковых запросов позволяют спланировать, какие действия будут производить пользователи на будущем или действующем сайте и предоставить заранее ответ, обладающий максимальной полнотой для удержания пользователя или выполнения им необходимого действия.

Пользователь, который ищет информацию в сети, формирует к поисковой системе запрос, отвечающий его потребностям. Поисковая система подбирает ресурсы, которые считает релевантными этому вопросу, и ранжирует их по ряду параметров.

Правильное определение типа и смысла поисковой фразы позволит понять:

1. Что именно подразумевает пользователь, формируя запрос?
2. Что пользователь ожидает увидеть на странице выдачи?

Понимая намерения пользователя, мы можем предоставить ему ответ, который максимально соответствует ожиданиям, выраженным при формировании поискового запроса.

Тип поискового запроса определяет ожидания статистически значимого большинства пользователей. Перечень сайтов в ТОПе поисковой выдачи формируется именно на основе ожиданий и потребностей пользователей. Для точного определения типа поискового слова желательно анализировать информацию из поисковой выдачи. Выдача не является статичной: в ней постоянно происходят изменения, которые влияют и на определение типа поисковой фразы.

Запросы подбирают с помощью сервисов подбора ключевых слов в Яндекс.Wordstat и Google AdWords. Они имеют понятный интерфейс и широкий функционал. В Вордстате можно найти поисковые запросы разных тематик, узнать количество просмотров, проанализировать динамику интереса. Также Яндекс собирает многолетнюю статистику по всем запросам пользователей, это позволяет сео-специалистам оптимизировать сайты. Кабинет Google AdWords работает аналогично.

Поисковые запросы помогают понять, что интересно пользователям, понять их намерение (интент). Перед продвижением сайта нужно собрать пул поисковых запросов, исходя из тематики бизнеса. Это поможет подготовить материал, который будет полностью соответствовать ожиданиям пользователей. Также важно правильно определять тип запроса, чтобы попасть в органическую выдачу и привлекать целевую аудиторию.

java — ТРЕБУЕМАЯ транзакция Spring против REQUIRES_NEW: транзакция отката

Задавать вопрос

спросил 10 лет, 9 месяцев назад

Изменено 1 год, 5 месяцев назад

Просмотрено 197 тысяч раз

У меня есть метод с распространение = Распространение.REQUIRES_NEW транзакционное свойство:

 @Transactional(распространение = Распространение.REQUIRES_NEW)
public void createUser (конечный UserBean UserBean) {
    //Здесь некоторая логика, требующая модификации в БД
}
 

---

Этот метод можно вызывать несколько раз одновременно, и для каждой транзакции, если возникает ошибка, она откатывается (независимо от других транзакций).

Проблема в том, что это может заставить Spring создать несколько транзакций, даже если доступна другая, и может вызвать некоторые проблемы с производительностью.

---

Документ Java о распространении = Распространение. ТРЕБУЕТСЯ говорит: Поддержите текущую транзакцию, создайте новую, если таковой не существует.

Кажется, это решает проблему с производительностью, не так ли?

Как насчет проблемы с откатом? Что делать, если вызов нового метода откатывается при использовании существующей транзакции? не отменит ли это всю транзакцию, даже предыдущие вызовы?

[РЕДАКТИРОВАТЬ] Я думаю, мой вопрос был недостаточно ясен:

К нашему серверу подключены сотни клиентов.

Для каждого клиента естественно нужно отправить отзыв о транзакции (ОК или исключение ->

откат).

Мой вопрос: если я использую REQUIRED , означает ли это, что используется только одна транзакция, и если 100-й клиент столкнется с проблемой, транзакция 1-го клиента также будет отменена?

• java
• spring
• hibernate
• транзакции
• spring-transactions

3

Использование REQUIRES_NEW имеет значение только тогда, когда метод вызывается из транзакционного контекста; когда метод вызывается из нетранзакционного контекста, он будет вести себя точно так же, как REQUIRED — он создаст новую транзакцию.

Это не означает, что для всех ваших клиентов будет только одна транзакция — каждый клиент будет запускаться из нетранзакционного контекста, и как только обработка запроса достигнет @Transactional

создаст новую транзакцию.

Итак, имея это в виду, если использование REQUIRES_NEW имеет смысл для семантики этой операции, то я бы не беспокоился о производительности — это приведет к преждевременной оптимизации учебника — я бы предпочел подчеркнуть правильность и целостность данных и беспокоиться о производительности после того, как показатели производительности будут собраны, а не раньше.

При откате — использование REQUIRES_NEW приведет к принудительному запуску новой транзакции, поэтому исключение приведет к откату этой транзакции. Если также выполнялась другая транзакция, которая будет или не будет отброшена в зависимости от того, всплывет ли исключение в стеке или будет перехвачено — ваш выбор, основанный на специфике операций. Также для более глубокого обсуждения транзакционных стратегий и отката я бы рекомендовал: «Стратегии транзакций: понимание ловушек транзакций», Марк Ричардс.

1

Если вам действительно нужно сделать это в отдельной транзакции, вам нужно использовать REQUIRES_NEW и жить с накладными расходами на производительность. Остерегайтесь мертвых замков.

Я бы сделал по-другому:

• Проверить данные на стороне Java.
• Запустить все за одну транзакцию.
• Если что-то пойдет не так на стороне БД -> это серьезная ошибка БД или схемы проверки. Откатить все и выдать критическую ошибку верхнего уровня.
• Напишите хорошие модульные тесты.

2

Зарегистрируйтесь или войдите в систему

Зарегистрируйтесь с помощью Google

Зарегистрироваться через Facebook

Зарегистрируйтесь, используя адрес электронной почты и пароль

Опубликовать как гость

Электронная почта

Требуется, но не отображается

Опубликовать как гость

Электронная почта

Требуется, но не отображается

Нажимая «Опубликовать свой ответ», вы соглашаетесь с нашими условиями обслуживания и подтверждаете, что прочитали и поняли нашу политику конфиденциальности и кодекс поведения.

Транзакции Amazon DynamoDB: как это работает

С помощью транзакций Amazon DynamoDB можно группировать несколько действий и отправлять их в виде одиночный все или ничего TransactWriteItems или TransactGetItems операция. В следующих разделах описываются операции API, управление емкостью, лучшие практики и другие сведения об использовании транзакционных операций в DynamoDB.

Темы

• API TransactWriteItems
• API TransactGetItems
• Уровни изоляции для транзакций DynamoDB
• Обработка конфликтов транзакций в DynamoDB
• Использование транзакционных API в DynamoDB Accelerator (DAX)
• Управление емкостью для транзакций
• Рекомендации по транзакциям
• Использование транзакционных API с глобальными таблицы
• Транзакции DynamoDB по сравнению с транзакциями AWSLabs клиентская библиотека

API TransactWriteItems

TransactWriteItems — синхронная и идемпотентная операция записи, группирует до 100 действий записи в одну операцию «все или ничего». Эти действия могут быть нацелены до 100 отдельных элементов в одной или нескольких таблицах DynamoDB в рамках одной учетной записи AWS и в тот же Регион. Совокупный размер элементов в транзакции не может превышать 4 МБ. действия выполняются атомарно, так что либо все они завершаются успешно, либо ни одно из них удается.

Примечание

• Операция TransactWriteItems отличается от операции BatchWriteItem . операции в том смысле, что все содержащиеся в ней действия должны быть выполнены успешно, иначе вообще вносятся изменения. С операцией BatchWriteItem возможно, что только некоторые действия в пакете выполняются успешно, а другие нет.

• Транзакции не могут быть выполнены с использованием индексов.

Вы не можете нацелить один и тот же элемент на несколько операций в рамках одной транзакции. Для например, вы не можете выполнить ConditionCheck , а также Update действие над одним и тем же элементом в одной и той же транзакции.

К транзакции можно добавить следующие типы действий:

• Put  — Инициирует операцию PutItem для создать новый элемент или заменить старый элемент новым элементом, условно или без указание любого условия.

• Update  — Инициирует UpdateItem операция редактирования атрибутов существующего элемента или добавления нового элемента в таблицу, если он уже не существует. Используйте это действие для добавления, удаления или обновления атрибутов в существующий элемент условно или без условия.

• Удалить  — Инициирует операцию DeleteItem для удаления одного элемента в таблице, идентифицированной его первичным ключом.

• ConditionCheck  — Проверяет существование элемента или проверяет состояние конкретных атрибутов предмета.

После завершения транзакции изменения, сделанные в этой транзакции, распространяются на глобальные вторичные индексы (GSI), потоки и резервные копии. Поскольку распространение не является немедленным или мгновенно, если таблица восстанавливается из резервной копии (RestoreTableFromBackup) или экспортируется в момент времени (ExportTableToPointInTime) в середине распространения, она может содержать некоторые, но не все изменения, сделанные во время последней транзакции.

Идемпотентность

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

Если первоначальный вызов TransactWriteItems был успешным, то последующие Вызовы TransactWriteItems с тем же токеном клиента успешно возвращаются без внесения каких-либо изменений. Если установлен параметр ReturnConsumedCapacity , первоначальный вызов TransactWriteItems возвращает число возможностей записи единиц, потраченных на внесение изменений. Последующие вызовы TransactWriteItems с тем же клиентским токеном возвращает количество единиц емкости чтения, использованных при чтении предмет.

Важные моменты об идемпотентности

• Токен клиента действителен в течение 10 минут после завершения запроса, в котором он используется. Через 10 минут любой запрос, в котором используется тот же клиентский токен, рассматривается как новый. запрос. Вы не должны повторно использовать один и тот же токен клиента для одного и того же запроса после 10 минут.

• Если вы повторите запрос с тем же токеном клиента в течение 10 минут окно идемпотентности, но изменить какой-либо другой параметр запроса, DynamoDB возвращает Исключение IdempotentParameterMismatch .

Обработка ошибок при записи

Транзакции записи не завершаются успешно при следующих обстоятельствах:

• Когда условие в одном из выражений условий не выполняется.

• Когда возникает ошибка проверки транзакции из-за более чем одного действия в тот же TransactWriteItems операция нацелена на тот же элемент.

• Когда запрос TransactWriteItems конфликтует с текущим TransactWriteItems операция над одним или несколькими элементами в TransactWriteItems запрос. В этом случае запрос завершается с ошибкой TransactionCanceledException .

• Когда для транзакции недостаточно выделенной емкости завершенный.

• Когда размер элемента становится слишком большим (более 400 КБ) или локальный вторичный индекс (LSI) становится слишком большим, или аналогичная ошибка проверки возникает из-за изменений совершается по сделке.

• При ошибке пользователя, такой как недопустимый формат данных.

Дополнительные сведения о конфликте с TransactWriteItems операции обрабатываются, см. Обработка конфликтов транзакций в ДинамоДБ.

TransactGetItems API

TransactGetItems — операция синхронного чтения, которая группирует до 100 Совершить действий вместе. Эти действия могут быть нацелены на до 100 различных элементов в одном или более таблиц DynamoDB в одной учетной записи AWS и регионе. Совокупный размер элементы в транзакции не могут превышать 4 МБ.

Действия Получить выполняются атомарно, так что либо все они завершатся успешно или все они терпят неудачу:

Обработка ошибок при чтении

Транзакции чтения не завершаются успешно при следующих обстоятельствах:

• Когда запрос TransactGetItems конфликтует с текущим TransactWriteItems операция над одним или несколькими элементами в Запрос TransactGetItems . В этом случае запрос завершается с ошибкой TransactionCanceledException .

• Когда для транзакции недостаточно выделенной емкости. завершенный.

• При ошибке пользователя, такой как недопустимый формат данных.

Дополнительные сведения о конфликте с TransactGetItems операции обрабатываются, см. Обработка конфликтов транзакций в ДинамоДБ.

Уровни изоляции для транзакций DynamoDB

Уровни изоляции транзакционных операций ( TransactWriteItems или TransactGetItems ) и другие операции.

SERIALIZABLE

Serializable Изоляция гарантирует, что результаты нескольких одновременные операции аналогичны ситуации, когда ни одна операция не начинается до тех пор, пока предыдущая не завершится. законченный.

Существует сериализуемая изоляция между следующими типами операций:

• Между любой транзакционной операцией и любой стандартной операцией записи ( PutItem , UpdateItem или DeleteItem ).

• Между любой транзакционной операцией и любой стандартной операцией чтения ( GetItem ).

• Между операцией TransactWriteItems и TransactGetItems операция.

Хотя существует сериализуемая изоляция между транзакционными операциями, и каждая индивидуальный стандарт пишет в BatchWriteItem операция, нет сериализуемая изоляция между транзакцией и BatchWriteItem работа как единое целое.

Аналогично, уровень изоляции между транзакционной операцией и отдельной GetItems в операции BatchGetItem является сериализуемой. Но уровень изоляции между транзакцией и операцией BatchGetItem как единица зафиксирована чтением .

Один запрос GetItem сериализуем по отношению к TransactWriteItems запрос одним из двух способов: до или после TransactWriteItems запрос. Несколько запросов GetItem против ключей в одновременных запросах TransactWriteItems можно запускать в любом порядке, и поэтому результаты read-committed .

Например, если GetItem запросов для элемента A и элемента B выполняются одновременно с запросом TransactWriteItems , который изменяет как элемент A, так и пункт B, есть четыре возможности:

• Оба запроса GetItem выполняются до TransactWriteItems запрос.

• Оба запроса GetItem выполняются после TransactWriteItems запрос.

• GetItem Запрос элемента A выполняется до TransactWriteItems запрос. Для элемента B запускается GetItem . после TransactWriteItems .

• GetItem запрос для элемента B выполняется до TransactWriteItems запрос. Для элемента A выполняется GetItem . после TransactWriteItems .

Если сериализуемый уровень изоляции предпочтителен для нескольких GetItem запросы, используйте TransactGetItems .

READ-COMMITTED

Read-committed Изоляция гарантирует, что операции чтения всегда возвращать зафиксированные значения для элемента — чтение никогда не будет отображать элемент представляющее состояние транзакционной записи, которая в конечном итоге не удалась. Изоляция с фиксированным чтением не предотвращает модификации элемента сразу после операция чтения.

Уровень изоляции зафиксирован между любой транзакционной операцией и любым чтением. операция, включающая несколько стандартных операций чтения ( BatchGetItem , Запрос или Сканирование ). Если транзакционная запись обновляет элемент в середина BatchGetItem , Query или Scan операция, последующая часть операции чтения возвращает вновь зафиксированное значение (с ConsistentRead) или, возможно, ранее зафиксированное значение (в конечном итоге согласованные чтения).

Сводка операций

Подводя итог, в следующей таблице показаны уровни изоляции между транзакциями операция ( TransactWriteItems или TransactGetItems ) и другие операции.

Эксплуатация	Уровень изоляции
УдалитьЭлемент	Сериализуемый
ПутИтем	Сериализуемый
Элемент обновления	Сериализуемый
GetItem	Сериализуемый
BatchGetItem	Чтение зафиксировано *
BatchWriteItem	НЕ сериализуемый *
Запрос	Чтение подтверждено
Скан	Чтение подтверждено
Прочие транзакционные операции	Сериализуемый

Уровни, отмеченные звездочкой (*), относятся к операции как к единице. Однако, отдельные действия внутри этих операций имеют сериализуемый уровень изоляции.

Обработка конфликтов транзакций в ДинамоДБ

Конфликт транзакций может возникнуть во время параллельных запросов на уровне элемента для элемента внутри транзакции. Конфликты транзакций могут возникать в следующих сценариях:

• A PutItem , UpdateItem или DeleteItem запрос для элемента конфликтует с текущим запросом TransactWriteItems , который включает один и тот же элемент.

• Элемент в пределах Запрос TransactWriteItems является частью другого текущего TransactWriteItems запрос.

• Элемент в запросе TransactGetItems является частью текущего TransactWriteItems , BatchWriteItem , PutItem , UpdateItem или DeleteItem запрос.

Примечание

• Когда PutItem , UpdateItem или DeleteItem запрос отклонен, запрос завершается с ошибкой TransactionConflictException .

• Если какой-либо запрос уровня элемента в пределах TransactWriteItems или TransactGetItems отклонен, запрос завершается с ошибкой TransactionCanceledException . Если этот запрос завершается неудачно, AWS SDK не повторите запрос.

  Если вы используете AWS SDK для Java, исключение содержит список CancellationReasons, упорядоченный в соответствии со списком элементов в TransactItems Параметр запроса. Для других языков строка представление списка включено в сообщение об ошибке исключения.

• Если текущий TransactWriteItems или TransactGetItems операция конфликтует с параллельным Запрос GetItem , обе операции может преуспеть.

Конфликт транзакций Метрика CloudWatch увеличивается для каждого неудачного запроса на уровне элемента.

Использование транзакционных API в DynamoDB Accelerator (DAX)

TransactWriteItems и TransactGetItems оба поддерживаются в DynamoDB Accelerator (DAX) с теми же уровнями изоляции, что и в DynamoDB.

TransactWriteItems пишет через DAX. DAX проходит TransactWriteItems вызывает DynamoDB и возвращает ответ. Чтобы заполнить кэш после записи, DAX вызывает TransactGetItems в фоновом режиме для каждого элемент в операции TransactWriteItems , которая потребляет дополнительное чтение единиц мощности. (Дополнительную информацию см. в разделе Управление мощностями для транзакций.) Эта функция позволяет логика вашего приложения проста и использует DAX как для транзакционных операций, так и нетранзакционные.

Вызовы TransactGetItems проходят через DAX без элементов кэшируется локально. Это то же поведение, что и для строго согласованных API чтения в ДАКС.

Управление емкостью для транзакций

Включение транзакций для таблиц DynamoDB не требует дополнительных затрат. Вы платите только для операций чтения или записи, которые являются частью вашей транзакции. DynamoDB выполняет два базовых читает или записывает каждый элемент в транзакции: один для подготовки транзакции и один для совершить транзакцию. Две основные операции чтения/записи видны в вашем Показатели Amazon CloudWatch.

Запланируйте дополнительные операции чтения и записи, необходимые для транзакционных API, когда вы выделяете ресурсы для своих таблиц. Например, предположим, что ваше приложение выполняет одну транзакцию в секунду, и каждая транзакция записывает три элемента по 500 байт в ваш стол. Для каждого элемента требуется две единицы емкости записи (WCU): одна для подготовки транзакции. и один для совершения транзакции. Следовательно, вам потребуется выделить шесть WCU для стол.

Если вы использовали DynamoDB Accelerator (DAX) в предыдущем примере, вы также использовали бы два чтения единицы емкости (RCU) для каждого элемента в вызове TransactWriteItems . Так что вы потребуется выделить шесть дополнительных RCU.

Аналогично, если ваше приложение выполняет одну транзакцию чтения в секунду, и каждая транзакция считывает три 500-байтовых элемента в вашей таблице, вам потребуется подготовить шесть операций чтения единиц мощности (RCU) в таблицу. Для чтения каждого элемента требуется два RCU: один для подготовки транзакции и один для фиксации транзакции.

Кроме того, SDK по умолчанию повторяет транзакции в случае Исключение TransactionInProgressException . Планируйте дополнительные единицы емкости чтения (RCU), потребляемые этими повторными попытками. То же самое верно, если вы повторяете попытку транзакции в вашем собственном коде с использованием ClientRequestToken .

Рекомендации по транзакциям

При использовании транзакций DynamoDB учитывайте следующие рекомендации.

• Включите автоматическое масштабирование для ваших таблиц или убедитесь, что вы подготовили достаточно пропускная способность для выполнения двух операций чтения или записи для каждого элемента в вашем сделка.

• Если вы не используете SDK, предоставленный AWS, включите Атрибут ClientRequestToken при создании TransactWriteItems , чтобы убедиться, что запрос является идемпотентным.

• Не группировать операции вместе в транзакции, если в этом нет необходимости. Например, если одну транзакцию с 10 операциями можно разбить на несколько транзакций без ущерба для корректности приложения, мы рекомендуем разделить сделка. Простые транзакции повышают пропускную способность и повышают вероятность успеха.

• Несколько транзакций, обновляющих одни и те же элементы одновременно, могут вызвать конфликты которые отменяют транзакции. Мы рекомендуем следовать рекомендациям DynamoDB по работе с данными. моделирование для минимизации таких конфликтов.

• Если набор атрибутов часто обновляется для нескольких элементов как часть одного транзакцию, рассмотрите возможность группировки атрибутов в один элемент, чтобы уменьшить объем перевод.

• Избегайте использования транзакций для массового приема данных. Для массовой записи лучше использовать BatchWriteItem .

Использование транзакционных API с глобальными столы

Транзакционные операции гарантируют атомарность, непротиворечивость, изоляцию и устойчивость (ACID) только в пределах региона, в котором изначально была сделана запись. Транзакции не поддерживаются между регионами в глобальных таблицах. Например, если у вас есть глобальная таблица с репликами на востоке США (Огайо) и Запад США (Орегон) и выполнить операцию TransactWriteItems в регионе Восток США (Сев. Вирджиния), вы можете наблюдать частично выполненные транзакции в регионе Запад США (Орегон) по мере репликации изменений. Изменения будут реплицированы в другие регионы только после того, как они были совершены в исходном регионе.

Транзакции DynamoDB и транзакции AWSLabs клиентская библиотека

Транзакции DynamoDB обеспечивают более экономичную, надежную и производительную замену клиентская библиотека транзакций AWSLabs. Мы предложить вам обновить свои приложения, чтобы использовать собственную транзакцию на стороне сервера API.

Javascript отключен или недоступен в вашем браузере.

Чтобы использовать документацию Amazon Web Services, должен быть включен Javascript.