Đã đăng vào Thứ Hai, 8:55 SA 16 phút đọc

Những Thách Thức Khi Làm Việc Với DynamoDB Và Cách Xử Lý Hiệu Quả

💭 Liệu có bao giờ bạn tự hỏi, làm sao để tối ưu hóa việc sử dụng DynamoDB khi đối mặt với những giới hạn và thách thức của nó? DynamoDB là một dịch vụ NoSQL mạnh mẽ, nhưng không phải lúc nào việc sử dụng cũng suôn sẻ. Dưới đây là một số vấn đề phổ biến mà bạn có thể gặp phải cùng các giải pháp hiệu quả, dễ áp dụng. 🚀

1. Kích thước của một item vượt quá giới hạn 400 KB 😱

🤔 Bạn đã từng cần lưu trữ một bài viết dài hay một dữ liệu phức tạp lớn hơn 400 KB trong DynamoDB chưa? Đây là một thách thức phổ biến khi DynamoDB chỉ hỗ trợ kích thước tối đa 400 KB cho mỗi mục.

💡 Giải pháp

Dùng Amazon S3 🗂️: Lưu dữ liệu lớn trên S3 và chỉ lưu metadata trong DynamoDB.
Tách nhỏ dữ liệu ✂️: Chia dữ liệu thành nhiều phần nhỏ hơn và lưu với cùng Partition Key, đảm bảo khả năng truy xuất toàn bộ dữ liệu.

🌟 Ví dụ minh họa

1. Lưu dữ liệu lớn trên S3 và chỉ lưu metadata vào DynamoDB

Bạn đang phát triển một ứng dụng thương mại điện tử và cần lưu trữ hình ảnh sản phẩm. Vì kích thước hình ảnh thường lớn hơn 400 KB, bạn có thể lưu hình ảnh vào S3 và lưu thông tin metadata trong DynamoDB.

📸 Lưu hình ảnh vào S3 với một đường dẫn cụ thể:

Bucket: ecommerce-images
Key: products/product123/image1.jpg

📝 Metadata bao gồm đường dẫn S3 và các thông tin khác được lưu vào DynamoDB:

const AWS = require('aws-sdk');
const dynamoDB = new AWS.DynamoDB.DocumentClient();

const params = {
    TableName: 'ProductsTable',
    Item: {
        PK: 'PRODUCT#123',
        SK: 'IMAGE#1',
        S3Key: 'ecommerce-images/products/product123/image1.jpg',
        ProductName: 'Smartphone XYZ',
        Category: 'Electronics',
        UploadedAt: Date.now(),
    },
};

dynamoDB.put(params, (err) => {
    if (err) console.error('❌ Error saving metadata:', err);
    else console.log('✅ Metadata saved successfully.');
});

2. Tách nhỏ dữ liệu thành các phần nhỏ hơn

Nếu bạn cần lưu dữ liệu văn bản lớn hoặc cấu trúc phức tạp, bạn có thể chia nhỏ nó thành các phần và lưu chúng với cùng Partition Key, sử dụng Sort Key để định danh từng phần:

const largeData = '...'; // Dữ liệu lớn cần lưu
const chunks = [];
const chunkSize = 200000; // Kích thước mỗi phần (giới hạn 400 KB)

for (let i = 0; i < largeData.length; i += chunkSize) {
    chunks.push(largeData.slice(i, i + chunkSize));
}

chunks.forEach((chunk, index) => {
    const params = {
        TableName: 'LargeDataTable',
        Item: {
            PK: 'DATA#123',
            SK: `PART#${index + 1}`,
            Data: chunk,
        },
    };

    dynamoDB.put(params, (err) => {
        if (err) console.error(`❌ Error saving chunk #${index + 1}:`, err);
        else console.log(`✅ Chunk #${index + 1} saved successfully.`);
    });
});

Lợi ích của các giải pháp này

S3 với metadata:
- Hình ảnh hoặc dữ liệu lớn được lưu trữ an toàn trên S3 🛡️.
- DynamoDB chỉ quản lý metadata, tối ưu hóa hiệu suất và giảm chi phí lưu trữ.
Tách nhỏ dữ liệu:
- Đảm bảo lưu trữ được dữ liệu lớn trong DynamoDB.
- Dễ dàng hợp nhất dữ liệu khi cần truy xuất.

