Tìm hiểu Property Graph trong Postgres 19

• Property Graph trong Postgres 19 là tính năng SQL/PGQ cho phép khai báo các bảng hiện có thành đỉnh và cạnh, rồi dùng MATCH để tìm kiếm các mẫu quan hệ cố định; không sao chép dữ liệu hay tạo engine thực thi đồ thị riêng
• Các mẫu đồ thị được biên dịch thành join quan hệ, tận dụng nguyên trạng optimizer, index và thống kê hiện có, nên cả các lượt duyệt chậm cũng có thể được phân tích và tối ưu theo cách giống như join thông thường
• Bảng chiều tương ứng tự nhiên với đỉnh, bảng join thuần túy tương ứng với cạnh, nhưng bảng fact có nhiều khóa ngoại và thuộc tính riêng thì phù hợp hơn khi mô hình hóa thành đỉnh hub biểu diễn sự kiện
• Có thể khai báo cùng một bảng đồng thời làm đỉnh và nhiều cạnh với các alias khác nhau, nên không cần tạo và lưu các bảng cạnh riêng dựa trên khóa ngoại hiện có của results
• Postgres 19 không hỗ trợ đường đi có độ dài biến đổi, nên không phù hợp cho shortest path, khả năng tới được trong N hop, hay PageRank; phù hợp với tìm kiếm độ dài cố định khi đã biết trước cấu trúc quan hệ

---

Cách đọc schema quan hệ như một đồ thị

• Trong một schema quan hệ đã chuẩn hóa, các bảng chiều như drivers, constructors, circuits chứa thực thể, còn bảng fact ghi nhận các sự kiện như kết quả cuộc đua hoặc phiên phân hạng
• Mỗi hàng là một đỉnh tiềm năng, còn khóa ngoại là một cạnh tiềm năng trỏ tới hàng khác
  • Sơ đồ ER tương ứng với đồ thị ở cấp schema
  • Các hàng thực tế và quan hệ khóa ngoại tương ứng với đồ thị ở cấp instance
• Yêu cầu “tìm constructor tương ứng với từng kết quả” là một phép duyệt đồ thị được viết trong SQL quan hệ dưới dạng results JOIN constructors ON ...
• SQL/PGQ không thêm một đồ thị mới, mà cho phép viết câu hỏi dưới dạng đồ thị thay vì liệt kê trực tiếp các join
• Cách tiếp cận RelBench đưa bảng vào pandas rồi dựng đồ thị PyTorch trong bộ nhớ, còn Postgres Property Graph dùng nguyên các quan hệ bảng hiện có bên trong database
• Các ví dụ của PyG cũng chủ yếu dùng file phẳng hoặc đồ thị trong bộ nhớ
• Có thể xem mã thử nghiệm với bộ dữ liệu Formula 1 trong kho GitHub

Cấu trúc của Property Graph

• CREATE PROPERTY GRAPH là đối tượng khai báo có tên được tạo trên các bảng hiện có
  • VERTEX TABLES chỉ định các bảng sẽ được đọc như đỉnh theo từng hàng
  • EDGE TABLES chỉ định các bảng sẽ được đọc như quan hệ liên kết
• Mỗi bảng đỉnh định nghĩa các yếu tố sau
  • KEY: định danh của đỉnh, đa số dùng khóa chính
  • LABEL: tên loại đỉnh sẽ dùng trong MATCH
  • PROPERTIES: danh sách cột có thể truy cập trong truy vấn đồ thị
• Mỗi bảng cạnh chỉ định SOURCE và DESTINATION; hai giá trị này lần lượt tham chiếu tới khóa của đỉnh
• CREATE PROPERTY GRAPH không di chuyển hay sao chép dữ liệu
  • Các hàng vẫn nằm nguyên trong bảng gốc
  • Phần khai báo chỉ định nghĩa cách đọc cấu trúc khóa ngoại hiện có như một đồ thị
• Thành phần cấu trúc của Property Graph chỉ có hai loại: đỉnh và cạnh
  • Label và property là thuộc tính thuộc về đỉnh hoặc cạnh
  • Trong psql, Element Kind của mỗi thành phần là một trong hai giá trị vertex hoặc edge

Truy vấn mẫu cố định bằng MATCH

• Truy vấn đồ thị được viết bằng cách đặt mẫu MATCH bên trong GRAPH_TABLE(...)
• Mẫu sau biểu diễn quan hệ đi từ driver qua result tới race

MATCH (d IS driver)<-[IS of_driver]-(res IS result)-[IS in_race]->(ra IS race)  

• Mệnh đề COLUMNS chỉ định các cột mà truy vấn đồ thị trả ra bên ngoài
• Trong SELECT bên ngoài, có thể truy vấn kết quả của GRAPH_TABLE(...) như một bảng thông thường
• Vì mẫu có hướng và label, quan hệ có thể được đọc như một câu, nên dễ nắm bắt cấu trúc hơn so với một truy vấn nhiều join tương đương

