Xin chào tất cả những bạn ) Trong nội dung bài viết trước tôi đã đưa ra một bài toán nhỏ để so sánh tốc độ query giữa MongoDB và Redshift. Và các bạn đã và đang thấy được tốc độ query rất kinh khủng của Redshift trước MongoDB. Ở nội dung bài viết này mình sẽ giới thiệu với những bạn về cấu trúc của Redshift, cách mà Redshift thực hiện các câu query để hiểu vì sao Redshift lại sở hữu khả năng gớm ghê đến vậy.

Bạn Đang Xem: AWS Redshift

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

Trước hết tất cả chúng ta sẽ đi vào kiến trúc khối hệ thống của Redshift. Sau này là hình vẽ mô tả về kiến trúc của Redshift.

Client Application và Connection

Amazon Redshift được xây dựng dựa trên PostgreSQL với chỉ một tí thay đổi. Do đó nếu ứng dụng của bạn đang sử dụng SQL, chỉ việc vài thay đổi nhỏ thì bạn đã sở hữu thể chuyển sang Redshift. Những điểm khác nhau giữa PostgreSQL và Redshift bạn cũng có thể tìm hiểu ở link sau đây.

Vì được xây dựng dựa trên PostgreSQL nên Redshift tương trợ việc kết nối giữa application và khối hệ thống qua JDBC and ODBC drivers.

Cluster

Hiện tại tất cả chúng ta sẽ đi sâu hơn vào cấu trúc của Redshift. Thành phần core trong kiến trúc của Redshift là Cluster. Trong Cluster sẽ có được một hoặc nhiều Database. Để truy câp vào Cluster các bạn sẽ cần đường link cửa cluster , tên database và password. Mỗi cluster sẽ tiến hành tạo thành bởi 1 hay nhiều Node. Khi Cluster được tạo nên là nhiều Node thì Redshift sinh thêm Leader Node.

Leader Node

Nhiệm vụ trước nhất của Leader Node là kết nối với application để nhận query cũng như trả kết quả. Nhiệm vụ thứ hai là xử lý, truyền query excution plan tới từng Compute Node. Đồi với những câu lệnh query phức tạp thì Leader Node còn truyền xuống các Compute Node các bước query và chính Leader Node tổng hợp kết quả trả về từ Compute Node để sở hữu thể ra được kết quả. Như vậy bước xử lý câu query và tổng hợp kết quả được thực hiện quả Leader Node còn thực hiện nó thì sẽ là ở các Node con.

Compute Node

Compute Node đây là nơi thực hiện các câu lệnh query sau đó trả kết quả lại cho Leader Node tổng hợp lại. Điểm đặc biệt quan trọng ở đây đây là mỗi Compute Node sẽ có được CPU, Memory và Storage cho riêng mình. Cấu hình cụ thể sẽ tùy thuộc vào Plan mà bạn chọn khi tạo Cluster. Ví dụ nếu tài liệu của bạn cực kì kinh khủng thì bạn cũng có thể chọn cho mình max là 36 vCPU, 244Gb Memory và 16TB Storage (hihi). Chúng ta có thể tham khảo link tại đây cho cấu hình từng Cluster và Node:

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

Node Slices

Mỗi một Compute Node tiếp tục được chia ra thành các Node Slice. Mỗi một Node Slice sẽ tiến hành phân chia đều CPU, Memory và Storage từ Compute Node đó. Với một query mà Compute Node nhận được từ Leader Node, Compute Node tiếp tương truyền xuống cho từng Node Slice để các Slice này thực hiện song song query.

Internal network

Xem Thêm : Thuốc Cloxit là thuốc gì? Thuốc Cloxit có tác dụng gì?

Thành phần cuối cùng là Internal network. Redshift sử dụng một khối hệ thống private network với băng thông rộng, tốc độ cao để sở hữu thể kết nối giữa Leader Node và Compute Node. Đây là thành phần đảm bảo truyền query từ Leader Node tới Compute Node và truyền kết quả từ Compute Node tới Leader Node. Đó cũng là một thành phần rất quan trọng ảnh hưởng tác động đến thời kì query mà mình sẽ giới thiệu tới các bạn sau này.