💡 Kết hợp các phương pháp này sẽ giúp bạn xử lý hiệu quả giới hạn kích thước của DynamoDB, đồng thời duy trì hiệu suất cao và chi phí hợp lý! 🚀

2. Dữ liệu trả về từ query/scan vượt quá giới hạn 1 MB 🚧

📊 Bạn đã từng gặp phải trường hợp cần lấy dữ liệu lớn nhưng bị giới hạn 1 MB? Điều này có thể gây khó khăn nếu bạn muốn lấy toàn bộ thông tin. Tuy nhiên, có một số cách để xử lý hiệu quả.

💡 Giải pháp

Sử dụng LastEvaluatedKey 🔁: Nếu dữ liệu trả về vượt quá giới hạn, tiếp tục truy vấn từ điểm dừng lần trước cho đến khi lấy được toàn bộ.
Dùng ProjectionExpression 🎯: Chỉ truy vấn những thuộc tính cần thiết để giảm kích thước dữ liệu trả về.

🌟 Ví dụ thực tế

Bạn muốn lấy tất cả đơn hàng của người dùng nhưng không cần toàn bộ thông tin chi tiết như mô tả sản phẩm hoặc hình ảnh. Khi đó, bạn có thể kết hợp cả hai giải pháp.

const AWS = require('aws-sdk');
const dynamoDB = new AWS.DynamoDB.DocumentClient();

async function fetchAllOrders(userId, projectionExpression) {
    let lastKey = null;
    let allOrders = [];

    do {
        const params = {
            TableName: 'OrdersTable',
            KeyConditionExpression: 'PK = :pk',
            ExpressionAttributeValues: { ':pk': `USER#${userId}` },
            ExclusiveStartKey: lastKey, // Tiếp tục từ điểm dừng
        };

        // Nếu projectionExpression được truyền, thêm vào params
        if (projectionExpression) {
            params.ProjectionExpression = projectionExpression;
        }

        const result = await dynamoDB.query(params).promise();
        allOrders = allOrders.concat(result.Items); // Gộp dữ liệu vào danh sách
        lastKey = result.LastEvaluatedKey; // Cập nhật LastEvaluatedKey
    } while (lastKey); // Tiếp tục nếu còn dữ liệu

    return allOrders;
}

// Sử dụng hàm
fetchAllOrders('123', 'OrderID, OrderDate, TotalAmount') // Chỉ lấy các trường cần thiết
    .then((orders) => console.log('✅ All Orders:', orders))
    .catch((err) => console.error('❌ Error fetching orders:', err));

🔗 Lợi ích khi kết hợp hai giải pháp

LastEvaluatedKey 🔄 giúp bạn lấy toàn bộ dữ liệu mà không vượt quá giới hạn 1 MB mỗi lần truy vấn.
ProjectionExpression ✂️ giảm kích thước của mỗi lần truy vấn bằng cách chỉ lấy những trường cần thiết, tăng tốc độ truy vấn và tiết kiệm chi phí.

🎯 Cách tiếp cận này không chỉ đảm bảo bạn lấy được tất cả dữ liệu mà còn tối ưu hóa hiệu suất hệ thống 🏎️.

🚀 Hãy áp dụng ngay để tối ưu hóa việc quản lý dữ liệu của bạn!

3. Lạm dụng lệnh Scan dẫn đến chi phí cao và hiệu suất thấp 💸⚡

📂 Bạn đã từng sử dụng lệnh Scan để tìm kiếm dữ liệu trên toàn bộ bảng DynamoDB chưa? Lệnh này không tối ưu khi bảng lớn, dẫn đến chi phí cao và hiệu suất kém. Tuy nhiên, có một số giải pháp giúp bạn có thể tối ưu hóa truy vấn và giảm chi phí đáng kể.

💡 Giải pháp

