Tóm tắt học tập về Azure Database for PostgreSQL - nạp tiền bằng thẻ game w88

calendar Feb 26, 2025 · 21 phút đọc · nạp tiền bằng thẻ game w88  ·
Chia sẻ trên: linkedin copy

Ngày 02 tháng 03 năm 2022 - Máy tính

Azure Database for PostgreSQL là dịch vụ cơ sở dữ liệu trên đám mây do Azure cung cấp, dựa trên cơ sở dữ liệu nguồn mở PostgreSQL. Đây là một dịch vụ cơ sở dữ liệu được quản lý hoàn toàn với khả năng hiệu suất có thể đoán trước, bảo mật, khả dụng cao và khả năng mở rộng động để xử lý các công việc quan trọng.

Azure Database for PostgreSQL cung cấp:

  • Khả năng sẵn sàng cao tích hợp;
  • Sao lưu tự động và phục hồi tại thời điểm cụ thể (dữ liệu sao lưu có thể được giữ tối đa 35 ngày);
  • Bảo trì tự động đối với phần cứng cơ bản, hệ điều hành và bộ máy cơ sở dữ liệu để duy trì sự an toàn của dịch vụ và cập nhật phiên bản mới nhất;
  • Hiệu suất có thể dự đoán được với mô hình giá theo mức sử dụng;
  • Khả năng mở rộng đàn hồi trong vài giây;
  • Bảo mật doanh nghiệp và tuân thủ ngành hàng đầu, giúp bảo vệ dữ liệu nhạy cảm tĩnh và động;
  • Các đặc điểm giám sát phong phú và tự động hóa;
  • Trải nghiệm hỗ trợ hàng đầu trong ngành.

Các tính năng này hầu như không yêu cầu quản lý và được cung cấp mà không cần thêm phí, cho phép bạn tập trung vào phát triển ứng dụng và tăng tốc thời gian đưa sản phẩm ra thị trường thay vì dành nhiều thời gian và tài nguyên quý báu để quản lý máy ảo và hạ tầng.

Azure Database for PostgreSQL cung cấp ba chế độ triển khai: Single Server (Máy chủ đơn), Flexible Server (Máy chủ linh hoạt) và Hyperscale (Citus) Cluster (Nhóm phân tán). Dưới đây sẽ lần lượt giới thiệu từng loại.

1. Máy chủ đơn (Single Server)

Azure Database for PostgreSQL Single Server là điểm quản lý trung tâm cho nhiều cơ sở dữ liệu. Nó giống với cấu trúc khi bạn thiết lập một máy chủ PostgreSQL trong môi trường On-Premise.

Triển khai máy chủ đơn của Azure Database for PostgreSQL:

  • Được tạo trong một đăng ký Azure;
  • Là tài nguyên cha của cơ sở dữ liệu;
  • Cung cấp không gian tên cho cơ sở dữ liệu;
  • Là một container có ngữ nghĩa vòng đời mạnh mẽ (xóa máy chủ sẽ xóa các cơ sở dữ liệu chứa bên trong);
  • Được cấu hình tài nguyên trong một vùng;
  • Cung cấp điểm kết nối cho truy cập vào máy chủ và cơ sở dữ liệu;
  • Cung cấp phạm vi chính sách quản lý cho cơ sở dữ liệu của mình: đăng nhập, tường lửa, người dùng, vai trò, cấu hình, v.v.;
  • Hỗ trợ nhiều phiên bản PostgreSQL (bao gồm những phiên bản nào?);
  • Hỗ trợ các phần mở rộng PostgreSQL (hỗ trợ phần mở rộng nào?).

Bạn có thể tạo một hoặc nhiều cơ sở dữ liệu trong máy chủ đơn để cung cấp tài nguyên độc quyền hoặc chia sẻ cho một hoặc nhiều ứng dụng. Giá thành sẽ được tính dựa trên cấu hình lớp định giá, vCore và dung lượng lưu trữ (GB).

