Cơ sở dữ liệu đồ thị (Graph Database) và mô hình đồ thị thuộc tính (Property Graph) · RDF

1. Tổng quan

Định nghĩa: Cơ sở dữ liệu đồ thị là cơ sở dữ liệu biểu diễn dữ liệu bằng nút (Node), quan hệ (Edge hoặc Relationship) và thuộc tính (Property) thay vì tập hợp các hàng và cột độc lập, lấy quan hệ làm cốt lõi của cấu trúc lưu trữ để truy vấn hiệu quả sự kết nối, đường đi và mẫu (pattern).

Cơ sở dữ liệu quan hệ lưu thực thể trong bảng và khôi phục quan hệ giữa các bảng bằng khóa ngoại và JOIN. Cách này rất mạnh về tính toàn vẹn, tổng hợp và giao dịch đối với dữ liệu có cấu trúc, nhưng với những bài toán mà độ sâu kết nối tăng lên hoặc số loại quan hệ không ngừng tăng thì truy vấn có thể trở nên phức tạp. Hãy xét bài toán phát hiện gian lận trong đó con người với tài khoản, tài khoản với giao dịch, giao dịch với thiết bị đầu cuối, thiết bị với địa chỉ IP được nối qua nhiều bước: câu hỏi cốt lõi không còn là giá trị trong từng bảng mà là “chúng được kết nối theo đường đi nào”.

Cơ sở dữ liệu đồ thị không tạo lại các kết nối này bằng phép nối mỗi khi truy vấn, mà quản lý nút và quan hệ cùng nhau ngay từ lúc lưu trữ. Nhờ vậy, các câu hỏi xoay quanh đường đi như “có thể đi từ A đến B không”, “hai khách hàng có quan hệ chung qua bao nhiêu bước”, “một giao dịch cụ thể có liên hệ với nhóm tấn công đã biết hay không” được biểu đạt một cách tự nhiên. Ưu điểm của đồ thị không có nghĩa là mọi truy vấn đều tự động nhanh, mà là mô hình dữ liệu và cách thực thi phù hợp với những bài toán mà độ rộng và độ sâu duyệt quan hệ là quan trọng.

Bối cảnh khiến cơ sở dữ liệu đồ thị được chú ý là sự gia tăng tính kết nối của dữ liệu. Trong mạng xã hội, chuỗi cung ứng, mạng viễn thông, đồ thị tri thức, hệ thống gợi ý và mạng giao dịch tài chính, chính quan hệ giữa các dữ liệu, chứ không phải bản thân dữ liệu, quyết định ý nghĩa nghiệp vụ. Trong môi trường mà quan hệ liên tục được bổ sung theo quy tắc nghiệp vụ mới, việc mô hình hóa trực tiếp đối tượng miền và quan hệ thành đồ thị có thể linh hoạt trước thay đổi hơn so với việc tiếp tục phân rã bảng rồi nối lại.

Tuy nhiên, cơ sở dữ liệu đồ thị không thay thế hoàn toàn cơ sở dữ liệu quan hệ. Với các nghiệp vụ mà trọng tâm là tổng hợp quyết toán quy mô lớn, lược đồ hàng-cột chặt chẽ, phân tích số liệu phức tạp hay tích hợp với công cụ SQL phổ dụng, mô hình quan hệ có thể phù hợp hơn. Kỹ sư chuyên nghiệp (Professional Engineer) cần tổng hợp độ phức tạp của quan hệ, độ sâu truy vấn, yêu cầu nhất quán, mẫu phân tích, nhân lực vận hành và hệ sinh thái để chọn đồ thị theo một trong các cách: độc lập, bổ trợ hoặc polyglot (đa mô hình).

Phạm vi của ghi chú này gồm cấu trúc cơ bản của cơ sở dữ liệu đồ thị, khác biệt giữa đồ thị thuộc tính và đồ thị RDF, nguyên lý mô hình hóa, truy vấn và phân tích, so sánh với cơ sở dữ liệu quan hệ, các tình huống trong công nghiệp và những điểm cần cân nhắc khi triển khai dưới góc nhìn Kỹ sư chuyên nghiệp.

2. Mô hình dữ liệu đồ thị và cấu trúc tổng thể

Có thể coi đồ thị (G) là cặp gồm tập đỉnh (V) và tập cạnh (E), tức (G=(V,E)). Nút biểu diễn thực thể như con người, sản phẩm, tài khoản, tài liệu, địa điểm; quan hệ biểu diễn kết nối có ý nghĩa giữa các nút. Khi gán thuộc tính cho nút và quan hệ, ta có thể biểu diễn trực tiếp các sự kiện miền như “khách hàng A đã dùng thiết bị X”, “sản phẩm P thuộc danh mục C”.

Trong đồ thị thuộc tính, nút được gắn một hoặc nhiều nhãn (label), còn quan hệ được gán hướng và loại. Ví dụ, đặt quan hệ USED giữa nút Customer và nút Device, rồi đặt các thuộc tính như usedAt, channel, riskScore trên chính quan hệ đó. Vì bản thân quan hệ là một sự kiện nghiệp vụ, việc quan hệ có thể mang thuộc tính là điểm khác biệt so với danh sách kề (adjacency list) đơn thuần.

