Моделювання даних з DynamoDB та Spring Boot: від теорії до практики - javascript.org.ua

Вступ

Використання баз даних NoSQL значно зросло в останні роки, і Amazon DynamoDB виділяється своєю масштабованістю та низькою затримкою. Однак, на відміну від реляційних баз даних, моделювання даних у DynamoDB вимагає іншого підходу, оскільки вона не використовує нормалізацію або JOIN.

У цій статті ми розглянемо:

Як правильно моделювати дані в DynamoDB
Основні відмінності між NoSQL і SQL
Як інтегрувати DynamoDB з Spring Boot
Практичні приклади впровадження та оптимізації

1. SQL проти NoSQL: Що змінюється в моделюванні даних?

Основна відмінність при роботі з DynamoDB полягає в тому, що моделювання даних ґрунтується на шляхах доступу, а не на структурі. У SQL базах даних ми організовуємо дані в нормалізованому форматі для уникнення надмірності. В DynamoDB дані зберігаються в денормалізованому форматі, щоб оптимізувати запити.

2. Як моделювати дані в DynamoDB?

Кожна таблиця в DynamoDB повинна мати первинний ключ, яким може бути:

Простий → Тільки ключ розподілу (PK).
Складений → Ключ розподілу (PK) та ключ сортування (SK).

3. Вторинні індекси (GSI та LSI): Коли їх використовувати?

DynamoDB надає вторинні індекси для підвищення гнучкості запитів:

GSI (Global Secondary Index) → Індексує атрибути, відмінні від первинного ключа.
LSI (Local Secondary Index) → Дозволяє запитувати за другим ключем сортування в межах одного ключа розподілу.

Приклад: Отримання замовлень за статусом

Якщо нам потрібно отримати замовлення зі статусом "в очікуванні", ми можемо створити GSI:

PK = статус
SK = orderId

Це дозволяє нам ефективно запитувати всі замовлення в очікуванні без сканування всієї таблиці.

4. Реалізація DynamoDB з Spring Boot

4.1 Додавання залежностей

Додайте SDK DynamoDB у файл pom.xml:


 software.amazon.awssdk  
 dynamodb

4.2 Налаштування клієнта DynamoDB

@Configuration  
public class DynamoDBConfig {  

 @Bean  
 public DynamoDbClient dynamoDbClient() {  
 return DynamoDbClient.builder()  
 .region(Region.US_EAST_1)  
 .build();  
 }  
}

4.3 Створення репозиторію

@Repository  
public class OrderRepository {  

 private final DynamoDbClient dynamoDbClient;  

 @Autowired  
 public OrderRepository(DynamoDbClient dynamoDbClient) {  
 this.dynamoDbClient = dynamoDbClient;  
 }  

 public void saveOrder(Order order) {  
 Map item = new HashMap<>();  
 item.put("PK", AttributeValue.builder().s("CUSTOMER#" + order.getCustomerId()).build());  
 item.put("SK", AttributeValue.builder().s("ORDER#" + order.getOrderId()).build());  
 item.put("total", AttributeValue.builder().n(order.getTotal().toString()).build());  

 PutItemRequest request = PutItemRequest.builder()  
 .tableName("OrdersTable")  
 .item(item)  
 .build();  

 dynamoDbClient.putItem(request);  
 }  
}

5. Висновок: Моделюйте для запитів, а не для структури

Після експериментів з різними підходами стає зрозуміло, що DynamoDB не про таблиці, а про шляхи доступу.

Автоматична масштабованість → DynamoDB автоматично розподіляє дані.
Менше JOIN, краща продуктивність → Оптимізований доступ зменшує кількість запитів.
Низькі витрати → Ефективні запити зменшують витрати на читання/запис в AWS.

Правильне моделювання даних має велике значення для продуктивності та вартості в DynamoDB. Кожен випадок використання може вимагати коригувань, тому важливо спланувати шляхи доступу до того, як проектувати структуру таблиці.

Перекладено з: Data Modeling with DynamoDB and Spring Boot: From Theory to Practice