Tối ưu hóa với GSI (Global Secondary Index) 🗂️: Tạo các chỉ mục phụ hỗ trợ truy vấn theo các thuộc tính khác ngoài Partition Key chính.
FilterExpression 🎯: Trong trường hợp vẫn cần Scan, sử dụng FilterExpression để lọc dữ liệu ngay trên server.

Cách 1: Sử dụng GSI để tối ưu hóa truy vấn

GSI là gì?

GSI (Global Secondary Index) cho phép bạn định nghĩa Partition Key và Sort Key thay thế cho các truy vấn khác ngoài thiết kế bảng chính. Điều này rất hữu ích khi cần truy vấn dữ liệu với các thuộc tính khác mà không cần Scan toàn bảng.

Ví dụ thực tế

Bạn có bảng Products:

Partition Key (PK): Category (Loại sản phẩm).
Sort Key (SK): ProductID.

Bạn cần tìm tất cả các sản phẩm đã hết hạn sử dụng. Trong trường hợp này, bạn có thể tạo một GSI như sau:

GSI Partition Key: ExpirationStatus (có giá trị Expired hoặc Valid).
GSI Sort Key: ExpirationDate.

Tạo GSI: Trong AWS Console hoặc qua mã, bạn định nghĩa GSI cho bảng Products như sau:

{
  "IndexName": "ExpirationStatusIndex",
  "KeySchema": [
    { "AttributeName": "ExpirationStatus", "KeyType": "HASH" },
    { "AttributeName": "ExpirationDate", "KeyType": "RANGE" }
  ],
  "Projection": { "ProjectionType": "ALL" }
}

Truy vấn với GSI:
Sau khi tạo GSI, bạn có thể sử dụng query để lấy sản phẩm hết hạn mà không cần Scan toàn bảng.

const AWS = require('aws-sdk');
const dynamoDB = new AWS.DynamoDB.DocumentClient();

const params = {
    TableName: 'Products',
    IndexName: 'ExpirationStatusIndex', // Tên GSI
    KeyConditionExpression: 'ExpirationStatus = :status AND ExpirationDate <= :today',
    ExpressionAttributeValues: {
        ':status': 'Expired',
        ':today': new Date().toISOString(),
    },
};

dynamoDB.query(params, (err, data) => {
    if (err) console.error('❌ Query via GSI Failed:', err);
    else console.log('✅ Expired Products:', data.Items);
});

Khi nào sử dụng GSI?

Khi cần tìm kiếm hoặc lọc dữ liệu dựa trên các thuộc tính không phải là Partition Key hoặc Sort Key của bảng chính.
Khi các truy vấn thường xuyên không thể được tối ưu hóa với thiết kế hiện tại của bảng.

Lợi ích của GSI

🚀 Hiệu suất cao hơn: Truy vấn nhanh hơn nhiều so với Scan toàn bảng.
🎯 Đa dạng hóa truy vấn: Hỗ trợ nhiều kiểu tìm kiếm khác nhau.
💰 Tiết kiệm chi phí: Hạn chế quét toàn bảng, giảm tài nguyên và băng thông.

Ghi chú quan trọng

Mặc dù GSI mang lại nhiều lợi ích trong việc tối ưu hóa truy vấn, nhưng nó vẫn có một số hạn chế và tác hại mà bạn cần cân nhắc:

Chi phí: Mỗi GSI đều phát sinh chi phí lưu trữ và truy vấn riêng. Hãy theo dõi sát sao chi phí vận hành.
Độ trễ đồng bộ: Dữ liệu từ bảng chính được đồng bộ hóa với GSI, nhưng đôi khi có thể xảy ra độ trễ.
Giới hạn số lượng GSI: DynamoDB chỉ cho phép tối đa 20 GSI trên mỗi bảng.

Tôi sẽ chia sẻ chi tiết hơn về các hạn chế này và cách giảm thiểu rủi ro trong một bài viết riêng. Hãy đảm bảo bạn hiểu rõ để sử dụng GSI hiệu quả và tránh các vấn đề không mong muốn! 🚨

Cách 2: Sử dụng Scan với FilterExpression