graph LR
    C["Khách hàng<br/>Customer<br/>id=C100"] -->|USED<br/>usedAt, channel| D["Thiết bị<br/>Device<br/>id=D77"]
    C -->|OWNS| A["Tài khoản<br/>Account<br/>id=A10"]
    A -->|TRANSFERRED_TO<br/>amount, time| B["Tài khoản nhận<br/>Account<br/>id=A20"]
    D -->|SEEN_FROM| IP["Địa chỉ IP<br/>IP<br/>value=203.0.113.8"]
    C -->|PURCHASED| P["Sản phẩm<br/>Product<br/>sku=P9"]

Trong cấu trúc trên, khách hàng, thiết bị, tài khoản, sản phẩm, địa chỉ IP là nút; USED, OWNS, TRANSFERRED_TO... là loại quan hệ. amount và time không phải thuộc tính của nút tài khoản nhận mà là thuộc tính của quan hệ chuyển tiền. Nếu phân định sai điều này, các sự kiện quan hệ thay đổi theo thời gian sẽ bị ghi đè lên nút, làm mất lịch sử và khả năng kiểm toán.

Nút gồm định danh, nhãn và tập thuộc tính. Định danh có thể là khóa nghiệp vụ hoặc khóa nội bộ của hệ thống; khi hợp nhất khóa của nhiều hệ thống vào một đồ thị, cần quyết định về tính duy nhất toàn cục, xung đột khóa và việc tái sử dụng khóa. Nhãn thể hiện vai trò của nút và được dùng để xác định phạm vi của chỉ mục và ràng buộc.

Quan hệ nối nút đầu với nút cuối và thường có hướng, loại và thuộc tính. Ngay cả với quan hệ vô hướng về mặt nghiệp vụ, khi lưu trữ nên quy định một hướng nhất quán và cho phép duyệt hai chiều thì vận hành sẽ thuận lợi hơn. Nếu dùng lẫn lộn hướng một cách tùy tiện, cùng một kết nối có ý nghĩa như nhau có thể bị lưu trùng thành hai loại, khiến kết quả truy vấn đường đi sai khác.

Thuộc tính là dữ liệu khóa-giá trị gắn với nút hoặc quan hệ. Vì thuộc tính được dùng làm điều kiện tìm kiếm, điều kiện sắp xếp và tính điểm, kiểu dữ liệu phải được xác định rõ. Nếu lưu ngày tháng dưới dạng chuỗi hoặc đơn vị tiền tệ mỗi bản ghi mỗi khác, thì dù việc duyệt đồ thị vẫn thành công, độ tin cậy của kết quả phân tích sẽ sụp đổ.

Cài đặt bên trong của cơ sở dữ liệu đồ thị khác nhau theo sản phẩm, nhưng về mặt logic có thể hiểu theo các tầng: danh mục (catalog), chỉ mục, kho lưu nút, kho lưu quan hệ, bộ máy truy vấn và tầng giao dịch. Có loại động cơ đồ thị gốc (native) lưu quan hệ ở dạng kề để có thể lần theo nhanh, trong khi cũng có cơ sở dữ liệu đa mô hình cung cấp tầng truy vấn đồ thị trên nền kho lưu trữ quan hệ.

flowchart TB
    APP["Ứng dụng nghiệp vụ · công cụ phân tích"]
    API["API đồ thị / ngôn ngữ truy vấn<br/>Cypher·SPARQL·Gremlin v.v."]
    OPT["Bộ phân tích cú pháp · bộ tối ưu<br/>khớp mẫu · thống kê · kế hoạch thực thi"]
    TX["Giao dịch · điều khiển đồng thời<br/>nhất quán · log · khôi phục"]
    IDX["Chỉ mục · ràng buộc<br/>tìm theo định danh · thuộc tính"]
    NODE["Kho lưu nút"]
    EDGE["Kho lưu quan hệ<br/>tính kề · hướng · thuộc tính quan hệ"]
    ETL["Pipeline thu thập · đối soát · chuyển đổi"]
    SRC["RDB · tài liệu · sự kiện · nguồn tri thức ngoài"]
    APP --> API --> OPT --> TX
    OPT --> IDX
    TX --> NODE
    TX --> EDGE
    SRC --> ETL --> TX
    EDGE -. "Kết nối trực tiếp giữa các nút" .-> NODE

Trong xử lý truy vấn, chỉ mục giảm chi phí tìm nút xuất phát, còn kho lưu quan hệ giảm chi phí di chuyển từ nút đã tìm sang nút kế tiếp. Vì vậy, truy vấn đồ thị cần được thiết kế tách biệt hai câu hỏi “bắt đầu từ đâu” và “duyệt loại quan hệ nào qua bao nhiêu bước”. Việc duyệt toàn bộ khi điểm xuất phát không rõ ràng có thể tốn kém ngay cả khi đã có chỉ mục.

Khác biệt giữa phép nối quan hệ và duyệt đồ thị gốc xuất phát từ mục đích của cấu trúc lưu trữ. Phép nối quan hệ kết hợp các hàng của từng bảng theo điều kiện, trong khi duyệt đồ thị mở rộng tập nút kế tiếp bằng cách lần theo quan hệ kề của nút hiện tại. Do đó, đồ thị mạnh ở những truy vấn có độ dài đường đi ngắn và độ chọn lọc cao, còn với tổng hợp toàn cục quy mô lớn thì một động cơ phân tích riêng hoặc kho lưu trữ dạng cột có thể phù hợp hơn.

3. Đồ thị thuộc tính và đồ thị RDF