Cấu trúc được chuyển thành join quan hệ khi thực thi

• MATCH không phải là engine thực thi đồ thị được gắn thêm riêng cho Postgres, mà là cú pháp được biên dịch thành join quan hệ
• Khi chạy EXPLAIN trên mẫu driver–result–race, ta thấy 4 phép hash join trên các bảng nền
• Giống như join viết trực tiếp, nó sử dụng các yếu tố sau
  • Optimizer hiện có của Postgres
  • Index hiện có
  • Thống kê hiện có
• Nếu duyệt đồ thị chậm, nguyên nhân và cách tối ưu cũng giống như khi join thông thường bị chậm
• Ngay trong psql cũng có thể khảo sát đồ thị bằng các lệnh tương tự bảng
  • \dG: hiển thị danh sách Property Graph
  • \d f1: hiển thị từng đỉnh và cạnh, bảng nền, loại thành phần, cùng đỉnh xuất phát và đỉnh đích của cạnh
  • \d+ f1: tái dựng toàn bộ câu lệnh CREATE PROPERTY GRAPH, bao gồm cả khóa cạnh được suy luận từ khóa chính của bảng cạnh

Khác biệt giữa key và property

• Cột được chỉ định làm KEY của đỉnh không tự động trở thành property
• Nếu chỉ chỉ định driver_id làm khóa đỉnh rồi lọc bằng d.driver_id = 1, truy vấn sẽ thất bại vì cột đó không phải là property có thể truy vấn
• Key định danh đỉnh nhưng không phơi bày ra truy vấn
• Nếu muốn lọc hoặc trả về cột ID, phải thêm tường minh vào danh sách PROPERTIES

Hạn chế về đường đi có độ dài biến đổi trong Postgres 19

• Postgres 19 không hỗ trợ bộ định lượng mẫu thành phần kiểu đi theo cạnh 1–3 lần

ERROR: element pattern quantifier is not supported  

• Muốn duyệt hai hop thì phải viết rõ hai mẫu cạnh trong MATCH
• Không thể biểu diễn đường đi có độ dài tùy ý bằng cú pháp Property Graph
• Tìm kiếm với độ sâu mở phải được xử lý bằng CTE đệ quy trên các bảng nền; khi đó sẽ nằm ngoài cú pháp Property Graph

Ánh xạ bảng hiện có thành đỉnh và cạnh

• Bảng chiều là đỉnh

  • Các bảng thực thể có khóa chính và thuộc tính ổn định như drivers, constructors, circuits tương ứng trực tiếp với đỉnh
  • Chỉ cần dùng khóa chính làm key của đỉnh và phơi bày các cột cần thiết làm property

• Bảng join thuần túy là cạnh

  • Các bảng bridge nhiều-nhiều như student_courses(student_id, course_id) vốn có vai trò kết nối hai thực thể, nên tương ứng tự nhiên với cạnh
  • Khai báo một khóa ngoại làm đỉnh xuất phát, khóa ngoại còn lại làm đỉnh đích
  • Mỗi hàng của bảng join tự nó là một quan hệ, nên không cần chuyển đổi dữ liệu riêng cho đồ thị
  • Trong cấu trúc này, students và courses là đỉnh, còn student_courses là cạnh enrolled_in

• Bảng fact là đỉnh sự kiện

  • Một hàng results trỏ tới ba thực thể driver, race, constructor, đồng thời có dữ liệu riêng như grid, position, points, status
  • Cạnh SQL/PGQ là quan hệ nhị phân có một điểm xuất phát và một điểm đích, nên không thể biến toàn bộ hàng có ba khóa ngoại thành một cạnh duy nhất
  • Nếu bản thân hàng fact là đối tượng phân tích, phù hợp hơn là khai báo bảng đó làm đỉnh
  • Đỉnh results giữ sự kiện và các thuộc tính của sự kiện
  • Các cạnh hẹp như results_driver, results_race, results_constructor kết nối nó với các thực thể bên ngoài
  • Mô hình này tạo ra cấu trúc hub như driver <- result -> race, cho phép dừng ở đỉnh result để lọc hoặc truy xuất thuộc tính
  • Nếu quan hệ là đối tượng quan tâm, hãy mô hình hóa thành cạnh; nếu một hàng hay sự kiện cụ thể có thuộc tính riêng là đối tượng quan tâm, hãy mô hình hóa thành đỉnh
  • Bảng join biểu diễn quan hệ, còn bảng fact biểu diễn sự kiện

Dùng cùng một bảng đồng thời làm đỉnh và cạnh

• Phân biệt “đỉnh hoặc cạnh” áp dụng cho từng khai báo thành phần trong đồ thị, không áp dụng cho bảng nền
• Có thể khai báo cùng một bảng ở cả VERTEX TABLES và EDGE TABLES với các alias khác nhau
• Khi dùng results làm đỉnh result, có thể tái sử dụng cùng bảng này với các alias cạnh sau
  • results AS res_driver: nối từ result tới driver
  • results AS res_race: nối từ result tới race
  • results AS res_constr: nối từ result tới constructor
