Xử Lý Dữ Liệu Địa Lý Hiệu Quả Với DynamoDB
Giới thiệu
Xử lý dữ liệu địa lý trong DynamoDB có thể không phải là điều tự nhiên và có thể trông phức tạp. Tuy nhiên, nếu bạn áp dụng cách tiếp cận đúng đắn và thực hiện một số công việc chuẩn bị, bạn có thể tận dụng sức mạnh độc đáo của DynamoDB cho ứng dụng địa lý của mình.
Bài viết này sẽ hướng dẫn bạn cách tôi đã thực hiện điều này bằng cách sử dụng DynamoDB, với một tập dữ liệu ví dụ về dữ liệu thời tiết từ khoảng 5.000 sân bay toàn cầu. Cách tiếp cận cho việc cấu trúc và truy vấn dữ liệu địa lý bao gồm việc sử dụng nhiều chỉ mục geohash và một số kỹ thuật giảm cụm.
Mục tiêu cuối cùng:
- Truy vấn theo thời gian thực hoạt động với tốc độ nhanh ở bất kỳ mức độ chính xác nào.
- Thời gian phản hồi đồng nhất, bất kể kích thước hộp giới hạn.
- Truy vấn không bị ảnh hưởng bởi kích thước tập dữ liệu tổng thể: Không sử dụng các phép quét, chỉ truy vấn được tối ưu hóa.
- Một tập hợp kết quả ngẫu nhiên, phân phối đều, thay vì dữ liệu cụm từ một góc của hộp giới hạn.
Thách thức với Dữ liệu Địa lý trong DynamoDB
Về cơ bản, DynamoDB không cung cấp các truy vấn địa lý một cách tự nhiên. Bạn không thể đơn giản nói: "Cho tôi tất cả các điểm trong hộp giới hạn này."
Chúng ta cần phân tích vấn đề:
- Geohashing: Mã hóa vĩ độ và kinh độ thành một chuỗi ngắn gọn, có thứ tự.
- Mức độ chính xác: Các hộp giới hạn rộng hơn sử dụng geohash có độ chính xác thấp, trong khi các hộp nhỏ hơn sử dụng độ chính xác cao hơn.
- Chỉ mục: Tận dụng Khóa Phân vùng Chính và GSIs của DynamoDB để truy vấn dữ liệu ở mức độ chính xác phù hợp.
- Tiền tố phân vùng: Tránh các phân vùng nóng và cho phép lựa chọn ngẫu nhiên.
Thiết kế Bảng
Dưới đây là thiết kế mà tôi đã sử dụng để cho phép truy vấn ở nhiều mức độ chính xác:
| Khóa Phân vùng | Khóa Sắp xếp | Khóa Phân vùng GSI1 | Khóa Sắp xếp GSI1 |
|---|---|---|---|
| PK | SK | GSI1PK | GSI1SK |
<ShardID>#<GeoHash Precision 1> |
<GeoHash Precision 8> |
<GeoHash Precision 4> |
<GeoHash Precision 8> |
Điều quan trọng là:
ShardIDlà một số ngẫu nhiên (1–10 trong trường hợp mặc định) để phân phối dữ liệu qua các phân vùng.- Chúng ta phát tán các truy vấn song song, trả về một sự phân tán ngẫu nhiên của các kết quả.
Các mức độ chính xác có thể cấu hình dựa trên trường hợp sử dụng của bạn, nhưng trong thử nghiệm, tôi thấy cấu trúc này hoạt động tốt từ các truy vấn có độ chính xác rất thấp đến rất cao.
ShardID được sử dụng trên khóa phân vùng chính, trong khi GSI1 cho phép truy vấn ở mức độ chính xác trung bình mà không cần đến shard. Điều này mang lại hai lợi ích:
- Chúng ta không tạo ra một phân vùng nóng khi sử dụng geohash có độ chính xác rất thấp (ví dụ: truy vấn cấp độ thế giới) trên khóa phân vùng chính.
- Chúng ta có thể thực hiện các truy vấn có độ chính xác cao hơn (ví dụ: cấp độ thành phố) mà không cần phải bao gồm shard, điều này sẽ yêu cầu nhiều truy vấn để bao phủ tất cả các giá trị shard.
Các Loại Truy vấn
Tùy thuộc vào mức độ thu phóng của hộp giới hạn, chúng ta điều chỉnh động các khóa/chỉ mục được sử dụng:
- PK chỉ → Truy vấn quy mô thế giới
- PK + SK → Truy vấn theo quốc gia hoặc khu vực
- GSI1PK chỉ → Truy vấn cấp thành phố
- GSI1PK + GSI1SK → Truy vấn cấp thị trấn
Cách tiếp cận phân tầng này đảm bảo chúng ta luôn truy vấn ở mức độ chính xác đúng mà không lấy quá nhiều dữ liệu.
Phân Phối Kết Quả Ngẫu Nhiên
Nếu không có tiền tố phân vùng, các truy vấn DynamoDB thường trả về các kết quả cụm (ví dụ: tất cả từ góc "trên bên trái"). Bằng cách giới thiệu một tiền tố ShardID ngẫu nhiên, chúng ta đảm bảo các truy vấn phân tán qua các phân vùng và trả về một sự phân tán các điểm trong hộp giới hạn.
⚠️ Trước khi Truy vấn quy mô thế giới mà không có lưới → dữ liệu cụm:
✅ Sau khi Truy vấn quy mô thế giới với tiền tố phân vùng và lưới → dữ liệu phân phối đều:
Tối Ưu Hiệu Suất Với Lambda
Thời gian phản hồi đã được kiểm tra bằng cách sử dụng công cụ tuyệt vời Lambda Power Tuning.
Tại 1024MB, với các truy vấn hộp giới hạn lớn (cấp độ quận) trung bình khoảng 124ms. Tăng hoặc giảm bộ nhớ sẽ điều chỉnh thời gian phản hồi theo tỷ lệ mà không có bất kỳ đột biến không thể đoán trước nào.
Ví dụ: Truy Vấn Hộp Giới Hạn
Dưới đây là bảng so sánh kích thước hộp giới hạn, chỉ mục được sử dụng và hiệu suất trên tập dữ liệu khoảng 5.000 bản ghi:
| Cấp độ | Hộp Giới Hạn | Khoảng cách Đường chéo (Km) | Độ Chính xác Geohash | Chỉ mục Sử dụng | Số Truy Vấn DDB | Thời gian Phản hồi Trung Bình (1024MB) |
|---|---|---|---|---|---|---|
| Thế giới | (80, -170), (-80, 170) | 17,845 km | 1 | PK | 320 | 880 ms |
| Châu lục | (70, -25), (40, 30) | 4,568 km | 1 | PK | 40 | 150 ms |
| Quốc gia | (43, -10), (37, 2) | 1,220 km | 2 | PK + SK | 40 | 124 ms |
| Khu vực | (50, 8), (47, 13) | 497 km | 3 | PK + SK | 150 | 324 ms |
| Thành phố | (51.6, -0.45), (51.3, 0.2) | 56 km | 4 | GSI1 | 9 | 23 ms |
| Thị trấn | (37.041, -7.995), (37.006, -7.901) | 9 km | 4 | GSI1PK + GSI1SK | 3 | 11 ms |
Ngay cả các truy vấn quy mô thế giới cũng trả về kết quả trong chưa đầy một giây, với các điểm phân phối đều. Ngoài ra còn rất nhiều điều chúng ta có thể làm ở đây để tối ưu hóa hiệu suất của chức năng Lambda.
Điều này cho thấy cách tiếp cận mang lại thời gian phản hồi đồng nhất bất kể kích thước hộp giới hạn.
Bắt Đầu
Để bắt đầu với dự án ví dụ:
- Sao chép repo
- Triển khai stack CDK (xem README)
- Tải tập dữ liệu mẫu (5.000 sân bay với dữ liệu thời tiết METAR)
- Tải frontend và thử nghiệm với các truy vấn hộp giới hạn khác nhau
Bạn sẽ thấy rằng dù truy vấn toàn cầu hay một thị trấn nhỏ, thời gian phản hồi vẫn nhanh và kết quả được phân phối đều.
Cấu hình
Các băm và chỉ mục được sử dụng được cấu hình trong tập tin cấu hình môi trường: config/environment-config.ts và cấu hình truy vấn được cấu hình trong config/geospatial-config.ts, bao gồm các chỉ mục và độ chính xác cần sử dụng tùy theo kích thước hộp giới hạn.
Kiến trúc
Dự án demo bao gồm hai thành phần chính:
- Frontend: Ứng dụng web dựa trên React được phục vụ qua CloudFront. Được triển khai bằng AWS CDK.
- Backend: API không máy chủ được xây dựng bằng AWS Lambda và API Gateway, sử dụng DynamoDB để lưu trữ dữ liệu và kiến trúc dựa trên sự kiện để cập nhật theo thời gian thực. Được triển khai bằng AWS CDK.
Các dịch vụ AWS bao gồm:
- Amazon DynamoDB cho lưu trữ dữ liệu địa lý
- AWS Lambda cho tính toán không máy chủ
- AWS API Gateway cho quản lý REST API
- Amazon S3 cho lưu trữ tĩnh của frontend
- Amazon CloudFront cho phân phối nội dung
API
API cũng bao gồm một endpoint lộ trình sử dụng logic tương tự như truy vấn hộp giới hạn và sẽ trả về các điểm quan tâm dọc theo lộ trình. Phản hồi dữ liệu sẽ bao gồm tổng khoảng cách của lộ trình:
Bước Tiếp Theo
Cách tiếp cận này cung cấp một nền tảng vững chắc cho việc xử lý dữ liệu địa lý trong DynamoDB:
- Có khả năng mở rộng tới hàng triệu bản ghi
- Thời gian phản hồi đồng nhất
- Kết quả truy vấn ngẫu nhiên và phân phối tốt
Công việc trong tương lai có thể bao gồm:
- Các GSIs bổ sung cho các mức độ chính xác trung gian
- Hỗ trợ cho các truy vấn địa lý phức tạp hơn (ví dụ: bán kính, hàng xóm gần nhất)
- Cải thiện hiệu quả của việc giảm cụm. Hiện tại đây là một cách tiếp cận rất cơ bản và có thể được cải thiện với các thuật toán tiên tiến hơn.
Về Tôi
Tôi là Ian, một Chuyên gia AWS Serverless, Nhà xây dựng cộng đồng AWS và Kiến trúc sư đám mây được chứng nhận AWS có trụ sở tại Vương quốc Anh. Tôi làm việc như một tư vấn độc lập, đã làm việc trong nhiều lĩnh vực, với niềm đam mê về hàng không.
Hãy kết nối với tôi trên LinkedIn, hoặc tìm hiểu thêm về công việc của tôi tại Crockwell Solutions.