Khi thiết kế cơ sở dữ liệu đồ thị, điều cần quyết định trước tiên là mô hình ngữ nghĩa của đồ thị. Mô hình được dùng rộng rãi trong các sản phẩm thực tế là đồ thị thuộc tính, còn trong chuẩn web, biểu diễn tri thức và tích hợp dữ liệu thì đồ thị RDF đóng vai trò quan trọng. Cả hai đều biểu diễn nút và kết nối, nhưng khác nhau về định danh, thuộc tính, ngữ nghĩa và cách truy vấn nên không được coi là một.

A. Đồ thị thuộc tính (Property Graph)

Đồ thị thuộc tính là mô hình cho phép đặt thuộc tính khóa-giá trị trên cả nút lẫn quan hệ. Nút được gán nhãn, quan hệ được gán loại và hướng, nhờ đó biểu diễn trực quan cấu trúc đối tượng của miền ứng dụng. Ví dụ, (:Person {id:'P1'})-[:WORKS_AT {since:2020}]->(:Company {id:'C1'}) biểu diễn con người, công ty và ngày bắt đầu làm việc trong một mẫu quan hệ duy nhất.

Đồ thị thuộc tính có ưu điểm là có thể nhanh chóng bắt đầu duyệt miền và phân tích đường đi. Khi đặt since, weight, status vào quan hệ, ta có thể phân biệt nhiều sự kiện nghiệp vụ giữa cùng hai nút. Tuy nhiên, tên và ngữ nghĩa thuộc tính có thể khác nhau giữa các tổ chức, nên nếu không quản lý nhãn, loại quan hệ và kiểu thuộc tính như một chuẩn dữ liệu thì đồ thị linh hoạt nhưng tính nhất quán sẽ thấp.

Thiết kế định danh trong đồ thị thuộc tính đặc biệt quan trọng. Nếu dùng nguyên các khóa nghiệp vụ nhạy cảm như số định danh cư dân hay số tài khoản làm định danh nút, dữ liệu cá nhân có thể lan rộng qua log, bản sao lưu và lịch sử truy vấn. Cách an toàn là dùng khóa thay thế (surrogate key) nội bộ và quản lý khóa của hệ thống nguồn như một thuộc tính được bảo vệ riêng hoặc bằng bảng ánh xạ.

B. Đồ thị RDF

RDF (Resource Description Framework) biểu diễn sự kiện dưới dạng bộ ba (triple) chủ ngữ (subject) · vị ngữ (predicate) · tân ngữ (object). Ví dụ, ex:customer100 ex:owns ex:account10 là một sự kiện cho biết khách hàng sở hữu tài khoản. Tài liệu khái niệm RDF 1.1 của W3C định nghĩa đồ thị RDF là tập các bộ ba RDF, và mô tả IRI, literal, blank node là các RDF term.

RDF mạnh ở chỗ giúp các tổ chức khác nhau thống nhất định danh và ngữ nghĩa của dữ liệu để liên kết với nhau. Khi định danh tài nguyên toàn cục bằng IRI và kết hợp ontology với quy tắc suy luận, ta có thể biểu đạt về mặt ngữ nghĩa “tài nguyên này thuộc khái niệm cấp trên nào”. Trong tích hợp dữ liệu và dữ liệu liên kết (linked data), khả năng trao đổi và ngữ nghĩa này thường quan trọng hơn tên thuộc tính riêng của từng ứng dụng.

SPARQL là ngôn ngữ truy vấn cho dữ liệu RDF. Mẫu đồ thị cơ bản (basic graph pattern) là tổ hợp các mẫu bộ ba được khớp với đồ thị con, và có thể trả kết quả theo các dạng SELECT, CONSTRUCT, ASK, DESCRIBE. Dùng OPTIONAL, UNION, FILTER, hàm tổng hợp và property path, ta có thể biểu đạt các mẫu đồ thị phức tạp và đường đi nhiều bước.

C. Tiêu chí lựa chọn giữa hai mô hình

Đồ thị thuộc tính thuận tiện để lập trình viên ứng dụng mô hình hóa nhanh đối tượng, quan hệ, thuộc tính và hiện thực thuộc tính quan hệ, đường đi, gợi ý, phát hiện gian lận. RDF phù hợp với môi trường mà trọng tâm là tích hợp ngữ nghĩa giữa các tổ chức, từ vựng chuẩn, trao đổi dữ liệu, đồ thị tri thức và suy luận. Không mô hình nào tuyệt đối ưu việt hơn; chính người tiêu dùng dữ liệu và yêu cầu khả năng tương tác quyết định lựa chọn mô hình.

Phân loại	Đồ thị thuộc tính	Đồ thị RDF
Biểu diễn cơ bản	Nút · quan hệ · thuộc tính	Bộ ba chủ ngữ · vị ngữ · tân ngữ
Cách định danh	ID và nhãn theo sản phẩm · miền	Định danh toàn cục lấy IRI làm trung tâm
Thuộc tính quan hệ	Gán trực tiếp thuộc tính khóa-giá trị cho quan hệ	Tái cấu trúc quan hệ thành tài nguyên hoặc dùng reification · named graph
Truy vấn chính	Cypher · Gremlin · ngôn ngữ riêng của sản phẩm	SPARQL
Điểm mạnh	Mô hình hóa trực quan · duyệt đường đi · phát triển ứng dụng	Ngữ nghĩa · tích hợp dữ liệu · trao đổi chuẩn · suy luận
Lưu ý	Cần thỏa thuận riêng về ngữ nghĩa · lược đồ giữa các tổ chức	Cần quản lý thiết kế ontology và chi phí suy luận