Cách kết nối

  • Xác thực: Azure Database for PostgreSQL Single Server hỗ trợ xác thực PostgreSQL gốc. Bạn có thể kết nối bằng tài khoản quản trị viên.

  • Giao thức: Dịch vụ hỗ trợ giao thức dựa trên tin nhắn mà PostgreSQL sử dụng.

  • TCP/IP: Giao thức trên được hỗ trợ bởi TCP/IP và Unix domain sockets.

  • Tường lửa: Để bảo vệ dữ liệu, Azure mặc định đóng tất cả các quyền truy cập. Sau khi bạn thiết lập quy tắc tường lửa (danh sách trắng IP) ở phía máy chủ, bạn có thể mở quyền truy cập cho các địa chỉ IP cụ thể. Tường lửa xác định quyền truy cập dựa trên địa chỉ IP gốc của mỗi yêu cầu. Bạn cần thiết lập quy tắc tường lửa (khoảng địa chỉ IP được phép) thông qua cổng Azure hoặc CLI Azure, và tất cả các cơ sở dữ liệu dưới cùng một máy chủ logic đều tuân theo các quy tắc này. Hãy sử dụng chủ sở hữu hoặc người đóng góp của đăng ký để tạo quy tắc tường lửa.

Bạn cũng có thể chọn bật chế độ TLS để tăng cường bảo mật. Sau đó tải xuống chứng chỉ và sử dụng psql để kết nạp tiền bằng thẻ game w88 nối:

1$ wget --no-check-certificate 

1$ psql --host=mydemoserver-pg.postgres.database.azure.com --port=5432 --username=myadmin --dbname=postgres --set=sslmode=require --set=sslrootcert=DigiCertGlobalRootCA.crt.pem
2# psql "host=mydemoserver-pg.postgres.database.azure.com port=5432 user=myadmin dbname=postgres sslmode=verify-full sslrootcert=DigiCertGlobalRootCA.crt.pem"

Quản lý máy chủ Bạn có thể quản lý Azure Database for PostgreSQL Single Server thông qua cổng Azure hoặc CLI Azure. Khi tạo máy chủ, bạn đặt mật khẩu cho người dùng quản trị. Người dùng quản trị là người dùng có quyền cao nhất trên máy chủ của bạn. Họ thuộc nhóm azure_pg_admin. Nhóm này không có quyền siêu người dùng đầy đủ.

Siêu người dùng PostgreSQL được phân bổ cho azure_superuser, thuộc về dịch vụ được quản lý. Bạn không có quyền truy cập vào vai trò này.

Dưới đây là một số cơ sở dữ liệu mặc định trên máy chủ:

  • postgres: Cơ sở dữ liệu mặc định có thể kết nối sau khi tạo máy chủ;
  • azure_maintenance: Cơ sở dữ liệu này được sử dụng để tách biệt quá trình cung cấp dịch vụ được quản lý khỏi các thao tác của người dùng, bạn không có quyền truy cập vào cơ sở dữ liệu này;
  • azure_sys: Cơ sở dữ liệu này được sử dụng cho Query Store. Nếu Query Store bị tắt, nó sẽ không tích lũy dữ liệu. Mặc định, Query Store bị tắt.

Tham số máy chủ Tham số máy chủ quyết định cấu hình của máy chủ. Trong Azure Database for PostgreSQL, bạn có thể xem và chỉnh sửa danh sách tham số thông qua cổng Azure hoặc CLI Azure. Là một dịch vụ được quản lý, các tham số có thể cấu hình của Azure Database for PostgreSQL là tập con của các tham số có thể cấu hình của phiên bản PostgreSQL tự xây dựng (chi tiết về các tham số PostgreSQL, tham khảo [PostgreSQL Runtime Configuration]).

Khi tạo máy chủ Azure Database for PostgreSQL, mỗi tham số được sử dụng với giá trị mặc định. Người dùng không thể cấu hình một số tham số cần khởi động lại hoặc chỉ có quyền siêu người dùng mới có thể thay đổi.

2. Máy chủ linh hoạt (Flexible Server)