Nếu không thể tạo thêm GSI hoặc thiết kế lại bảng, bạn có thể cải thiện Scan bằng cách sử dụng FilterExpression. Dù không tối ưu bằng GSI, cách này vẫn giảm đáng kể kích thước dữ liệu trả về.

const params = {
    TableName: 'Products',
    FilterExpression: 'ExpirationDate <= :today', // Lọc sản phẩm hết hạn
    ExpressionAttributeValues: {
        ':today': new Date().toISOString(),
    },
};

dynamoDB.scan(params, (err, data) => {
    if (err) console.error('❌ Scan Failed:', err);
    else console.log('✅ Expired Products:', data.Items);
});

Tóm tắt

GSI: Lựa chọn hàng đầu để tăng hiệu suất và giảm chi phí.
FilterExpression: Giải pháp tạm thời khi không thể áp dụng GSI.

💡 DynamoDB là công cụ mạnh mẽ, nhưng việc thiết kế bảng hợp lý và sử dụng các giải pháp như GSI hoặc FilterExpression là chìa khóa để khai thác tối đa hiệu quả của nó. 🚀

4. Không hỗ trợ phân trang trực tiếp như SQL 🌀

📋 Bạn muốn phân trang dữ liệu như SQL (LIMIT OFFSET) nhưng lại không thể thực hiện trực tiếp với DynamoDB? Điều này là do DynamoDB không hỗ trợ cú pháp OFFSET. Thay vào đó, bạn có thể sử dụng LastEvaluatedKey, một cơ chế hiệu quả để lấy dữ liệu theo từng trang mà không cần phải duyệt qua dữ liệu đã lấy trước đó.

💡 Giải pháp

Sử dụng LastEvaluatedKey: DynamoDB trả về một LastEvaluatedKey sau mỗi truy vấn. Bạn dùng khóa này để bắt đầu truy vấn tiếp theo, giúp truy vấn hiệu quả và tiết kiệm tài nguyên.

🌟 Ví dụ minh họa

Dưới đây là cách bạn có thể lấy dữ liệu phân trang bằng LastEvaluatedKey:

const AWS = require('aws-sdk');
const docClient = new AWS.DynamoDB.DocumentClient();

async function getPageData(previousKey) {
    const params = {
        TableName: "Products",
        Limit: 20, // Giới hạn 20 sản phẩm/lần
        ExclusiveStartKey: previousKey // Khoá trước đã lưu (nếu có)
    };

    const result = await docClient.scan(params).promise();
    console.log("Page Data:", result.Items);
    console.log("Next Key:", result.LastEvaluatedKey); // Khoá tiếp theo để phân trang

    return {
        items: result.Items, // Dữ liệu của trang hiện tại
        nextKey: result.LastEvaluatedKey, // Khoá để lấy trang tiếp theo
    };
}

// Gọi hàm
(async () => {
    let previousKey = null; // Bắt đầu từ trang đầu tiên
    const { items, nextKey } = await getPageData(previousKey);

    console.log("Fetched Items:", items);
    console.log("Next Key for Next Page:", nextKey);

    // Có thể tiếp tục gọi getPageData(nextKey) để lấy trang tiếp theo
})();

Ưu điểm của LastEvaluatedKey

Hiệu quả: Không cần duyệt qua dữ liệu đã lấy trước đó.
Dễ dàng triển khai: Dựa trên kết quả của truy vấn trước để tiếp tục.

Lưu ý

Không hỗ trợ nhảy trang:
- DynamoDB không cho phép nhảy trực tiếp đến một trang cụ thể như OFFSET trong SQL. Bạn phải lần lượt lấy dữ liệu qua từng trang.
- Để nhảy trang, bạn cần lưu trữ LastEvaluatedKey của từng trang trước đó để sử dụng khi cần.
Phụ thuộc vào thứ tự sắp xếp dữ liệu:
- DynamoDB trả về dữ liệu theo thứ tự của Partition Key và Sort Key.
- Nếu không có Sort Key, thứ tự kết quả có thể không như mong muốn.

Khi nào nên dùng LastEvaluatedKey?

Khi cần lấy dữ liệu theo từng trang, đặc biệt với bảng lớn.
Khi không cần truy cập trực tiếp đến các trang giữa hoặc cụ thể.