Khác biệt trong bảng không đơn thuần là khác biệt cú pháp. Trong đồ thị thuộc tính, việc gắn thuộc tính cho chính quan hệ là tự nhiên, nhưng đơn vị cơ bản của RDF là bộ ba nên cách biểu diễn sự kiện bổ sung về một quan hệ sẽ khác. Ngược lại, IRI và ontology của RDF có lợi trong việc khiến nhiều nhà cung cấp dữ liệu cùng trỏ đến một khái niệm, còn với đồ thị thuộc tính thì sự thỏa thuận này phải được bổ sung bằng quản trị (governance) riêng.

4. Quy trình mô hình hóa · nạp dữ liệu · xử lý truy vấn

Xây dựng đồ thị không phải là công việc ETL đơn thuần chuyển dữ liệu nguồn sang đồ thị. Cốt lõi là quá trình mô hình hóa miền để quyết định đối tượng nào thành nút và sự kiện nào thành quan hệ. Nếu chỉ lưu “khách hàng đã mua sản phẩm” như trạng thái hiện tại của khách hàng và sản phẩm, ta sẽ mất thời điểm mua, số lượng, giá và kênh. Việc đặt sự kiện mua thành quan hệ hay thành một nút sự kiện riêng phải được quyết định theo mức độ quan trọng của lịch sử và phân tích.

Bước đầu tiên là thu thập các truy vấn và câu hỏi nghiệp vụ. “Tìm đường chuyển tiền giữa hai tài khoản” và “tổng hợp doanh thu theo tháng” đòi hỏi đặc tính lưu trữ và thực thi khác nhau. Câu hỏi thứ nhất coi trọng hướng quan hệ và điều kiện thời gian, câu hỏi thứ hai coi trọng tổng hợp dạng cột và phân vùng (partitioning), nên dù đưa cả hai vào cùng một đồ thị vẫn phải thiết kế kèm kho lưu trữ bổ trợ và đường truy xuất.

Bước thứ hai là xác định ứng viên nút, quan hệ, thuộc tính và chọn định danh. Nếu một thực thể nghiệp vụ bị trùng lặp ở nhiều nguồn, trước hết phải xác định quy tắc phân giải thực thể (entity resolution). Các quy tắc như có gộp những người trùng tên vào một nút hay không, những người khác nhau có thể dùng chung số điện thoại hay không sẽ chi phối kết quả kết nối của đồ thị.

Bước thứ ba là quy định hướng, bản số (cardinality), thời hạn hiệu lực và chính sách xóa của quan hệ. OWNS có thể hướng từ khách hàng tới tài khoản, còn TRANSFERRED_TO phải bảo toàn bên gửi và bên nhận của giao dịch chuyển tiền. Nếu xóa vật lý quan hệ vì nó đã bị hủy thì dấu vết kiểm toán có thể bị đứt, nên cách quản lý thời hạn hiệu lực bằng status, validFrom, validTo thường được sử dụng.

Bước thứ tư là áp dụng chỉ mục, ràng buộc và quy tắc chất lượng. Đặt chỉ mục cho các thuộc tính thường dùng để tìm điểm xuất phát như ID khách hàng và ID tài khoản, đồng thời thiết lập ràng buộc duy nhất để định danh không bị trùng. Các thuộc tính bắt buộc theo loại quan hệ, nhãn đầu-cuối được phép, phạm vi ngày tháng và đơn vị tiền cũng phải được kiểm tra trước khi nạp.

Bước thứ năm là tách riêng việc nạp hàng loạt ban đầu và việc phản ánh dữ liệu thay đổi. Lần nạp đầu được thực hiện có thể tái lập dựa trên ảnh chụp (snapshot) nguồn, sau đó các thay đổi được phản ánh qua CDC, sự kiện hoặc chênh lệch theo lô. Điều quan trọng là lưu ID sự kiện gốc và khóa lũy đẳng (idempotent key) để không phát sinh quan hệ trùng khi xử lý lại.

Bước thứ sáu là kiểm chứng đồng thời hiệu năng truy vấn và chất lượng đồ thị. Dù truy vấn tìm láng giềng 3 bước từ một khách hàng cụ thể chạy nhanh, nếu một nút hub có hàng triệu quan hệ thì toàn bộ kết quả có thể bùng nổ. Cần chỉ rõ độ sâu tối đa, số kết quả, giới hạn thời gian và loại quan hệ được phép để truy vấn vận hành không duyệt toàn bộ đồ thị một cách vô hạn.

5. Truy vấn đồ thị và thuật toán phân tích

Truy vấn đồ thị thường xác định nút xuất phát, khớp mẫu quan hệ, mở rộng tới các nút kế tiếp thỏa điều kiện, rồi trả về kết quả đường đi, tổng hợp và sắp xếp. Trong truy vấn đồ thị thuộc tính, người ta dùng ngôn ngữ khai báo cho phép đọc mẫu một cách trực quan. Ví dụ dưới đây chỉ nhằm minh họa khái niệm cú pháp; cú pháp và hàm thực tế cần được kiểm tra theo phiên bản sản phẩm.

MATCH p = (c:Customer)-[:TRANSFERRED_TO*1..3]->(a:Account)
WHERE c.id = 'C100'
  AND ALL(r IN relationships(p) WHERE r.status = 'COMPLETED')
RETURN a.id, length(p) AS hops
ORDER BY hops
LIMIT 50

