AWS Redshift

Xin chào mọi người! Trong bài viết trước, chúng ta đã so sánh tốc độ truy vấn giữa MongoDB và Redshift. Bạn đã nhận thấy tốc độ truy vấn đáng kinh ngạc của Redshift so với MongoDB. Trong bài viết này, tôi sẽ giới thiệu với bạn về cấu trúc của Redshift, cách Redshift thực hiện truy vấn để hiểu tại sao Redshift có khả năng mạnh mẽ như vậy.

1. Kiến trúc hệ thống tổng quát

Tiếp theo, chúng ta sẽ đi vào chi tiết kiến trúc của Redshift. Dưới đây là hình vẽ mô tả kiến trúc của Redshift.

Ứng dụng khách hàng và kết nối

Amazon Redshift được xây dựng dựa trên PostgreSQL với một số thay đổi nhỏ. Do đó, nếu ứng dụng của bạn sử dụng SQL, bạn chỉ cần thực hiện vài thay đổi nhỏ để chuyển sang Redshift. Bạn có thể tìm hiểu sự khác biệt giữa PostgreSQL và Redshift tại đường link dưới đây.

Vì nó được xây dựng dựa trên PostgreSQL, Redshift hỗ trợ kết nối giữa ứng dụng và hệ thống thông qua các trình điều khiển JDBC và ODBC.

Cluster

Bây giờ chúng ta sẽ đi sâu hơn vào cấu trúc của Redshift. Thành phần chính trong kiến trúc của Redshift là Cluster. Trong một Cluster, có một hoặc nhiều Database. Để truy cập vào Cluster, bạn cần dung một đường dẫn đến Cluster, tên cơ sở dữ liệu và mật khẩu. Mỗi Cluster được hình thành từ một hoặc nhiều Node. Khi một Cluster được tạo từ nhiều Node, Redshift sinh thêm Leader Node.

Leader Node

Nhiệm vụ đầu tiên của Leader Node là kết nối với ứng dụng để nhận truy vấn và trả kết quả. Nhiệm vụ thứ hai là xử lý và truyền kế hoạch thực hiện truy vấn đến mỗi Compute Node. Đối với các truy vấn phức tạp, Leader Node còn truyền các bước truy vấn xuống các Compute Node và tổng hợp kết quả trả về từ Compute Node để có được kết quả cuối cùng. Vì vậy, quá trình xử lý truy vấn và tổng hợp kết quả được thực hiện bởi Leader Node hoặc các Node con tuỳ thuộc vào truy vấn.

Compute Node

Compute Node là nơi thực hiện các truy vấn và trả kết quả về Leader Node. Điểm độc đáo ở đây là mỗi Compute Node có CPU, bộ nhớ và bộ nhớ lưu trữ riêng của mình. Cấu hình cụ thể phụ thuộc vào kế hoạch mà bạn chọn khi tạo Cluster. Ví dụ, nếu dữ liệu của bạn rất lớn, bạn có thể chọn tối đa 36 vCPU, 244GB bộ nhớ và 16TB bộ nhớ lưu trữ (hehe). Bạn có thể tham khảo liên kết dưới đây để biết chi tiết về cấu hình từng Cluster và Node:

Có Thể Bạn Quan Tâm :  

https://aws.amazon.com/redshift/pricing/

Node Slices

Mỗi Compute Node được chia nhỏ thành các Node Slice. Mỗi Node Slice sẽ chia sẻ CPU, bộ nhớ và bộ nhớ lưu trữ từ Compute Node đó. Với một truy vấn nhất định, Compute Node tiếp tục chuyển cho mỗi Node Slice để các Node Slice này thực hiện truy vấn đồng thời.

Mạng nội bộ

Thành phần cuối cùng là Mạng nội bộ. Redshift sử dụng một hệ thống mạng riêng với băng thông rộng và tốc độ cao để kết nối giữa Leader Node và Compute Node. Đây là yếu tố quan trọng đảm bảo việc truyền truy vấn từ Leader Node đến Compute Node và truyền kết quả từ Compute Node đến Leader Node. Đây cũng là một thành phần rất quan trọng ảnh hưởng đến thời gian truy vấn mà chúng ta sẽ giới thiệu sau này.

2. Lưu trữ dữ liệu

Phong cách phân phối