💡 Phân trang bằng LastEvaluatedKey không chỉ hiệu quả mà còn giúp bạn tiết kiệm chi phí và tối ưu hóa tài nguyên DynamoDB. 🚀

5. Lỗi Throttled khi vượt quá giới hạn ghi 🚨

🔧 Bạn đã bao giờ gặp lỗi ProvisionedThroughputExceededException khi DynamoDB bị quá tải do ghi dữ liệu quá nhiều trong một khoảng thời gian ngắn? Đây là lỗi thường gặp khi công suất ghi không đủ đáp ứng. Tuy nhiên, bạn có thể giải quyết vấn đề này bằng một số cách hiệu quả.

💡 Giải pháp

Bật Auto Scaling: DynamoDB sẽ tự động điều chỉnh công suất ghi và đọc của bảng dựa trên nhu cầu thực tế, giảm thiểu rủi ro bị quá tải.
Batch Write: Gom nhóm nhiều ghi vào một lệnh để giảm số lần tương tác với DynamoDB.

🌟 Ví dụ minh họa

Bật Auto Scaling

Trong AWS Console:

Mở bảng DynamoDB của bạn.
Đi tới tab Capacity.
Bật Auto Scaling cho cả Read và Write Capacity.
Đặt các ngưỡng tối thiểu và tối đa phù hợp với nhu cầu.

Sử dụng Batch Write

Ghi nhiều mục cùng lúc bằng batchWrite:

const AWS = require('aws-sdk');
const dynamoDB = new AWS.DynamoDB.DocumentClient();

const params = {
    RequestItems: {
        MyTable: [
            {
                PutRequest: {
                    Item: { PK: 'USER#123', SK: 'ORDER#001', Status: 'PENDING' },
                },
            },
            {
                PutRequest: {
                    Item: { PK: 'USER#123', SK: 'ORDER#002', Status: 'SHIPPED' },
                },
            },
            {
                PutRequest: {
                    Item: { PK: 'USER#124', SK: 'ORDER#003', Status: 'DELIVERED' },
                },
            },
        ],
    },
};

dynamoDB.batchWrite(params, (err, data) => {
    if (err) {
        console.error('❌ Batch Write Failed:', err);
    } else {
        console.log('✅ Batch Write Success:', data);
    }
});

Lưu ý quan trọng khi sử dụng Batch Write

Giới hạn kích thước: Mỗi yêu cầu batchWrite chỉ cho phép tối đa 25 mục hoặc 16 MB dữ liệu.
Kiểm tra lại mục chưa xử lý: batchWrite có thể trả về các mục chưa được xử lý. Bạn cần kiểm tra trong trường UnprocessedItems và ghi lại các mục này nếu cần.

Tóm tắt

Bật Auto Scaling: Giải pháp lâu dài và tự động hóa để đảm bảo công suất ghi luôn đủ.
Batch Write: Giải pháp hiệu quả để giảm số lần ghi và tối ưu hóa hiệu suất.

💡 Với các giải pháp trên, bạn có thể giảm thiểu nguy cơ bị throttled khi ghi dữ liệu và đảm bảo hệ thống hoạt động mượt mà hơn! 🚀

6. Lỗi TransactionConflictException khi ghi đồng thời ⚠️

🔄 Liệu bạn có từng đối mặt với xung đột khi nhiều người dùng hoặc hệ thống cố gắng cập nhật cùng một mục trong DynamoDB? Đây là lỗi phổ biến xảy ra khi các ghi đồng thời can thiệp lẫn nhau, dẫn đến xung đột trong giao dịch.

💡 Giải pháp

Optimistic Locking: Sử dụng một trường Version để kiểm soát xung đột và chỉ cho phép cập nhật khi phiên bản hiện tại khớp.
Giảm ghi đồng thời: Tối ưu hóa luồng dữ liệu hoặc phân chia các nhiệm vụ ghi để giảm thiểu tình trạng nhiều hệ thống ghi vào cùng một mục cùng lúc.

🌟 Ví dụ minh họa

Cập nhật chỉ khi phiên bản khớp (Optimistic Locking)