Điều quan trọng trong truy vấn này là duyệt quan hệ hướng từ khách hàng tới tài khoản trong phạm vi 1–3 bước. Nếu để độ sâu vô hạn, thời gian thực thi sẽ không thể dự đoán do đồ thị có chu trình và các nút hub. Trong thực tế, người ta đưa đồng thời cửa sổ thời gian, loại quan hệ, trạng thái và số kết quả tối đa vào điều kiện để kiểm soát cả ý nghĩa nghiệp vụ lẫn hiệu năng.

Trong môi trường RDF, người ta dùng mẫu đồ thị cơ bản và property path của SPARQL. Ví dụ, mẫu tìm các tài nguyên có thể đạt tới bằng cách lần theo quan hệ ex:knows một hoặc nhiều lần từ một tài nguyên cụ thể biểu đạt đường đi lặp của quan hệ. W3C SPARQL 1.1 Query Language định nghĩa các đường đi tuần tự, lựa chọn, ngược chiều, 0 lần trở lên và 1 lần trở lên của property path.

Thuật toán đồ thị cần được phân biệt với truy vấn. Truy vấn tập trung tìm sự kiện và đường đi theo điều kiện cụ thể, còn thuật toán tính các đặc tính cấu trúc của toàn bộ đồ thị hoặc đồ thị con. Phân tích đường đi dùng các thuật toán họ BFS · DFS · Dijkstra; phân tích mức độ quan trọng dùng họ degree · closeness · betweenness · PageRank; phân tích nhóm dùng phát hiện cộng đồng và phân tích thành phần liên thông.

Tìm đường đi là bài toán tìm đường nối hai thực thể, đường đi ngắn nhất và mọi đường đi thỏa điều kiện. Trên mạng lưới đường bộ có thể dùng quãng đường, thời gian, phí cầu đường làm trọng số; trong chuỗi cung ứng có thể dùng thời hạn giao hàng, mức rủi ro, khả năng thay thế làm trọng số. Nếu không định nghĩa trước “ngắn nhất” nghĩa là khoảng cách, chi phí hay rủi ro thì dù thuật toán chính xác, kết quả nghiệp vụ vẫn sai.

Phân tích độ trung tâm (centrality) đo mức ảnh hưởng hoặc tầm quan trọng về mặt cấu trúc kết nối trong đồ thị. Độ trung tâm bậc xét số kết nối trực tiếp, độ trung tâm trung gian xét tần suất nút xuất hiện trên đường đi giữa các nút khác, độ trung tâm gần xét khoảng cách trung bình tới các nút khác. Trong phát hiện gian lận tài chính, tài khoản có độ trung tâm trung gian cao có thể là điểm trung chuyển dòng tiền, nhưng độ trung tâm cao không đồng nghĩa với hành vi gian lận, nên phải kết hợp quy tắc, mô hình và điều tra.

Phát hiện cộng đồng tìm các nhóm có kết nối bên trong dày đặc và kết nối ra bên ngoài tương đối ít. Có thể ứng dụng trong gợi ý xã hội, cụm rủi ro chuỗi cung ứng, phân tích tổ chức chiếm đoạt tài khoản. Số cụm và độ phân giải thay đổi theo thiết lập thuật toán, nên không được diễn giải kết quả như ranh giới tổ chức tuyệt đối mà phải dùng kèm nhãn nghiệp vụ, biến động theo thời gian và kiểm chứng thực địa.

Độ tương đồng và embedding là cách biểu diễn cấu trúc láng giềng hoặc thuộc tính của nút thành vector để tìm sản phẩm, tài liệu, khách hàng tương tự. Embedding đồ thị hữu ích cho gợi ý và phân loại, nhưng vector không tự động bảo toàn ý nghĩa, thời gian và quy tắc cấm của quan hệ gốc. Cần quản lý riêng việc đầu vào mô hình có chứa dữ liệu cá nhân hay không, hướng quan hệ và yêu cầu xóa có được phản ánh hay không, kết quả có tái lập được khi huấn luyện lại hay không.

6. So sánh với cơ sở dữ liệu quan hệ

Khác biệt giữa mô hình quan hệ và mô hình đồ thị không phải là khác biệt “bảng với hình vẽ”, mà là khác biệt ở chỗ quan hệ được tính ở đâu và với chi phí nào. Cơ sở dữ liệu quan hệ giảm trùng lặp nhờ bảng chuẩn hóa và chỉ mục, xử lý mạnh tổng hợp và giao dịch. Cơ sở dữ liệu đồ thị biểu diễn trực tiếp và duyệt các kết nối, giúp truy vấn quan hệ nhiều bước trở nên gọn gàng.

Hạng mục so sánh	Cơ sở dữ liệu quan hệ	Cơ sở dữ liệu đồ thị
Đơn vị cơ bản	Hàng · cột · bảng	Nút · quan hệ · thuộc tính
Biểu diễn quan hệ	Khóa ngoại và JOIN	Quan hệ được lưu và duyệt
Điểm mạnh	Tổng hợp dữ liệu có cấu trúc · giao dịch · hệ sinh thái SQL	Đường đi nhiều bước · mẫu kết nối · duyệt quan hệ
Thay đổi lược đồ	Lược đồ chặt chẽ và di trú (migration)	Mô hình linh hoạt hoặc tiến hóa dựa trên ràng buộc
Mức phù hợp cho phân tích	Tổng hợp số liệu quy mô lớn · báo cáo	Đường đi · độ trung tâm · cộng đồng · bất thường kết nối
Rủi ro	JOIN sâu · độ gắn kết lược đồ	Hub bậc cao · bùng nổ đường đi · thiếu chuẩn hóa
Trọng tâm vận hành	Chỉ mục · phân vùng · kế hoạch thực thi	Chọn điểm xuất phát · độ sâu duyệt · chất lượng đồ thị