Azure Database for PostgreSQL Flexible Server là một dịch vụ cơ sở dữ liệu được quản lý hoàn toàn, nhằm cung cấp kiểm soát và tùy chỉnh chi tiết hơn đối với các chức năng quản lý cơ sở dữ liệu và cài đặt cấu hình. Dịch vụ này cung cấp nhiều khả năng linh hoạt hơn và tùy chỉnh cấu hình máy chủ dựa trên nhu cầu của người dùng. Kiến trúc máy chủ linh hoạt cho phép người dùng đặt cả cơ sở dữ liệu và dịch vụ khách hàng ở cùng một vị trí để giảm độ trễ, lựa chọn khả năng sẵn sàng cao trong một vùng hoặc giữa nhiều vùng. Máy chủ linh hoạt còn cung cấp kiểm soát tốt hơn về tối ưu hóa chi phí, cho phép bạn bật/tắt máy chủ và sử dụng lớp tính toán đột biến, rất phù hợp cho các khối lượng công việc không cần năng lực tính toán đầy đủ liên tục. Hiện tại, dịch vụ hỗ trợ phiên bản cộng đồng PostgreSQL 11, 12 và 13. Dịch vụ hiện đã có sẵn ở hầu hết các khu vực của Azure.

Máy chủ linh hoạt rất phù hợp cho các trường hợp sau:

  • Phát triển ứng dụng cần kiểm soát và tùy chỉnh tốt hơn;
  • Sẵn sàng cao dự phòng vùng;
  • Thời gian bảo trì được quản lý.

Khả năng sẵn sàng cao Kiến trúc triển khai máy chủ linh hoạt được thiết kế để hỗ trợ khả năng sẵn sàng cao trong một vùng hoặc giữa nhiều vùng. Kiến trúc này tách biệt tính toán và lưu trữ. Cơ sở dữ liệu chạy trong các container trên máy ảo Linux, trong khi các tệp dữ liệu được lưu trữ trên Azure Storage. Lưu trữ duy trì ba bản sao đồng bộ cục bộ của các tệp dữ liệu để đảm bảo tính bền vững của dữ liệu.

Trong các sự kiện chuyển mạch dự kiến hoặc không dự kiến, nếu máy chủ gặp sự cố, dịch vụ sẽ sử dụng các chương trình tự động hóa sau để duy trì khả năng sẵn sàng cao của máy chủ:

  • Phân bổ một máy ảo Linux tính toán mới;
  • Lưu trữ chứa các tệp dữ liệu được ánh xạ đến máy ảo mới;
  • Cơ sở dữ liệu PostgreSQL được khởi chạy trên máy ảo mới.

Nếu bạn cấu hình sẵn sàng cao dự phòng vùng, dịch vụ sẽ cung cấp và duy trì một máy chủ dự phòng nóng trong vùng dự phòng của cùng một khu vực Azure. Các thay đổi dữ liệu trên máy chủ nguồn được sao chép đồng bộ đến máy chủ dự phòng, đảm bảo không mất dữ liệu. Với sẵn sàng cao dự phòng vùng, khi xảy ra sự kiện chuyển mạch dự kiến hoặc không dự kiến, máy chủ dự phòng sẽ ngay lập tức xử lý các yêu cầu giao dịch. Điều này cho phép dịch vụ khôi phục từ các sự cố trong cùng một khu vực có nhiều vùng khả dụng.

Bảo trì tự động với cửa sổ bảo trì được quản lý Dịch vụ này tự động vá phần cứng cơ bản, hệ điều hành và bộ máy cơ sở dữ liệu. Bao gồm cả vá bảo mật và cập nhật phần mềm. Đối với bộ máy PostgreSQL, nâng cấp phiên bản phụ cũng nằm trong các phiên bản bảo trì đã lên kế hoạch. Người dùng có thể cấu hình lịch trình vá thành hệ thống quản lý hoặc tùy chỉnh thời gian bảo trì. Trong giai đoạn bảo trì, các bản vá sẽ được áp dụng và có thể cần khởi động lại máy chủ để hoàn thành cập nhật. Qua việc tùy chỉnh thời gian bảo trì, người dùng có thể làm cho chu kỳ vá của họ trở nên có thể dự đoán được và chọn khung thời gian bảo trì ít ảnh hưởng nhất đến hoạt động kinh doanh. Thông thường, như một phần của tích hợp và phát hành liên tục, dịch vụ này phát hành mỗi tháng một lần.