2. Lưu trữ tài liệu

Distribution Style

Tiếp theo mình sẽ nói một tí về việc lưu trữ tài liệu của Redshift. Như ở trên tôi đã nói đến cấu trúc nhỏ nhất trong Redshift là các Node Slices và data của bạn được lưu trữ trên node slices này. Vậy thì Redshift phân bổ data tới các Node Slices ra sao.

Khi chúng ta tạo bảng thì sẽ có được trường bạn nên khai báo là Distribution Key. Distribution Key là một column trong bảng của bạn, và Redshift sẽ sử dụng giá trị của column này để phân chia data đến node slices tương ứng. Hiểu nôm na ví dụ bạn chọn distribution key là cột date. Thì những bản ghi có data là ngày 2016-04-24 sẽ ở trên cùng một node slice, hoặc trên cùng một node nếu như số lượng bản ghi có date là ngày 2016-04-24 quá nhiều… Việc phân chia cũng như lưu trữ xem node nào, nodes slice nào lưu trữ giá trị nào được quyết định và lưu trữ bởi Leader Node.

Ví dụ khi chúng ta query là date BETWEEN 2016-04-24 and 2016-04-25 , leader node thấy với những date là 2016-04-24 và 2016-04-25 thì chỉ được lưu ở node 1 và node 2. Khi đó thì query sẽ chỉ được 2 node này thực hiện. Thông qua đó tránh việc phải xử lý lượng tài liệu không cấp thiết. Do đó việc chọn Distribution Key là cực kì quan trọng khi thiết kế table.

Columnar Data Storage

Columnar Data Storage hiểu đơn giản là lưu trữ tài liệu theo cột. Đây là một trong những yếu tố cực kì quan trọng hỗ trợ cho việc giảm đi một lượng cực kì lớn I/O requirements và lượng tài liệu phải load trong quá trình query.

Cấu trúc lưu data kiểu truyền thống là lưu theo row (row-wise database storage) như bạn thấy tại đây.

Mỗi một block sẽ lưu data của tất cả 1 row. Tức là nếu như row size to ra nhiều thêm block size thì các bạn sẽ cần nhiều hơn 1 block để lưu data, còn nếu như row size nhở hơn block size thì trên 1 block sẽ lưu data của ít nhât 2 row. Kiểu lưu này phù phù hợp với những application là trực tuyến transaction processing (OLTP). Ở những application kiểu này thì việc đọc và ghi liên quan đến toàn bộ tài liệu hoăc chỉ là một lượng nhỏ tài liệu. Do đó việc phải đọc và ghi qua bao nhiêu block không cần thiết phải tối ưu vì bạn hoặc là xử lý trên toàn bộ block, hoặc chỉ việc xử lý trên 1 lượng block nhỏ.

Redshift sử dụng Columnar Data Storage, lưu theo cột để lưu tài liệu như ban thấy tại đây.