Trong cơ sở dữ liệu quan hệ, truy vấn nối liên tiếp 5 bảng sẽ tốn kém tùy theo thứ tự nối, thống kê và kích thước kết quả trung gian. Cơ sở dữ liệu đồ thị cũng không miễn phí, nhưng nếu được lưu để lần theo các quan hệ kề đã được nối sẵn thì việc duyệt cùng những quan hệ đó có thể thực hiện trực tiếp hơn. Ngược lại, công việc tổng hợp theo nhóm toàn bộ hàng tỷ nút không thể giải quyết chỉ bằng lưu trữ đồ thị, mà có thể cần bản sao dành cho phân tích hoặc động cơ dạng cột.

Tính linh hoạt của lược đồ cũng là điểm dễ hiểu lầm. Dù đồ thị linh hoạt khi thêm thuộc tính, nếu không kiểm soát định danh, ý nghĩa quan hệ, thuộc tính bắt buộc và các kết nối bị cấm thì chất lượng dữ liệu sẽ xuống cấp nhanh chóng. Vì vậy, không được hiểu “schemaless” (không lược đồ) là “governanceless” (không quản trị), mà phải quản lý lược đồ logic và quy tắc chất lượng trong một danh mục riêng.

Trong thực tế, hai loại thường được xem là bổ trợ hơn là cạnh tranh. Sổ cái khách hàng, tài khoản và quyết toán thanh toán được xử lý trong hệ thống quan hệ, còn việc duyệt quan hệ và phân tích rủi ro có thể được chiếu (project) sang đồ thị. Khi đó phải lập văn bản về quyền sở hữu dữ liệu: đồ thị thay thế hệ thống sổ cái, là đồ thị dẫn xuất chỉ đọc, hay là hệ thống bản ghi gốc (system of record) cho một phần quan hệ.

7. Các tình huống ứng dụng

A. Phát hiện giao dịch bất thường · gian lận tài chính

Trong mạng giao dịch tài chính, có thể lấy tài khoản, khách hàng, thiết bị, số điện thoại, IP, đơn vị chấp nhận thẻ, tài khoản nhận làm nút, và các quan hệ sở hữu, sử dụng, đăng nhập, chuyển tiền, dùng chung làm cạnh. Một giao dịch trông bình thường nếu chỉ nhìn số tiền, nhưng khi lộ ra cụm tài khoản dùng chung một thiết bị trong thời gian ngắn hoặc đường đi tới địa chỉ đã bị trừng phạt, thì có thể nâng mức ưu tiên điều tra.

Ví dụ, giả sử giao dịch chuyển tiền mới của khách hàng C100 phát sinh từ thiết bị D77, D77 đã được dùng cho nhiều tài khoản mới trong 24 giờ qua, và các tài khoản đó cùng dồn về tài khoản nhận A20. Truy vấn đồ thị có thể tìm đường khách hàng → thiết bị → tài khoản khác → tài khoản nhận và biến nó thành đặc trưng rủi ro. Chỉ số này trở thành căn cứ điều tra có thể giải thích được, nhưng việc có chặn thực sự hay không phải được quyết định có xét đến số tiền giao dịch, xác minh khách hàng, chi phí báo động giả và thủ tục pháp lý.

Trong thiết kế vận hành, truy vấn đường đi thời gian thực và phân tích theo lô được tách riêng. Giai đoạn phê duyệt thời gian thực chỉ dùng độ sâu giới hạn, cửa sổ thời gian gần và các loại quan hệ cốt lõi, còn phân tích ban đêm tính cộng đồng, độ trung tâm và mẫu dài hạn. Cấu trúc không ghi đè trực tiếp kết quả đồ thị làm phán quyết cuối cùng cho giao dịch sổ cái, mà chuyển điểm rủi ro và đường chứng cứ sang hệ thống thẩm định, sẽ có lợi cho kiểm toán và xử lý báo động giả.

B. Gợi ý và đồ thị tri thức

Trong hệ thống gợi ý, có thể liên kết người dùng, sản phẩm, danh mục, thương hiệu, từ khóa tìm kiếm và sự kiện mua hàng. Các đường đi như “sản phẩm mà khách hàng đã xem sản phẩm này cũng xem” hay “sản phẩm tương tự danh mục khách hàng ưa thích” có thể được mở rộng để dùng đồng thời lọc cộng tác (collaborative filtering) và thuộc tính nội dung.

Trong đồ thị tri thức, tài liệu, khái niệm, cơ quan, nhân vật, văn bản pháp luật, sản phẩm được liên kết bằng định danh chuẩn, đồng thời lưu kèm nguồn, ngày tạo, độ tin cậy và thời hạn hiệu lực. Khi dùng đồ thị để tăng cường truy xuất cho AI tạo sinh, cần truy vết đường đi và nguồn văn bản gốc được dùng cho câu trả lời, và không được bảo đảm tính xác thực của sự kiện chỉ vì chúng được kết nối với nhau.

Điểm cốt lõi của tình huống gợi ý không phải là số lượng kết nối mà là ý nghĩa của kết nối. Nếu gộp việc mua và việc chỉ xem vào cùng quan hệ INTERACTED, mô hình sẽ không phân biệt được ý định mua mạnh với sự quan tâm yếu. Cần chỉ rõ loại quan hệ, trọng số và độ suy giảm theo thời gian, đồng thời phản ánh bằng chính sách các giới hạn gợi ý liên quan đến người chưa thành niên, sản phẩm nhạy cảm và gợi ý dựa trên dữ liệu cá nhân.