Sao lưu tự động Máy chủ linh hoạt sẽ tự động sao lưu dữ liệu và lưu chúng trên Lưu trữ Bền vững theo vùng (ZRS) trong cùng một khu vực. Sao lưu có thể được sử dụng để khôi phục máy chủ của bạn về bất kỳ thời điểm nào trong khoảng thời gian giữ sao lưu. Thời gian giữ sao lưu mặc định là 7 ngày, có thể cấu hình tối đa 35 ngày. Tất cả các bản sao lưu đều được mã hóa bằng thuật toán AES 256.

Mở rộng quy mô trong vài giây Máy chủ linh hoạt có ba lớp tính toán để lựa chọn: Đột biến, Tiêu chuẩn và Tối ưu hóa bộ nhớ. Lớp Đột biến phù hợp nhất cho các khối lượng công việc phát triển chi phí thấp và ít cần năng lực tính toán liên tục. Lớp Tiêu chuẩn và Tối ưu hóa bộ nhớ phù hợp hơn cho các khối lượng công việc sản xuất cần đồng thời, quy mô lớn và hiệu suất có thể dự đoán được. Bạn có thể bắt đầu xây dựng ứng dụng đầu tiên của mình trên một cơ sở dữ liệu nhỏ với vài đô la mỗi tháng, sau đó điều chỉnh quy mô liền mạch để đáp ứng nhu cầu giải pháp của bạn.

Bật/tắt máy chủ để giảm TCO Máy chủ linh hoạt cho phép bạn dừng và khởi động lại máy chủ theo nhu cầu để giảm tổng chi phí sở hữu (TCO). Khi máy chủ bị dừng, chi phí tính toán sẽ ngừng ngay lập tức. Điều này cho phép bạn tiết kiệm đáng kể chi phí trong giai đoạn phát triển, thử nghiệm và khối lượng công việc sản xuất có thể dự đoán trong một khoảng thời gian hạn định. Nếu không được khởi động lại trước thời hạn, máy chủ sẽ tiếp tục trạng thái dừng trong 7 ngày.

Bảo mật doanh nghiệp Máy chủ linh hoạt sử dụng mô-đun mã hóa đã được xác minh theo tiêu chuẩn FIPS 140-2 để mã hóa dữ liệu đang lưu trữ. Tất cả dữ liệu được tạo khi chạy truy vấn (bao gồm cả bản sao lưu và tệp tạm thời) đều được mã hóa. Dịch vụ này sử dụng khóa AES 256 được bao gồm trong mã hóa Lưu trữ Azure, và khóa có thể được quản lý bởi hệ thống (mặc định). Dịch vụ này sử dụng mã hóa bảo mật truyền layer (SSL/TLS) được tăng cường theo mặc định. Dịch vụ này chỉ tăng cường và hỗ trợ phiên bản TLS 1.2.

Cho phép truy cập riêng tư hoàn toàn vào máy chủ thông qua tích hợp Mạng ảo Azure (VNet). Máy chủ trong Mạng ảo Azure chỉ có thể được truy cập và kết nối thông qua địa chỉ IP riêng. Qua tích hợp VNet, truy cập công cộng bị từ chối và không thể sử dụng điểm cuối công cộng để truy cập vào máy chủ.

Giám sát và cảnh báo Máy chủ linh hoạt đi kèm với chức năng giám sát và cảnh báo hiệu suất tích hợp. Tất cả các chỉ số Azure được thu thập mỗi phút một lần và cung cấp lịch sử 30 ngày cho mỗi chỉ số. Bạn có thể cấu hình cảnh báo trên các chỉ số. Các chỉ số máy chủ chính được cung cấp quyền truy cập để giám sát việc sử dụng tài nguyên và cho phép cấu hình nhật ký truy vấn chậm. Sử dụng các công cụ này, bạn có thể tối ưu hóa khối lượng công việc của mình nhanh chóng và tối ưu hóa cấu hình để đạt hiệu suất tốt nhất.

PgBouncer tích hợp sẵn Máy chủ linh hoạt đi kèm với PgBouncer tích hợp sẵn (một pool kết nối). Bạn có thể chọn bật nó và kết nối ứng dụng của mình đến máy chủ cơ sở dữ liệu qua cùng tên miền và cổng 6432.