Tiếp theo, tôi sẽ nói một chút về việc lưu trữ dữ liệu trong Redshift. Như đã đề cập ở trên, nhỏ nhất trong cấu trúc Redshift là các Node Slices và dữ liệu của bạn được lưu trữ trên các Node Slice này. Vậy Redshift phân phối dữ liệu đến các Node Slices như thế nào.

Khi bạn tạo một bảng, bạn cần chỉ định một trường là Khóa Phân phối. Khóa phân phối là một cột trong bảng của bạn, và Redshift sẽ sử dụng giá trị của cột này để phân phối dữ liệu đến các node slices tương ứng. Hiểu đơn giản, ví dụ bạn chọn khóa phân phối là cột ngày. Khi đó, những bản ghi có ngày 2016-04-24 sẽ được lưu trữ trên cùng một Node Slice hoặc cùng một Node nếu có quá nhiều bản ghi với ngày 2016-04-24 … Việc phân phối và lưu trữ dữ liệu trên Node và Node Slice được quyết định và thực hiện bởi Leader Node.

Ví dụ khi bạn truy vấn là ngày BETWEEN 2016-04-24 và 2016-04-25, Leader Node sẽ thấy rằng các ngày 2016-04-24 và 2016-04-25 chỉ được lưu trữ trên Node 1 và Node 2. Khi đó, chỉ có 2 node này thực hiện truy vấn. Điều này giúp tránh việc xử lý dữ liệu không cần thiết. Vì vậy, việc chọn Khóa Phân phối rất quan trọng trong thiết kế bảng.

Lưu trữ dữ liệu theo cột

Lưu trữ dữ liệu theo cột đơn giản hiểu là lưu trữ dữ liệu theo từng cột. Đây là một trong những yếu tố quan trọng giúp giảm yêu cầu I / O và lượng dữ liệu cần phải tải trong quá trình truy vấn.

Có Thể Bạn Quan Tâm :   Xịt chống nắng Maycreate có tốt không? Giá bao nhiêu?

Kiểu lưu trữ dữ liệu truyền thống là theo hàng (lưu trữ cơ sở dữ liệu theo hàng) như bạn thấy ở dưới đây.

Mỗi khối lưu trữ dữ liệu của một hàng. Nghĩa là nếu kích thước hàng lớn hơn kích thước khối, bạn cần nhiều khối hơn để lưu trữ dữ liệu, trong khi nếu kích thước hàng nhỏ hơn kích thước khối, một khối sẽ lưu trữ ít nhất 2 hàng. Kiểu lưu trữ này phù hợp với ứng dụng xử lý giao dịch trực tuyến (OLTP). Trong loại ứng dụng này, việc đọc và ghi liên quan đến toàn bộ hoặc chỉ một lượng nhỏ dữ liệu. Vì vậy, không cần tối ưu số khối đọc và ghi.

Redshift sử dụng Columnar Data Storage, lưu trữ theo cột như bạn thấy dưới đây.

Như bạn thấy, trên một khối, thay vì lưu trữ một hàng, chúng ta lưu trữ theo cột. Dĩ nhiên, trong bài viết này, tôi sẽ không đi sâu vào so sánh giữa Columnar Storage và Row-Wise Storage (chắc là sẽ có một bài riêng cho phần này (hihi)). Ở đây, tôi chỉ nói về điểm mạnh của Columnar Data Storage:

  • Có khả năng truy vấn mạnh mẽ khi phải truy vấn lượng dữ liệu lớn.
  • Khả năng nén dữ liệu cao, giảm lượng dữ liệu cần xử lý.
  • Tốc độ truy vấn tốt nếu chỉ liên quan đến một hoặc một vài cột trong bảng.

Column được lưu trữ trên khối theo thứ tự được xác định bởi Khóa Sắp xếp mà bạn khai báo khi tạo bảng.

3. Hiệu suất

Quay trở lại với vấn đề chính, tại sao Redshift có thể có tốc độ truy vấn nhanh với lượng dữ liệu lớn. Có lẽ qua phần giới thiệu về hệ thống của Redshift, bạn đã có thể đoán được một phần. Dưới đây là những lý do chính.

Xử lý song song cực lớn