C. Phân tích phụ thuộc chuỗi cung ứng · tài sản

Trong chuỗi cung ứng, có thể liên kết sản phẩm, linh kiện, nhà cung cấp, nhà máy, tuyến vận tải, chứng nhận, quốc gia và yêu cầu pháp quy. Khi một nhà cung cấp linh kiện nào đó ngừng cung ứng, có thể tìm các sản phẩm bị ảnh hưởng và nhà cung cấp thay thế qua đường đi nhiều bước, đồng thời truy vết việc chứng nhận hết hạn ảnh hưởng tới dây chuyền sản xuất nào.

Trong quản lý tài sản CNTT, khi liên kết dịch vụ, ứng dụng, API, máy chủ, cơ sở dữ liệu, tài khoản đám mây và đơn vị phụ trách, có thể thực hiện phân tích tác động của thay đổi. Nếu trước khi triển khai kiểm tra đường đi từ dịch vụ bị thay đổi tới các thành phần thanh toán, dữ liệu cá nhân, khôi phục thảm họa, thì dễ hiểu phạm vi ảnh hưởng nghiệp vụ hơn so với việc chỉ tìm kiếm tệp cấu hình.

Trong tình huống này, tính cập nhật của đồ thị là quan trọng. Nếu CMDB và danh mục tài sản đã cũ, đồ thị sẽ trả lời bằng các kết nối trong quá khứ chứ không phải phụ thuộc thực tế. Cập nhật dựa trên sự kiện, xác nhận chủ sở hữu, đối chiếu với dữ liệu quan sát (observability) và vô hiệu hóa các quan hệ đã hết hạn là thủ tục bắt buộc của vận hành chất lượng.

8. Chuyên sâu: Kết hợp phân tích đồ thị · tìm kiếm vector · đồ thị tri thức

Gần đây, việc ứng dụng đồ thị đang mở rộng vượt ra ngoài CRUD đơn thuần theo hướng kết hợp phân tích đồ thị với tìm kiếm vector. Khi embedding tài liệu hoặc sản phẩm để tìm độ tương đồng, rồi dùng đồ thị để lọc theo quyền truy cập, nguồn, thời gian và ngữ cảnh nghiệp vụ, ta có thể chọn được kết quả vừa tương tự về ngữ nghĩa vừa được phép về mặt nghiệp vụ.

Tuy nhiên, độ tương đồng vector và tính kết nối đồ thị là hai tín hiệu khác nhau. Không có gì bảo đảm tài liệu gần nhau trong không gian embedding là tài liệu căn cứ chính thức của tổ chức, cũng không có gì bảo đảm tài liệu được kết nối trên đồ thị là phù hợp về ngữ nghĩa với câu hỏi. Do đó, pipeline tìm kiếm phải tách riêng và quan sát được các khâu: sinh ứng viên vector, lọc theo điều kiện đồ thị, xác nhận căn cứ văn bản gốc, xếp hạng lại (re-ranking) và trích dẫn trong câu trả lời.

Khi xây dựng đồ thị tri thức, cần phân biệt vòng đời của ontology với dữ liệu sự kiện. Nếu vì hệ thống khái niệm thay đổi mà ghi đè mọi sự kiện quá khứ bằng khái niệm hiện tại thì khả năng tái lập theo thời điểm sẽ mất. Nên lưu cho mỗi sự kiện nguồn, thời điểm thu thập, thời hạn hiệu lực, độ tin cậy, trạng thái kiểm chứng, và quản lý riêng phiên bản ontology cùng quy tắc ánh xạ.

Khả năng mở rộng của phân tích đồ thị chịu ảnh hưởng của phân bố kết nối nhiều hơn là số nút. Nếu một nút hub có số kết nối lớn bất thường, kết quả duyệt sẽ bùng nổ và việc tính cộng đồng, độ trung tâm cũng tốn thêm bộ nhớ và thời gian. Cần dùng bộ lọc trước cho nút bậc cao, lấy mẫu, đồ thị phân cấp, cắt lát theo thời gian và đặc trưng tính trước để kiểm soát chi phí phân tích toàn đồ thị.

W3C RDF 1.1 và SPARQL 1.1 có thể dùng làm điểm chuẩn cho trao đổi, biểu diễn và truy vấn đồ thị. Ngược lại, ngôn ngữ truy vấn và tính năng lưu trữ của đồ thị thuộc tính khác nhau lớn giữa các sản phẩm, nên không được nhầm cú pháp của một sản phẩm cụ thể là chuẩn dữ liệu của tổ chức. Khi triển khai, việc tách riêng mô hình logic, lớp trừu tượng truy vấn, định dạng trao đổi và bộ điều hợp (adapter) theo sản phẩm sẽ nâng cao khả năng di chuyển về lâu dài.

9. Những điểm cần cân nhắc và hàm ý

A. Mô hình hóa suy ngược từ câu hỏi nghiệp vụ

Điểm xuất phát của việc áp dụng đồ thị không nên là chọn sản phẩm hay “số lượng nút”, mà là những câu hỏi về quan hệ mà hệ thống hiện có liên tục không giải quyết được. Cần xác nhận đường đi sâu, quan hệ động và giải thích dựa trên kết nối có phải là cốt lõi của giá trị nghiệp vụ hay không; nếu chỉ là bài toán danh sách hoặc tổng hợp đơn giản thì không thêm đồ thị có thể giảm độ phức tạp tổng thể.