Bạn có thể sử dụng điều kiện trong DynamoDB để đảm bảo chỉ ghi dữ liệu nếu phiên bản (Version) hiện tại là giá trị mong đợi.

const AWS = require('aws-sdk');
const dynamoDB = new AWS.DynamoDB.DocumentClient();

const params = {
    TableName: 'MyTable',
    Key: { PK: 'USER#123', SK: 'PROFILE' },
    UpdateExpression: 'SET Name = :name, Version = :newVersion',
    ConditionExpression: 'Version = :currentVersion',
    ExpressionAttributeValues: {
        ':name': 'New Name',           // Giá trị mới cần cập nhật
        ':newVersion': 2,             // Tăng version
        ':currentVersion': 1,         // Chỉ cập nhật nếu version hiện tại là 1
    },
};

dynamoDB.update(params, (err, data) => {
    if (err) {
        console.error('❌ Update Failed:', err.message);
    } else {
        console.log('✅ Update Success:', data);
    }
});

Khi nào nên sử dụng Optimistic Locking?

Khi dữ liệu có khả năng bị cập nhật đồng thời.
Khi bạn cần đảm bảo rằng dữ liệu không bị ghi đè bởi các tác vụ khác.

Giảm ghi đồng thời

Nếu lỗi xảy ra do số lượng tác vụ ghi đồng thời quá lớn, bạn có thể áp dụng các kỹ thuật sau:

Phân chia dữ liệu ghi:
- Sử dụng Partition Key khác nhau cho các mục có khả năng bị ghi đồng thời.
Tối ưu hóa luồng dữ liệu:
- Giảm tần suất ghi bằng cách sử dụng một bộ đệm hoặc chỉ ghi dữ liệu khi thực sự cần thiết.

Kết luận

💡 DynamoDB là một công cụ mạnh mẽ, nhưng để tận dụng tối đa hiệu suất, bạn cần nắm rõ các kỹ thuật xử lý lỗi và tối ưu hóa như trên.

Liệu bạn đã sẵn sàng giải quyết những thách thức để tận dụng tối đa sức mạnh của DynamoDB? Hãy áp dụng những giải pháp này và chia sẻ kinh nghiệm của bạn trong phần bình luận nhé! 🚀

1. Kích thước của một item vượt quá giới hạn 400 KB 😱

💡 Giải pháp

🌟 Ví dụ minh họa

1. Lưu dữ liệu lớn trên S3 và chỉ lưu metadata vào DynamoDB

2. Tách nhỏ dữ liệu thành các phần nhỏ hơn

Lợi ích của các giải pháp này

2. Dữ liệu trả về từ query/scan vượt quá giới hạn 1 MB 🚧

💡 Giải pháp

🌟 Ví dụ thực tế

🔗 Lợi ích khi kết hợp hai giải pháp

3. Lạm dụng lệnh Scan dẫn đến chi phí cao và hiệu suất thấp 💸⚡

💡 Giải pháp

Cách 1: Sử dụng GSI để tối ưu hóa truy vấn

GSI là gì?

Ví dụ thực tế

Khi nào sử dụng GSI?

Lợi ích của GSI

Ghi chú quan trọng

Cách 2: Sử dụng Scan với FilterExpression

Tóm tắt

4. Không hỗ trợ phân trang trực tiếp như SQL 🌀

💡 Giải pháp

🌟 Ví dụ minh họa

Ưu điểm của LastEvaluatedKey

Lưu ý

Khi nào nên dùng LastEvaluatedKey?

5. Lỗi Throttled khi vượt quá giới hạn ghi 🚨

💡 Giải pháp

🌟 Ví dụ minh họa

Bật Auto Scaling

Sử dụng Batch Write

Lưu ý quan trọng khi sử dụng Batch Write

Tóm tắt

6. Lỗi TransactionConflictException khi ghi đồng thời ⚠️

💡 Giải pháp

🌟 Ví dụ minh họa

Cập nhật chỉ khi phiên bản khớp (Optimistic Locking)

Khi nào nên sử dụng Optimistic Locking?

Giảm ghi đồng thời

Kết luận

Mục lục