Như bạn thấy, thì trên 1 block thay vì lưu cả 1 row thì sẽ lưu theo cột. Tất nhiên trong nội dung bài viết này mình sẽ không còn đi sâu vào so sánh giữa Columnar Storage và Row-Wise Storage (chắc là sẽ có đượ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 là:

• Khả năng query cực kì mạnh mẽ khi phải query lượng tài liệu lớn.
• Khả năng nén tài liệu rất cao, thông qua đó giảm được lượng tài liệu phải xử lý.
• Tốc độc query rất tốt nếu như chỉ liên quan đến một hay một vài cột trong bảng.

Column được lưu trên block theo trật tự nào thì tùy thuộc vào Sort Key mà bạn khai báo khi tạo bảng.

3. Perfomance

Xem Thêm : Data Driven là gì? Doanh nghiệp áp dụng Data Driven ra sao?

Quay trở lại với vấn đề đây là vì sao Redshift có thể có tốc độ query cực kì tốt với lượng tài liệu lớn. Thì có nhẽ qua phần giới thiệu về system của Redshift các bạn cũng luôn có thể đoán ra được phần nào. Sau này là những lý do chính.

Massively parallel processing

Với cấu trúc chia nhở data vào các compute node, các compute node lại được chia nhỏ thành các node slices. Và các node slices lại được cấp CPU, Memory, Storage để xử lý tài liệu song song thì hiển nhiên là tốc độ query sẽ nhanh hơn rất nhiều. Ví dụ như bạn chọn cluster là ds1.xlarge với max node có thể là 32, mỗi node có max là 2 slices, thì với 64 process xử lý query song song hiển nhiên là nhanh hơn so với cùng 1 process. Số lượng 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à max là 32 slices trên 1 node (tất nhiên là nếu tìm con này thì bạn tốn lượng tiền lớn rồi (hihi)).

Columnar data storage

Như đã nói ở trên thì lưu tài liệu theo cột sẽ tốn ít I/O và lượng tài liệu phải load hơn. Columnar data storage cực kì hữu dụng nếu data của bạn cực kì lớn. Đó cũng là một trong những lý do chính giúp Redshift có tốc độ query rất nhanh khi so sánh vs MongoDB ở bài trước của mình.

Data Compression

Với kiểu lưu theo Columnar Data Storage thì Redshift cũng gây tuyệt vời mạnh với khả năng nén tài liệu. Với table có 8.5 triệu bản ghi như của mình, nếu như ở MongoDB lượng tài liệu chiếm là 4.5Gb thì ở Redshift chỉ gần 1Gb, điều đó hỗ trợ cho lượng tài liệu phải xử lý giảm đi rất rất nhiều thông qua đó tăng cao được performance. Redshift cung cấp rất nhiểu kiểu encode cho tài liệu của bạn như raw, byte, delta, lzo… để bạn lựa chọn, thông qua đó nén một cách tối ưu nhất tài liệu của mình.

Query Optimizer

Phân Engine xử lý query của Redshift có khả năng tối ưu hóa query với việc sử dụng (MPP-aware (Massive Parallel Processing))[https://en.wikipedia.org/wiki/Massively_parallel_(computing)] và những lợi thế đã dành từ Columnar data storage. Khi nhận được query thì Engine sẽ chuyển query plan thành code và sau đó chuyển code đó đến Compute Node để thực hiện. Để sở hữu thể làm rõ hơn về query plan cũng như flow thực hiện bạn cũng có thể tham khảo link sau đây:

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

Ngoài ra Redshift còn cung cấp cho bạn 1 loạt các bảng có sắn để bạn cũng có thể phân tích flow của query thông qua đó giúp cho bạn cải thiện câu query. Ví dụ như bảng SVL_QUERY_SUMMARY cung cấp cho bạn thống kê query theo stream, bảng SVL_QUERY_REPORT cung cấp cho bạn thông tin query theo Node Slice, hay STL_ALERT_EVENT_LOG lưu trữ những thông tin mà nó ảnh hưởng tác động đến performance của query… Chúng ta có thể tham khảo về kiểu cách phân tích, cách cải thiện câu query theo như link tại đây:

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

4. Tóm lại

Trong nội dung bài viết này tôi đã giới thiệu cho những bạn về khối hệ thống của Redshift cũng như giảng giải được phần nào lý do vì sao Redshift có hiệu năng cực kì tốt. Tuy nhiên để sở hữu thể sử dụng được một cách tốt nhất toàn bộ hiệu quả của Redshift thì nên sẽ có được những tips riêng, nhất là khi đối chiếu với phần thiết kế bảng.

Trong bài tiếp theo mình sẽ giới thiệu cho những bạn làm thế nào để thiết kế bảng một cách tối ưu trong Redshift. Và đó cũng đây là phương pháp để mình giảm câu query từ 10s xuống còn 4 giây như trong bài trước có nói (hihi).

Xin hứa tái ngộ các bạn ở nội dung bài viết sau (chao).