Với cấu trúc phân chia dữ liệu vào các compute node, các compute node lại được chia nhỏ thành các node slice. Và các node slice lại được cung cấp CPU, bộ nhớ, bộ nhớ lưu trữ để xử lý dữ liệu song song, rõ ràng là tốc độ truy vấn sẽ nhanh hơn rất nhiều. Ví dụ, nếu bạn chọn cluster là ds1.xlarge với tối đa 32 node, mỗi node có tối đa 2 slice, với 64 tiến trình truy vấn song song rõ ràng là nhanh hơn so với 1 tiến trình. Con số này sẽ còn kinh khủng hơn khi sử dụng cluster dc1.8xlarge với tối đa 128 nodes và tối đa 32 slices trên một node (tất nhiên, nếu bạn chọn cục này, bạn đã tiêu rất nhiều tiền rồi (hihi)).

Có Thể Bạn Quan Tâm :   TRƯỜNG DỮ LIỆU LÀ GÌ ? CÁC MÔ HÌNH CƠ SỞ DỮ LIỆU THÔNG DỤNG TRƯỜNG (KHOA HỌC MÁY TÍNH)

Lưu trữ dữ liệu theo cột

Như đã nói ở trên, việc lưu trữ dữ liệu theo cột giúp giảm yêu cầu I / O và lượng dữ liệu cần phải tải. Lưu trữ dữ liệu theo cột rất hữu ích khi dữ liệu của bạn rất lớn. Đây cũng là một trong những lý do chính giúp Redshift có tốc độ truy vấn rất nhanh khi so sánh với MongoDB trong bài viết trước của tôi.

Nén dữ liệu

Với kiểu lưu trữ dữ liệu theo cột, Redshift cũng ấn tượng với khả năng nén dữ liệu. Với bảng có 8,5 triệu bản ghi như của tôi, nếu dữ liệu chiếm 4,5GB ở MongoDB, chỉ còn gần 1GB ở Redshift, điều này giúp giảm rất nhiều lượng dữ liệu cần xử lý, qua đó nâng cao hiệu năng. Redshift cung cấp nhiều kiểu mã hóa dữ liệu như raw, byte, delta, lzo … để bạn lựa chọn, từ đó nén dữ liệu của bạn một cách tối ưu nhất.

Trình tối ưu truy vấn

Bộ xử lý truy vấn của Redshift có khả năng tối ưu hóa truy vấn sử dụng (MPP-aware (Massive Parallel Processing)) [https://en.wikipedia.org/wiki/Massively_parallel_(computing)] và những lợi ích từ việc lưu trữ dữ liệu theo cột. Khi nhận được một truy vấn, bộ xử lý chuyển kế hoạch truy vấn thành mã và sau đó chuyển mã đó đến Compute Node để thực hiện. Để hiểu rõ hơn về kế hoạch truy vấn và luồng thực hiện, bạn có thể tham khảo liên kết dưới đây:

http://docs.aws.amazon.com/redshift/latest/dg/c-query-processing.html

Ngoài ra, Redshift còn cung cấp nhiều bảng sẵn có để phân tích luồng truy vấn và giúp bạn cải thiện truy vấn. Ví dụ, bảng SVL_QUERY_SUMMARY cung cấp thống kê truy vấn theo luồng, bảng SVL_QUERY_REPORT cung cấp thông tin truy vấn theo Node Slice, hoặc STL_ALERT_EVENT_LOG lưu trữ các thông báo ảnh hưởng đến hiệu suất truy vấn … Bạn có thể tham khảo cách phân tích, cải thiện truy vấn theo liên kết dưới đây:

http://docs.aws.amazon.com/redshift/latest/dg/c-query-tuning.html

4. Kết luận

Trong bài viết này, tôi đã giới thiệu về hệ thống Redshift và giải thích một phần lý do tại sao Redshift có hiệu suất tốt. Tuy nhiên, để tận dụng hết hiệu suất của Redshift, cần có các gợi ý riêng, đặc biệt là đối với thiết kế bảng.

Trong bài viết tiếp theo, tôi sẽ giới thiệu cho bạn cách thiết kế bảng tối ưu trong Redshift. Đây cũng là cách giúp tôi giảm thời gian truy vấn từ 10 giây xuống còn 4 giây như tôi đã đề cập trong bài viết trước đó (hehe).

Xin hẹn gặp lại các bạn trong bài viết sau (chào).

Back to top button