Di chuyển dữ liệu Dịch vụ này chạy phiên bản cộng đồng PostgreSQL. Điều này cho phép tương thích ứng dụng hoàn toàn và chi phí tái cấu trúc tối thiểu khi di chuyển các ứng dụng hiện có được phát triển trên cơ sở dữ liệu PostgreSQL sang Azure Flexible Server.

  • Chuyển đổ và khôi phục: Để di chuyển ngoại tuyến, người dùng có thể chịu một chút thời gian ngừng hoạt động, sử dụng các công cụ cộng đồng như pg_dump và pg_restore để chuyển đổ và khôi phục.
  • Dịch vụ Di chuyển Cơ sở Dữ liệu Azure: Để di chuyển liền mạch với thời gian ngừng hoạt động ngắn nhất, bạn có thể sử dụng Dịch vụ Di chuyển Cơ sở Dữ liệu Azure.

3. Nhóm phân tán (Hyperscale) Citus

Nhóm phân tán (Hyperscale) Citus là tùy chọn triển khai sử dụng phân đoạn để mở rộng truy vấn trên nhiều máy, với truy vấn song song trên các máy để phản hồi nhanh hơn cho các tập dữ liệu lớn. Nó vượt trội hơn hai tùy chọn triển khai trước đó về quy mô và hiệu suất, với khối lượng công việc thường gần hoặc vượt quá 100 GB.

Nhóm phân tán cung cấp các khả năng sau:

  • Mở rộng ngang trên nhiều máy sử dụng phân đoạn;
  • Thực hiện truy vấn song song trên nhiều máy để phản hồi nhanh hơn cho các tập dữ liệu lớn;
  • Hỗ trợ tuyệt vời cho các ứng dụng đa người thuê, phân tích hoạt động thời gian thực và khối lượng công việc giao dịch có băng thông cao.

Các ứng dụng được xây dựng trên PostgreSQL có thể chạy các truy vấn phân tán trên nhóm phân tán (Hyperscale) Citus với thư viện kết nối tiêu chuẩn và thay đổi tối thiểu.

Phân công node Loại nhóm phân tán (Hyperscale) Citus cho phép các máy chủ Azure Database for PostgreSQL (gọi là nodes) phối hợp với nhau trong kiến trúc “không chia sẻ”. So với một máy chủ đơn lẻ, các node trong nhóm máy chủ cùng sở hữu nhiều dữ liệu hơn và sử dụng nhiều lõi CPU hơn. Kiến trúc này còn cho phép mở rộng cơ sở dữ liệu bằng cách thêm nhiều node hơn vào nhóm máy chủ.

Mỗi nhóm máy chủ có một node điều phối và nhiều node làm việc. Các ứng dụng gửi truy vấn của chúng đến node điều phối (ứng dụng không thể kết nối trực tiếp với các node làm việc), node điều phối chuyển tiếp chúng đến các node làm việc liên quan và tổng hợp kết quả của chúng.

Node điều phối cho phép DBA xác định quy tắc phân đoạn bảng để lưu trữ các dòng khác nhau trên các node làm việc khác nhau. Bảng phân đoạn là chìa khóa cho hiệu suất mạnh mẽ của nhóm phân tán (Hyperscale) Citus. Các bảng không được phân đoạn sẽ lưu trữ dữ liệu hoàn toàn trên node điều phối, như vậy sẽ không tận dụng được lợi thế song song của nhiều máy.

Đối với mỗi truy vấn trên bảng phân đoạn, node điều phối quyết định sẽ định tuyến nó đến một node làm việc duy nhất hoặc định tuyến song song nó đến nhiều node làm việc dựa trên phân bố dữ liệu cần thiết. Node điều phối sử dụng bảng siêu dữ liệu để quyết định cách thực hiện, các bảng này theo dõi tên DNS và trạng thái hoạt động của các node làm việc, cũng như phân bố dữ liệu trên các node.

Phân đoạn Tiếp tục phần kỹ thuật phân đoạn, hãy thảo luận chi tiết về phân đoạn.

Bảng siêu dữ liệu pg_dist_shard trên node điều phối ghi lại thông tin về từng phân đoạn của mỗi bảng phân tán trong hệ thống. Thông tin này là sự khớp giữa ID phân đoạn và phạm vi số nguyên trong không gian băm (shardminvalue, shardmaxvalue).

