Базовые операции

3. Базовые операции

3.1. Базовые операции (CRUD)

В SQL у вас есть универсальный SELECT, который может делать всё. В DynamoDB операции четко разделены по "стоимости" и эффективности. Понимание этого раздела спасет ваш бюджет.

Чтение данных: библиотечная аналогия

Представьте, что ваша таблица DynamoDB - это огромная городская библиотека. Есть способы найти книгу.

1. GetItem (заказ по шифру)

Самый быстрый и дешевый способ.

• Аналогия: Вы подходите к библиотекарю и даете точный шифр книги (ISBN): "Мне нужна книга с ID user_123". Библиотекарь идет и приносит ровно одну книгу.
• Что делает: Достает один элемент по его полному первичному ключу (PK + SK).
• Стоимость: 1 RCU (или 0.5 RCU при Eventually Consistent).
• Когда использовать: Когда вы точно знаете ID (например, открыть профиль пользователя по ссылке, открыть конкретный заказ).

# Дай мне пользователя "alice" (мы точно знаем ID)
response = table.get_item(
    Key={'user_id': 'alice'}
)
item = response.get('Item')

(Примечание: Операции Query и Scan, позволяющие искать группы элементов, мы подробно разберем в следующем модуле).

Запись данных: Полная замена vs Редактирование

Многие новички используют PutItem для всего. Это ошибка.

1. PutItem (замена листа)

• Что делает: Создает новый элемент или полностью заменяет старый.
• Аналогия: Вы берете страницу с данными пользователя, выкидываете её в мусорку и пишете новую с чистого листа.
• Опасность: Если на старой странице были важные пометки (атрибуты), которые вы забыли переписать на новую, они исчезнут.
• Пример: Вы хотели обновить только email, но использовали PutItem только с полями user_id и email. Поля name, age, address - стерлись, так как их не было в новом "листе".

# Осторожно! Это перезапишет весь объект.
table.put_item(
    Item={
        'user_id': 'alice',
        'email': '[email protected]'
        # Если тут были другие поля (Имя, Возраст) - они удалены!
    }
)

2. UpdateItem (правка)

Инструмент точечного изменения. Используйте его по умолчанию.

• Что делает: Изменяет только указанные атрибуты. Остальные не трогает.
• Аналогия: Вы берете существующий документ и дописываете карандашом одну строчку. Остальной текст остается на месте.
• Суперсила: Поддерживает атомарные счетчики (SET a = a + 1) и работу со списками/множествами (ADD tags :t).
• Upsert: Работает как "Create or Update". Если элемента не было, он создастся.

# Безопасно. Меняем только email, остальное не трогаем.
table.update_item(
    Key={'user_id': 'alice'},
    UpdateExpression="SET email = :new_email",
    ExpressionAttributeValues={':new_email': '[email protected]'},
    ReturnValues="UPDATED_NEW" # Вернет обновленные данные
)

3. DeleteItem

Просто удаляет элемент по ключу.

• Совет: Можно использовать с ConditionExpression. Например, "Удали пользователя, только если его статус 'Архив' (status = 'ARCHIVED')".

Резюме по операциям:

Пример: Атомарный счетчик (Numbers)

Как реализовать счетчик просмотров страницы без транзакций и блокировок?

table.update_item(
    Key={'page_id': 'home_page'},
    # Мы используем значение поля в самом выражении
    UpdateExpression="SET views_count = views_count + :incr",
    ExpressionAttributeValues={
        ':incr': 1
    },
    # Опционально: вернуть новое значение сразу же
    ReturnValues="UPDATED_NEW"
)
# Это потокобезопасно. Даже если 1000 человек кликнут одновременно,
# DynamoDB выстроит запросы в очередь и инкрементирует каждый.

3.2. PartiQL: SQL для NoSQL

Долгие годы входной порог в DynamoDB был высоким из-за специфического синтаксиса. Чтобы сделать простой SELECT, вам нужно было собирать JSON-монстров с параметрами вроде KeyConditionExpression и ExpressionAttributeValues.

AWS услышал эту боль и представил PartiQL - SQL-совместимый язык запросов для DynamoDB.

Теперь вы можете взаимодействовать с базой, используя старый добрый SELECT, INSERT, UPDATE и DELETE. Это работает и в консоли AWS, и в коде (через SDK).

Как это выглядит

Сравните, как выглядит получение заказа в классическом Boto3 и с использованием PartiQL.

Классический Boto3 (Native API):

response = table.get_item(
    Key={'order_id': '1001'}
)

PartiQL:

# Выглядит как обычный SQL
response = client.execute_statement(
    Statement='SELECT * FROM "Orders" WHERE "order_id" = \'1001\''
)

Кажется, что разницы мало. Но посмотрите на вставку данных:

PartiQL:

INSERT INTO "Orders" VALUE {'order_id': '1002', 'total': 50, 'status': 'NEW'}

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

Главная ловушка: Это НЕ реляционная база

Самая большая опасность PartiQL - иллюзия. Когда вы пишете SQL, ваш мозг переключается в режим реляционной базы. Вы думаете: "О, я могу пофильтровать по возрасту!".

Вы пишете:

SELECT * FROM "Users" WHERE age > 25

В PostgreSQL это нормальный запрос. В DynamoDB, если у вас нет индекса на поле age, этот запрос превратится в Full Table Scan.

1. PartiQL - это просто транслятор (синтаксический сахар).
2. Под капотом он преобразует ваш SQL в те же самые операции DynamoDB (Scan, Query, PutItem).
3. Если вы не укажете Partition Key в WHERE, PartiQL молча запустит Scan, прочтет всю таблицу, сожжет ваши деньги (RCU) и вернет результат медленно.

Правило: Даже используя PartiQL, вы обязаны знать архитектуру ключей. Эффективный SQL-запрос в DynamoDB всегда должен содержать условие равенства по первичному ключу.

Когда использовать PartiQL?

1. Ad-hoc запросы в консоли: Когда вам нужно быстро проверить, записались ли данные, или найти конкретный заказ. Писать SELECT в консоли в 10 раз быстрее, чем заполнять формы фильтров.
2. Миграции и скрипты: Если нужно написать простой скрипт для массового обновления статусов, SQL-синтаксис часто лаконичнее.
3. Onboarding новичков: Если в команду пришли люди, не знающие DynamoDB SDK, PartiQL позволит им начать писать код в первый же день, пока они изучают концепции PK/SK.

Когда НЕ использовать?

В сложном, высоконагруженном коде. Нативные методы API (get_item, query) более явные. Когда вы видите в коде table.scan(), вы сразу понимаете - тут опасно. Когда вы видите SELECT ..., опасность скрыта. В продакшене явное лучше неявного.

3.3. Практика