B. Chất lượng đồ thị và phân giải thực thể

Nếu gộp sai cùng một thực thể từ các nguồn khác nhau, đồ thị sẽ tạo ra đường đi giả. Không chỉ so sánh đơn giản tên, địa chỉ, số điện thoại mà phải quản lý độ tin cậy của định danh, quy tắc khớp, rà soát thủ công, lịch sử hợp nhất và tách. Chỉ số chất lượng đồ thị có thể bao gồm tỷ lệ nút mồ côi, tỷ lệ nút trùng, tỷ lệ thiếu quan hệ bắt buộc, tỷ lệ lỗi thời hạn hiệu lực và tỷ lệ sự kiện không có nguồn.

C. Hiệu năng · chi phí · khả năng mở rộng

Chỉ mục điểm xuất phát, độ chọn lọc theo loại quan hệ, độ sâu duyệt, nút hub và giới hạn kết quả phải là các trục cơ bản của thiết kế hiệu năng. Truy vấn vận hành cần có timeout và số lần mở rộng tối đa, còn phân tích dài hạn thực hiện trên đồ thị phân tích · theo lô riêng. Trong đồ thị phân tán, việc duyệt quan hệ vượt qua phân vùng phát sinh chi phí mạng, nên phải xem xét có đặt các dữ liệu thường được duyệt cùng nhau vào cùng phân vùng hay không và phân tán điểm nóng (hotspot) như thế nào.

D. Tính nhất quán và ranh giới với hệ thống sổ cái

Nếu vô tình chuyển hệ thống bản ghi gốc của dữ liệu cần nhất quán mạnh như thanh toán, số dư tài khoản, tồn kho sang đồ thị thì sẽ phát sinh sổ cái kép. Khi đặt đồ thị làm mô hình đọc dẫn xuất, phải định nghĩa độ trễ CDC, sự kiện trùng, đảo thứ tự, phản ánh việc xóa và tiêu chí xử lý lại. Phạm vi cho phép mà kết quả đồ thị có thể khác sổ cái và SLA về độ cập nhật phải được thỏa thuận theo từng nghiệp vụ.

E. Bảo mật · dữ liệu cá nhân · kiểm toán

Đồ thị, thông qua kết nối nhiều tập dữ liệu, cho phép những suy luận nhạy cảm vốn không có trong nguồn. Vì đường đi quan hệ có thể làm lộ hành vi, quan hệ và mức rủi ro của cá nhân, cần áp dụng kiểm soát truy cập ở cấp nút và quan hệ, bộ lọc hàng-cột hoặc đồ thị con, log truy vấn theo mục đích, che (masking) và bí danh hóa. Với yêu cầu xóa, không chỉ xóa nút trực tiếp mà phải truy vết và xử lý cả quan hệ dẫn xuất, cache, embedding, bản sao lưu và chỉ mục tìm kiếm.

F. Chuẩn hóa và phụ thuộc nhà cung cấp

Trước hết phải quyết định có cần khả năng tương tác dựa trên RDF · SPARQL hay ưu tiên sự tiện lợi phát triển và tính năng sản phẩm của đồ thị thuộc tính. Cần đánh giá khác biệt về ngôn ngữ truy vấn, chỉ mục, giao dịch, tính năng phân tán giữa các sản phẩm, và tách mô hình logic khỏi mô hình vật lý để bảo đảm khả năng chuyển đổi. Trong PoC, thay vì trình diễn tính năng, cần đo bộ truy vấn thực tế, thời gian nạp lại dữ liệu, khôi phục sự cố, sao lưu-phục hồi và chi phí học tập của nhân lực vận hành.

G. Khả năng quan sát vận hành và khả năng giải thích

Với dịch vụ đồ thị, chỉ giám sát độ trễ truy vấn là chưa đủ. Cần quan sát đồng thời độ sâu duyệt, số quan hệ được mở rộng, số kết quả, tần suất truy cập nút hub, độ trễ CDC, nút mồ côi, vi phạm quy tắc chất lượng và thiếu nguồn. Với các kết quả ảnh hưởng tới quyết định như phát hiện gian lận, gợi ý, tìm kiếm AI, phải lưu lại nút, quan hệ, bộ lọc và phiên bản mô hình đã dùng như một đường chứng cứ để có thể tái lập và cho phép khiếu nại.

Tài liệu tham khảo

W3C, RDF 1.1 Concepts and Abstract Syntax: https://www.w3.org/TR/rdf11-concepts/
W3C, SPARQL 1.1 Query Language: https://www.w3.org/TR/sparql11-query/
Neo4j, What is a graph database: https://neo4j.com/docs/getting-started/graph-database/
Neo4j, Cypher Manual Introduction: https://neo4j.com/docs/cypher-manual/current/introduction/
Oracle, What Is a Graph Database?: https://www.oracle.com/apac/autonomous-database/what-is-graph-database/

Tóm tắt một câu: Cơ sở dữ liệu đồ thị là công nghệ coi quan hệ là dữ liệu hạng nhất (hơn cả nút) để tối ưu phân tích đường đi, mẫu và kết nối; giá trị thực tiễn chỉ phát sinh khi thiết kế đồng thời khác biệt mục đích giữa đồ thị thuộc tính và RDF, chất lượng dữ liệu, bảo mật và ranh giới với sổ cái.