1SELECT * FROM pg_dist_shard;
2 logicalrelid | shardid | shardstorage | shardminvalue | shardmaxvalue
3---------------+---------+--------------+---------------+---------------
4 github_events | 102026 | t      | 268435456   | 402653183
5 github_events | 102027 | t      | 402653184   | 536870911
6 github_events | 102028 | t      | 536870912   | 671088639
7 github_events | 102029 | t      | 671088640   | 805306367
8(4 rows)

Nếu node điều phối muốn xác định phân đoạn nào lưu trữ dòng của bảng github_events, nó sẽ băm giá trị của cột phân phối trong dòng đó. Sau đó nó kiểm tra phạm vi nào của phân đoạn chứa giá trị băm đó. Phạm vi được định nghĩa sao cho hình ảnh của hàm băm là hợp nhất không trùng lặp của chúng.

Giả sử phân đoạn 102027 liên quan đến dòng mà chúng ta muốn yêu cầu. Dòng này được đọc hoặc ghi vào bảng github_events_102027 trên một trong các node làm việc. Node làm việc nào? Điều này hoàn toàn do bảng siêu dữ liệu quyết định. Việc ánh xạ phân đoạn đến node làm việc được gọi là phân đoạn đặt chỗ.

Node điều phối viết lại truy vấn thành các phần tham chiếu đến bảng cụ thể (như github_events_102027) và chạy các phần này trên các node làm việc thích hợp. Dưới đây là một ví dụ về việc chạy truy vấn ở hậu trường để tìm node nắm giữ ID phân đoạn 102027:

1SELECT shardid, node.nodename, node.nodeport 
2FROM pg_dist_placement placement 
3JOIN pg_dist_node node 
4ON placement.groupid = node.groupid 
5AND node.noderole = 'primary'::noderole 
6WHERE shardid = 102027;

1┌─────────┬───────────┬──────────┐
2│ shardid │ nodename │ nodeport │
3├─────────┼───────────┼──────────┤
4│ 102027 │ localhost │   5433 │
5└─────────┴───────────┴──────────┘

Colocation bảng Colocation bảng có nghĩa là lưu trữ thông tin liên quan trên cùng một node. Điều này giúp lấy dữ liệu mong muốn từ một node trong một bước, tiết kiệm chi phí mạng và truy vấn có thể nhanh hơn. Việc đặt dữ liệu liên quan trên các node khác nhau cho phép truy vấn chạy hiệu quả song song trên mỗi node.

Nếu giá trị của cột phân phối của một dòng băm rơi vào phạm vi băm của một phân đoạn, dòng đó sẽ được lưu trữ trong phân đoạn đó. Các phân đoạn có cùng phạm vi băm luôn được đặt trên cùng một node. Các dòng có giá trị cột phân phối bằng nhau luôn nằm trên các bảng phân đoạn khác nhau trên cùng một node.

Xem xét ví dụ sau có thể là hệ thống phân tích web đa người thuê trong kịch bản SaaS:

1CREATE TABLE event(tenant_id int, event_id bigint, page_id int, payload jsonb, PRIMARY KEY(tenant_id, event_id));
2CREATE TABLE page(tenant_id int, page_id int, path text, PRIMARY KEY(tenant_id, page_id));

Xem xét một truy vấn có thể được khởi chạy từ Dashboard trang web của hệ thống này: "Trả về số lần truy cập trong tuần trước của tất cả các trang bắt đầu bằng '/blog' của người thuê 6".

Nếu dữ liệu của chúng ta tồn tại trên một máy chủ đơn lẻ, chúng ta có thể dễ dàng thực hiện truy vấn sau bằng SQL:

 1SELECT page_id, count(event_id) 
 2FROM page 
 3LEFT JOIN (
 4    SELECT * 
 5    FROM event 
 6    WHERE (payload->>'time')::timestamptz >= now() - interval '1 week'
 7) recent 
 8USING (tenant_id, page_id) 
 9WHERE tenant_id = 6 AND path LIKE '/blog%' 
10GROUP BY page_id;