• Mỗi alias cạnh dùng các cột khóa chính và khóa ngoại đã tồn tại trong results
• Không cần tạo các bảng riêng results_driver, results_race, results_constructor, và alias không lưu dữ liệu
• Một bảng fact có ba khóa ngoại không nên được khai báo là một cạnh đa đầu mút, mà phải khai báo thành ba alias cạnh, mỗi alias có một điểm xuất phát và một điểm đích
• Cách này dùng ba alias khai báo trên cùng một bảng nền thay vì ba bảng vật lý hoặc view

Xung đột tên và kiểu property

• Nếu bỏ qua PROPERTIES, SQL/PGQ sẽ phơi bày tất cả cột của bảng làm property
• Nếu cả results và qualifying đều có cột number nhưng lần lượt là double precision và bigint, lỗi sau sẽ xảy ra

ERROR: property "number" data type mismatch: double precision vs. bigint  

• Trên toàn bộ đồ thị, property cùng tên phải có một kiểu duy nhất, nên các cột cùng tên nhưng khác kiểu sẽ xung đột
• Nếu chỉ ghi rõ các cột cần thiết trong PROPERTIES, có thể loại cột gây xung đột khỏi đồ thị
• Cả vấn đề key không tự động trở thành property lẫn xung đột kiểu đều có thể giải quyết bằng danh sách cho phép property tường minh

Truy vấn phù hợp và không phù hợp

• Mẫu quan hệ cố định

  • Property Graph phù hợp với câu hỏi “hãy tìm các đối tượng được kết nối với X theo mẫu cụ thể này”
  • Trong đồ thị Formula 1, có thể viết các truy vấn như sau
    1. Tìm một driver cụ thể đã đua cho constructor nào
    2. Tìm đối thủ bằng mẫu đi từ driver qua result và race tới result khác rồi tới driver khác
    3. Lọc đồng thời theo cấu trúc và điều kiện thuộc tính, chẳng hạn các kết quả có vị trí xuất phát ngoài top 10 và driver là người Ý
  • Khi đã biết trước hình dạng quan hệ và cấu trúc đó cố định, hữu hạn, cú pháp tìm kiếm, lọc và tổng hợp sẽ dễ đọc hơn
  • Các truy vấn cần nhiều lần self-join cũng có thể được biểu diễn dễ đọc bằng một mẫu MATCH duy nhất

• Bài toán không biết trước chính đường đi

  • Các bài toán sau không phù hợp với Property Graph của Postgres 19
    • Đường đi ngắn nhất giữa hai driver
    • Tất cả đối tượng có thể tới được trong N hop
    • Tìm kiếm kết nối với độ sâu không thể biết trước
  • Những truy vấn này cần duyệt độ dài biến đổi, nên phải dùng CTE đệ quy trên các bảng nền
  • Các thuật toán đồ thị như PageRank, phát hiện cộng đồng, tính centrality cũng là vấn đề khác với pattern matching, nên không thuộc phạm vi của tính năng này
  • Property Graph tìm các đối tượng kết nối khi đã biết cấu trúc đường đi, nhưng không thể khám phá đường đi khi chưa biết X và Y được kết nối qua đường nào, cũng không tính được tầm quan trọng cấu trúc của đồ thị

Những điểm cần cân nhắc trước khi áp dụng

• SQL/PGQ là lớp phủ khai báo đặt trên cấu trúc khóa ngoại hiện có, và không lưu thêm dữ liệu trừ khi bạn chọn làm như vậy bằng cách khác
• Lợi ích chính có hai điểm
  • Có thể viết các lượt duyệt có dạng cố định dễ đọc hơn so với join quan hệ
  • Cung cấp một đối tượng có tên để tài liệu hóa schema như một đồ thị
• Hạn chế lớn nhất là không có đường đi có độ dài biến đổi, nên các tìm kiếm sâu hoặc mở phải xử lý bằng SQL đệ quy
• Bản thân bảng không có bản chất là đỉnh hay cạnh; trong mỗi đồ thị, bạn có thể quyết định đọc các hàng của bảng đó như đỉnh, cạnh hoặc cả hai
• Nếu muốn truy vấn các mẫu đồ thị cố định trên schema hiện có trong Postgres 19, có thể cân nhắc CREATE PROPERTY GRAPH và MATCH trước khi chuyển dữ liệu sang một graph database riêng
• Nếu cần khám phá độ sâu chưa biết, bạn cần CTE đệ quy, nhưng dù dùng cách nào thì dữ liệu cũng không cần rời khỏi Postgres
• Trước khi áp dụng thực tế, cần tự kiểm thử xem hiệu năng có đạt yêu cầu hay không