Khi sử dụng nhóm phân tán (Hyperscale) Citus, chúng ta cần thực hiện một số thay đổi, chủ yếu có hai cách phân đoạn có thể.

  • Phân đoạn theo ID Khi số lượng người thuê tăng lên và dữ liệu của mỗi người thuê tăng, truy vấn trên máy chủ đơn bắt đầu chậm hơn, bộ nhớ và CPU trở thành cổng nghẽn.

Trong trường hợp này, nhóm phân tán (Hyperscale) Citus phát huy tác dụng. Khi chúng ta quyết định phân đoạn, điều quan trọng nhất là xác định cột phân phối. Giờ đây, hãy thử sử dụng event_id và page_id lần lượt làm cột phân phối cho bảng event và page.

1-- naively use event_id and page_id as distribution columns
2SELECT create_distributed_table('event', 'event_id');
3SELECT create_distributed_table('page', 'page_id');

Khi dữ liệu được phân tán trên các node làm việc khác nhau, chúng ta không thể thực hiện thao tác join như trên một node PostgreSQL đơn lẻ. Chúng ta cần thực hiện hai truy vấn:

 1-- (Q1) get the relevant page_ids
 2SELECT page_id 
 3FROM page 
 4WHERE path LIKE '/blog%' AND tenant_id = 6;
 5
 6-- (Q2) get the counts
 7SELECT page_id, count(*) AS [m88vin - cổng game quốc tế](/post/power-apps.html)  count 
 8FROM event 
 9WHERE page_id IN (/*…page IDs from first query…*/) 
10AND tenant_id = 6 
11AND (payload->>'time')::date >= now() - interval '1 week' 
12GROUP BY page_id 
13ORDER BY count DESC LIMIT 10;

Chạy hai truy vấn này sẽ truy vấn dữ liệu từ các phân đoạn phân tán trên các node khác nhau.

Sau đó, ứng dụng cần tích hợp kết quả của hai bước này.

Trong trường hợp này, việc phân phối dữ liệu tạo ra nhiều khuyết điểm:

  • Chi phí truy vấn mỗi phân đoạn và chạy nhiều truy vấn;
  • Chi phí Q1 trả về nhiều hàng cho client;
  • Q2 trở nên lớn;
  • Cần thay đổi ứng dụng để phân tách thành nhiều truy vấn.

Dữ liệu được phân tán, vì vậy có thể song song hóa truy vấn. Chỉ có lợi ích khi khối lượng công việc của truy vấn lớn hơn nhiều so với chi phí truy vấn nhiều phân đoạn.

  • Phân đoạn theo người thuê Trong nhóm phân tán (Hyperscale) Citus, các dòng có cùng giá trị cột phân phối được đảm bảo nằm trên cùng một node. Do đó, chọn tenant_id làm cột phân phối là phù hợp nhất.
1-- colocate tables by using a common distribution column
2SELECT create_distributed_table('event', 'tenant_id');
3SELECT create_distributed_table('page', 'tenant_id', colocate_with => 'event');

Như vậy, truy vấn ban đầu có thể chạy mà không cần thay đổi:

 1SELECT page_id, count(event_id) 
 2FROM page 
 3LEFT JOIN (
 4    SELECT * 
 5    FROM event 
 6    WHERE (payload->>'time')::timestamptz >= now() - interval '1 week'
 7) recent 
 8USING (tenant_id, page_id) 
 9WHERE tenant_id = 6 AND path LIKE '/blog%' 
10GROUP BY page_id;

Do lọc và join theo tenant_id, nhóm phân tán (Hyperscale) Citus biết rằng toàn bộ truy vấn có thể được xử lý bằng cách sử dụng tập phân đoạn đồng vị chứa dữ liệu của người thuê cụ thể này. Một node PostgreSQL đơn lẻ có thể xử lý truy vấn trong một bước.

Trong một số trường hợp, cần phải sửa đổi truy vấn và mô hình bảng để bao gồm ID người thuê trong ràng buộc duy nhất và điều kiện join. Những sửa đổi này tương đối đơn giản.

Với đó, chúng ta đã hoàn thành sự hiểu biết sơ lược về ba loại dịch vụ PostgreSQL mà Azure cung cấp.

Tài liệu tham khảo: [1] Azure Database for PostgreSQL Documentation