Sử dụng cơ sở dữ liệu đồ thị trong hệ gợi ý

dữ liệu cho hệ gợi ý vì cơ sở dữ liệu đồ thị hỗ trợ tốt cho lưu trữ và thao tác với các mối quan hệ, mà đây là đặc trưng của dữ liệu trong các hệ gợi ý: Mối quan hệ giữa người dùng với s

BỘ GIÁO DỤC VÀ ĐÀO TẠO

TRƯỜNG ĐẠI HỌC QUY NHƠN

LỜI CAM ĐOAN

Tôi xin cam đoan những kết quả đƣợc trình bày trong luận văn này là của riêng tôi, không sao chép từ bất kỳ một công trình nào khác Nếu có điều

gì không trung thực, tôi xin chịu hoàn toàn trách nhiệm

HỌC VIÊN

LÊ QUYỀN

LỜI CẢM ƠN

Lời đầu tiên, cho phép tôi gửi lời cảm ơn đến TS TRẦN THIÊN THÀNH, người thầy đã luôn quan tâm giúp đỡ, hướng dẫn, chỉ bảo tận tình giúp tôi hoàn thành luận văn này

Tôi xin chân thành cảm ơn Quý Thầy Cô trong Khoa Công nghệ thông tin trường Đại Học Quy Nhơn vì những kiến thức mà quý Thầy Cô truyền đạt cho tôi trong suốt quá trình học tập tại trường

Xin chân thành cảm ơn các anh chị em lớp cao học Khoa học máy tính khoá 2019 – 2021 (K22) và các bạn đồng nghiệp đã luôn bên cạnh, động viên, khuyến khích tôi trong suốt thời gian học tập và thực hiện đề tài

Cuối cùng, tôi xin gửi đến gia đình, chính từ sự hỗ trợ và động viên từ phía gia đình mà tôi yên tâm học tập tốt và hoàn thành luận văn

Xin chân thành cảm ơn!

NGƯỜI THỰC HIỆN

LÊ QUYỀN

MỤC LỤC

LỜI CAM ĐOAN

LỜI CẢM ƠN

DANH MỤC CÁC THUẬT NGỮ, TỪ VIẾT TẮT

DANH MỤC CÁC BẢNG

DANH MỤC CÁC HÌNH VẼ

MỞ ĐẦU 1

1 Lý do chọn đề tài 1

2 Mục đ ch và nhiệm vụ nghi n cứu 1

3 Đối tượng và phạm vi nghiên cứu 1

4 Phương pháp nghiên cứu 2

5 Nội dung nghiên cứu 2

CHƯƠNG I TỔNG QUAN 3

1.1 Cơ sở dữ liệu đồ thị 3

1.1.1 Khái niệm đồ thị 3

1.1.2 Cơ sở dữ liệu đồ thị (Graph Database) 8

1.1.3 Một số ứng dụng của cơ sở dữ liệu đồ thị 18

1.2 Cơ sở dữ liệu đồ thị Neo4j 20

1.2.1 Giới thiệu chung 20

1.2.2 Mô hình dữ liệu 21

1.2.3 Ngôn ngữ truy vấn Cypher 23

1.2.4 Python với Neo4j Desktop 28

1.2.5 Chỉ mục (Indexing) 29

1.3 Tổng quan về hệ thống gợi ý 33

1.3.1 Giới thiệu chung 33

1.3.2 Ứng dụng của hệ thống gợi ý 36

1.3.3 Bài toán gợi ý 37

1.4 Một số phương pháp gợi ý 38

1.4.1 Phương pháp Gợi ý dựa trên Nội dung (Content-based) 39

1.4.2 Collaborative filtering - CF (lọc cộng tác) 39

1.4.3 Hybrid approach (các phương pháp lai) 46

1.5 Tiểu kết chương 1 47

CHƯƠNG 2 XÂY DỰNG HỆ GỢI Ý SỬ DỤNG NEO4J 48

2.1 Xây dựng cơ sở dữ liệu 48

2.1.1 Tổ chức dữ liệu Neo4j cho hệ gợi ý đơn giản 48

2.1.2 Nạp dữ liệu từ csv vào Neo4j 49

2.2 Thuật toán tính dự đoán rating bằng Cosin, Pearson 49

2.2.1 Thuật toán sử dụng tương quan Pearson 49

2.2.2 Thuật toán sử dụng độ tương tự Cosin 50

2.2.3 Thuật toán gợi ý k-sản phẩm 51

2.3 Các thuật toán đánh giá độ chính xác 53

2.3.1 Đánh giá dự đoán xếp hạng sản phẩm 53

2.3.2 Đánh giá gợi ý sản phẩm 56

2.4 Tiểu kết chương 2 59

CHƯƠNG 3 THỰC NGHIỆM 61

3.1 Công cụ thực nghiệm 61

3.2 Thực nghiệm 63

3.3 Phân tích kết quả thực nghiệm 65

KẾT LUẬN 66

DANH MỤC TÀI LIỆU THAM KHẢO 68 QUYẾT ĐỊNH GIAO ĐỀ TÀI LUẬN VĂN THẠC SĨ (BẢN SAO)

DANH MỤC CÁC THUẬT NGỮ, TỪ VIẾT TẮT

KNN K-Nearest Neighbor K láng giềng gần nhất

SDP Sparsity Data Problem Vấn đề dữ liệu thưa

User-Based

k-NN

User-Based k Neareast Neighbor

Phương pháp K láng giềng gần nhất dựa vào người dùng Item-Based k-

NN

Item-Based k Neareast Neighbor

Phương pháp K láng giềng gần nhất dựa vào sản phẩm

Chỉ những người dùng hệ thống để tìm kiếm lựa chọn sản phẩm

Chỉ những sản phẩm trên hệ thống như: sản phẩm, phim, ảnh, bản nhạc, trang web,

đoạn văn bản,…

Chỉ mức độ đánh giá của một người dùng với một sản phẩm Rating có thể có nhiều dạng biểu diễn: nhị phân (thích hoặc không th ch), hay đánh giá theo mức độ từ 1-5 ―dấu sao‖ đại diện 5 mức độ từ không th ch đến rất th ch…

NNLT Programming language Ngôn ngữ lập trình

DANH MỤC CÁC BẢNG

Bảng 1 1 Thời gian thực thi cho nhiều truy vấn kết hợp sử dụng công cụ

cơ sở dữ liệu MySQL trên tập dữ liệu 1.000 người dùng 12

Bảng 1 2 Thời gian thực hiện để duyệt đồ thị bằng Neo4j trên tập dữ liệu 1.000 người dùng 15

Bảng 1 3 Thời gian thực thi cho nhiều truy vấn kết hợp sử dụng công cụ cơ sở dữ liệu MySQL trên tập dữ liệu 1 triệu người dùng 16

Bảng 1 4 Thời gian thực hiện để duyệt đồ thị bằng Neo4j trên tập dữ liệu 1 triệu người dùng 17

Bảng 1 5 Công cụ và kỹ thuật để thực hiện các truy vấn Cypher 24

Bảng 1 6 Minh họa đánh giá của người dùng về 1 số bộ phim đã xem 38

Bảng 1 7 Ma trận đánh giá 40

Bảng 3 1 Các bộ dữ liệu thực nghiệm 63

Bảng 3 2 Kết quả thực nghiệm về tốc độ xử lý 64

Bảng 3 3 kết quả thực nghiệm độ chính xác 65

DANH MỤC CÁC HÌNH VẼ

Hình 1 1 Ví dụ đơn đồ thị 3

Hình 1 2 Ví dụ đa đồ thị 4

Hình 1 3 Đồ thị được gắn nhãn đại diện cho cặp đỉnh 5

Hình 1 4 Đồ thị có nhãn đại diện cho một hàm 5

Hình 1 5 Đồ thị gắn nhãn là tập hợp các quan hệ 6

Hình 1 6 Đồ thị thuộc t nh biểu diễn thông tin thư mục của các công bố khoa học 7

Hình 1 7 Đồ thị thuộc tính (Thomas Frisendal) 7

Hình 1 8 Người dùng và bạn bè của họ được biểu diễn dưới dạng cấu trúc dữ liệu đồ thị 10

Hình 1 9 Đồ thị SQL của các bảng biểu diễn dữ liệu người dùng và bạn bè 11

Hình 1 10 Duyệt dữ liệu đồ thị mạng xã hội 14

Hình 1 11 Tổng quan về CSDL đồ thị 29

Hình 2 1 Lược đồ cơ sở dữ liệu đồ thị cho hệ gợi ý 48

dữ liệu cho hệ gợi ý vì cơ sở dữ liệu đồ thị hỗ trợ tốt cho lưu trữ và thao tác với các mối quan hệ, mà đây là đặc trưng của dữ liệu trong các hệ gợi ý: Mối quan hệ giữa người dùng với sản phẩm, mối quan hệ người dùng với người

dùng, mối quan hệ giữa sản phẩm với sản phẩm

2 Mụ đ v n vụ n n u

Sử dụng cơ sở dữ liệu đồ thị mà cụ thể là Neo4J để lưu trữ dữ liệu của các hệ gợi ý và xây dựng các chức năng t nh toán trong hệ gợi ý bằng công cụ lập trình trên Neo4j

Thực nghiệm các chức năng của hệ gợi ý bằng dữ liệu MovieLens để đưa ra gợi ý các bộ phim cho từng người dùng dựa vào các phim họ đã đánh giá và những người dùng khác đã đánh giá Cách tiếp cận thực nghiệm dùng phương pháp lọc cộng tác dựa trên thuật toán láng giềng

3 Đối tượng và phạm vi nghiên c u

- Cơ sở dữ liệu đồ thị Neo4j

- Ngôn ngữ lập trình Python

- Hệ gợi ý sử dụng phương pháp lọc cộng tác dựa trên láng giềng

- Dữ liệu thực nghiệm: MovieLens

(https://grouplens.org/datasets/movielens/)

- Phân tích và tổng hợp kết quả thực nghiệm

5 Nội dung nghiên c u

- Tìm hiểu về cơ sở dữ liệu đồ thị và Neo4J

- Tìm hiểu về lập trình Python cho Neo4J

- Tìm hiểu về hệ gợi ý

- Triển khai một số thuật toán lọc cộng tác tr n cơ sở dữ liệu đồ thị

- Thực nghiệm gợi ý phim cho người dùng trên dữ liệu MovieLens được lưu trong Neo4J

Đồ thị G được biểu diễn dưới dạng tập hợp là một cặp gồm 2 tập hợp

G = (V, E) Trong đó:

o Tập đỉnh

o Tập cạnh *( ) +

Đồ thị có hướng (Directed Graph) là đồ thị mà mỗi cạnh là cặp đỉnh

có thứ tự Đồ thị vô hướng (Undirected Graphs) thì các cạnh là cặp đỉnh không có thứ tự

Mỗi cạnh của đồ thị có thể được gán trọng số được gọi là đồ thị có trọng số

Đơn đồ thị là một đồ thị mà giữa hai đỉnh có nhiều nhất một cạnh

Hình 1 1 V dụ đơn đồ t ị

Đa đồ thị là đồ thị mà giữa hai đỉnh có nhiều hơn một cạnh Hai cạnh

e1 và e2 được gọi là cạnh lặp (bội hay song song) nếu chúng cùng tương ứng với một cặp đỉnh

một hoặc nhiều hàm của các đỉnh Ví dụ: một đồ thị về các kết nối của các

hãng hàng không có thể hiển thị múi giờ của từng sân bay

Khi các cạnh được gắn nhãn, đồ thị sau đó biểu diễn một quan hệ bậc

ba Trong một đồ thị có nhãn, không có gì lạ khi có nhiều hơn một cạnh từ đỉnh v1 đến đỉnh v2, miễn là chúng có các nhãn khác nhau Ví dụ: một đồ thị

được gắn nhãn có thể chứa cả hai cạnh → và → Đồ thị được gắn nhãn có thể được sử dụng cho ba mục đ ch khác nhau

Đầu tiên, một đồ thị được gắn nhãn có thể đại diện cho một hàm từ

các cặp đỉnh đến nhãn Ví dụ: các đỉnh có thể đại diện cho các sân bay và các

nhãn có thể đại diện cho khoảng cách giữa chúng Trong trường hợp này, có thể có nhiều nhất một cạnh ở mỗi hướng giữa hai đỉnh bất kỳ

Hình 1 3 Đồ t ị đượ ắn n ãn đạ d n o ặp đỉn

Thứ hai, một đồ thị có nhãn có thể đại diện cho một hàm trong đó mỗi

cạnh ánh xạ nhãn và đỉnh nguồn của nó với đỉnh đ ch của nó Trong trường hợp này, nhiều nhất một cạnh có thể để lại mỗi đỉnh với một nhãn nhất định, mặc dù một số cạnh (được dán nhãn khác nhau) có thể nối cùng một cặp đỉnh

Hình 1 4 Đồ t ị ó n ãn đạ d n o ột

Thứ ba, một đồ thị được gắn nhãn có thể đại diện cho một tập hợp các

quan hệ, mà tên của chúng được đặt bởi các nhãn trên các cạnh Ví dụ: cạnh

→ có nghĩa là (v1,v2) là một yếu tố của mối quan hệ A, và cạnh

→ có nghĩa là (v2,v3) là một yếu tố của mối quan hệ B Do đó, đồ thị của các quan hệ thành phần này chỉ đơn giản là đồ thị con mà chúng ta thu

được bằng cách chỉ xem xét các cạnh được gắn nhãn tương ứng của đồ thị Ngược lại, chúng ta có thể chồng các đồ thị của một số quan hệ, miễn là chúng ta dán nhãn các cạnh đúng cách

- σ : (N E)×P  SET+(V) là một ánh xạ kết hợp mỗi đỉnh hoặc cạnh với

một những thuộc t nh và mỗi thuộc t nh gán cho nó một tập những giá trị trong V

Hình 1 6 Đồ t ị t uộ t n u d n t n t n t ư ụ a á n ố oa ọ [1]

Theo Thomas Frisendal, Đồ thị thuộc tính bao gồm:

Hình 1 7 Đồ t ị t uộ t n (Thomas Frisendal)

Một ứng dụng quan trọng của lý thuyết đồ thị đó là việc biểu diễn cơ

sở dữ liệu đồ thị, là nội dung luận văn sẽ tìm hiểu dưới đây

1.1.2 Cơ sở dữ liệu đồ thị (Graph Database)

Theo [2], Khoa học máy tính có liên quan mật thiết đến toán học, với rất nhiều khái niệm ban đầu xuất phát từ triết học toán học Thuật toán, mật

mã, tính toán, tự động hóa, và thậm chí cả các lý thuyết cơ bản của logic toán học và đại số Boolean đều là những khái niệm toán học kết hợp chặt chẽ giữa hai ngành này Một chủ đề toán học khác thường dễ dàng được tìm thấy trong các sách và bài báo về khoa học máy tính: lý thuyết đồ thị Trong khoa học máy tính, đồ thị được sử dụng để biểu diễn cấu trúc dữ liệu cụ thể, chẳng hạn như phân cấp tổ chức, mạng xã hội và luồng xử lý Thông thường, trong giai đoạn thiết kế phần mềm, các cấu trúc, quy trình và thuật toán được mô tả bằng sơ đồ, đồ thị Cấu trúc hướng đối tượng của hệ thống máy t nh cũng được mô hình hóa dưới dạng đồ thị, với các kế thừa, thành phần và đối tượng

Nhưng mặc dù đồ thị được sử dụng rộng rãi trong quá trình phát triển phần mềm, các nhà phát triển có xu hướng qu n đồ thị khi nói đến tính ổn định của dữ liệu Chúng ta cố gắng khớp dữ liệu vào các quan hệ bảng và cột, đồng thời chuẩn hóa và chuẩn hóa lại cấu trúc cho đến khi trông hoàn toàn khác với cấu trúc ban đầu

Một bài toán kiểm soát truy cập là một ví dụ Đây là một vấn đề được giải quyết lặp đi lặp lại trong nhiều ứng dụng doanh nghiệp bài toán thường

có các bảng cho người dùng, vai trò và tài nguy n Sau đó, bài toán sẽ có nhiều bảng để ánh xạ người dùng đến các vai trò và các vai trò với tài nguyên Cuối cùng, bài toán sẽ có ít nhất năm bảng quan hệ để đại diện cho một cấu trúc dữ liệu khá đơn giản, thực ra là một đồ thị Sau đó, bài toán sẽ sử dụng công cụ ánh xạ quan hệ đối tượng (Object-relational Mapping - ORM) để ánh

xạ dữ liệu này tới mô hình đối tượng của bài toán, cũng là một đồ thị

Sẽ thật tuyệt nếu bài toán có thể biểu diễn dữ liệu ở dạng tự nhiên nhất, làm cho các ánh xạ trở nên trực quan hơn và bỏ qua quá trình lặp đi lặp

lại ―dịch‖ dữ liệu đến và từ một công cụ lưu trữ? Nhờ cơ sở dữ liệu đồ thị, bài toán có thể được giải quyết Cơ sở dữ liệu đồ thị sử dụng mô hình đồ thị để lưu trữ dữ liệu dưới dạng đồ thị, với cấu trúc bao gồm đỉnh và các cạnh, hai thực thể được sử dụng để lập mô hình bất kỳ đồ thị nào

Ngoài ra, có thể sử dụng tất cả các thuật toán từ lịch sử lâu đời của lý thuyết đồ thị để giải quyết các vấn đề về đồ thị hiệu quả hơn và trong thời gian ngắn hơn so với việc sử dụng các truy vấn cơ sở dữ liệu quan hệ

1.1.2.1 Tại sao lại sử dụng cơ sở dữ liệu đồ thị? Tại sao lại là Neo4J?

Tại sao lại sử dụng cơ sở dữ liệu đồ thị, hay cụ thể hơn là Neo4j, làm

cơ sở dữ liệu mà luận văn này lựa chọn? Như đã đề cập trước đó, mọi người thường cố gắng lập mô hình hoặc mô tả một cách hợp lý miền vấn đề cụ thể bằng cách sử dụng các cấu trúc và khái niệm giống như đồ thị, mặc dù có thể không sử dụng cơ sở dữ liệu đồ thị làm nơi lưu trữ dữ liệu cuối cùng Việc chọn đúng nơi lưu trữ dữ liệu để chứa dữ liệu, có thể làm cho ứng dụng hoạt động tốt hơn, hiệu quả hơn rất nhiều

Một cách tốt để trả lời câu hỏi này là đưa một vấn đề phù hợp một cách tự nhiên với thế giới tự nhiên dựa tr n đồ thị và so sánh giải pháp sử dụng cơ sở dữ liệu đồ thị (Neo4j là một lựa chọn) với một giải pháp sử dụng một cơ sở dữ liệu khác Đối với mục đ ch so sánh, luận văn sẽ sử dụng cơ sở

dữ liệu quan hệ truyền thống, vì đây là cơ sở dữ liệu phổ biến cho hầu hết các bài toán khi tìm hiểu các tùy chọn lưu trữ dữ liệu

Ví dụ mà chúng ta sẽ khám phá là một mạng xã hội — một tập hợp những người dùng có thể là bạn của nhau Hình 1.8 minh họa mạng xã hội, nơi người dùng kết nối với mũi t n là bạn bè

Dữ liệu đồ thị trong cơ sở dữ liệu quan hệ

Hình 1 8 N ườ dùn v ạn è a ọ đượ u d n dướ dạn ấu trú dữ l u đồ t ị [2]

1.1.2.2 Dữ liệu đồ thị trong cơ sở dữ liệu quan hệ

Trong cơ sở dữ liệu quan hệ, chúng ta thường có hai bảng quan hệ để lưu trữ dữ liệu mạng xã hội: một bảng cho thông tin người dùng và một bảng khác cho mối quan hệ giữa những người dùng (xem Hình 1.8)

Mã lệnh sau đây cho thấy tập lệnh SQL để tạo bảng bằng cơ sở dữ liệu MySQL

Mã l n 1 1 Tập l n SQL xá địn á ản o dữ l u ạn xã ộ

create table t_user (

id bigint not null,

name varchar(255) not null,

primary key (id)

);

create table t_user_friend (

id bigint not null,

user_1 bigint not null,

user_2 bigint not null,

primary key (id) );

alter table t_user_friend

add index FK416055ABC6132571 (user_1),

add constraint FK416055ABC6132571

foreign key (user_1) references t_user (id);

alter table t_user_friend

add index FK416055ABC6132572 (user_2),

add constraint FK416055ABC6132572

foreign key (user_2) references t_user (id);

IS_FRIEND_OF IS_FRIEND_OF

IS_FRIEND_OF IS_FRIEND_OF

IS_FRIEND_OF

IS_FRIEND_OF IS_FRIEND_OF

IS_FRIEND_OF

IS_FRIEND_OF IS_FRIEND_OF IS_FRIEND_OF

Địn n ĩa ản o lưu trữ t n t n n ười dùng

Địn n ĩa bản đ lưu trữ quan h bạn bè

Khóa ngoại ràng buộc

Bảng t_user chứa các cột với thông tin người dùng, trong khi bảng t_user_friend chỉ đơn giản là có hai cột tham chiếu đến bảng t_user bằng cách

sử dụng quan hệ khóa ngoại Các cột khóa chính và khóa ngoại có chỉ mục cho các thao tác tra cứu nhanh hơn, một chiến lược thường được sử dụng khi lập mô hình cơ sở dữ liệu quan hệ

select count(distinct uf2.*) from t_user_friend uf1

➥ inner join t_user_friend uf2 on uf1.user_1 = uf2.user_2

ONE-TO-MANY

làm điều gì đó tương tự để tìm bạn của bạn bè của bạn bè của một người dùng, bạn cần một join tiếp theo:

select count(distinct uf3.*) from t_user_friend uf1

➥ inner join t_user_friend uf2 on uf1.user_1 = uf2.user_2

➥ inner join t_user_friend uf3 on uf2.user_1 = uf3.user_2

➥ where uf1.user_1 = ?

Tương tự, để lặp lại cấp độ bạn bè thứ tư, bạn cần có bốn lần join

Để có được tất cả các kết nối cho vấn đề có sáu cấp độ, cần có sáu lần join

Theo [2], Để minh họa hiệu suất của các truy vấn như vậy, chúng ta tham khảo truy vấn của bạn bè một vài lần dựa trên một tập dữ liệu nhỏ gồm 1.000 người dùng, nhưng đã tăng độ sâu của tìm kiếm với mỗi lần gọi và ghi lại kết quả Trên một tập dữ liệu nhỏ gồm 1.000 người dùng, trong đó trung bình mỗi người dùng có 50 người bạn, bảng t_user chứa 1.000 bản ghi, trong khi bảng t_user_friend chứa 1.000*50 = 50.000 bản ghi

Bảng 1.1 cho thấy kết quả của thí nghiệm

Ghi chú: Tất cả các thử nghiệm đều được thực hiện trên một

máy tính xách tay Intel i7 với RAM 8 GB Với độ sâu 3, 4 và 5, kết quả đếm được là 999 Do tập dữ liệu nhỏ, bất kỳ người dùng nào trong cơ sở

dữ liệu đều được kết nối với tất cả những người khác

Như vậy, cơ sở dữ liệu quan hệ không quá tuyệt vời để mô hình hóa các mối quan hệ nhiều-nhiều, đặc biệt là trong các tập dữ liệu lớn Mặt khác,

Cơ sở dữ liệu đồ thị (ở đây luận văn sử dụng Neo4j để thực nghiệm) vượt trội trong các mối quan hệ nhiều-nhiều

1.1.2.3 Dữ liệu đồ thị trong Cơ sở dữ liệu đồ thị

Trong phần này, luận văn sẽ sử dụng cơ sở dữ liệu Neo4j để giới thiệu

về cơ sở dữ liệu đồ thị

Neo4j lưu trữ dữ liệu dưới dạng đỉnh và cạnh, hoặc theo thuật ngữ

Neo4j, nodes (các điểm giao, nút) và relationships (các mối quan hệ) Người

dùng sẽ được biểu thị dưới dạng các nút và bạn bè sẽ được biểu thị dưới dạng mối quan hệ giữa các nút người dùng Ta sẽ thấy mạng xã hội trong hình 1.8,, với người dùng là các nút và các mũi t n bạn bè là các mối quan hệ

Có một điểm khác biệt chính giữa cơ sở dữ liệu quan hệ và Neo4j chúng ta cần phải quan tâm: truy vấn dữ liệu Không có bảng và cột nào trong Neo4j, cũng không có bất kỳ lệnh select hay join nào dựa trên nền tảng SQL Vậy, làm thế nào để truy vấn một cơ sở dữ liệu đồ thị?

Neo4j, giống như tất cả các cơ sở dữ liệu đồ thị, lấy một khái niệm toán học mạnh mẽ từ lý thuyết đồ thị và sử dụng nó như một công cụ mạnh

mẽ và hiệu quả để truy vấn dữ liệu Khái niệm này là duyệt đồ thị, và đó là một trong những công cụ chính khiến Neo4j trở nên mạnh mẽ để xử lý dữ liệu

Neo4j cung cấp một Traversal API phong phú giúp chúng ta có thể sử

dụng để điều hướng qua đồ thị Ngoài ra, cũng có thể sử dụng REST API hoặc ngôn ngữ truy vấn Neo4j để duyệt dữ liệu

Để có được tất cả bạn bè của bạn bè của người dùng, mã trong danh sách sau sẽ thực hiện điều đó:

Mã l n 1 2 Mã Traversal API a Neo4j đ tì tất ả ạn è ở độ sâu 2:

Iterable<Node> nodes = traversalDescription.traverse(nodeById).nodes();

Bảng 1.2 hiển thị các số liệu hiệu suất để thực hiện dựa trên một đồ thị

có chứa cùng dữ liệu trong cơ sở dữ liệu MySQL trước đó (trong đó thao tác duyệt có chức năng giống như các truy vấn được thực hiện trước đó tr n cơ sở

dữ liệu, tìm kiếm bạn bè của bạn bè theo chiều sâu đã xác định) Một lần nữa, điều này dành cho tập dữ liệu 1.000 người dùng với trung bình 50 bạn bè trên mỗi người dùng

IS_FRIEND_OF

IS_FRIEND_OF

IS_FRIEND_OF IS_FRIEND_OF

IS_FRIEND_OF

Bản 1 2 T ờ an t ự n đ duy t đồ t ị ằn Neo4j tr n tập dữ l u 1.000 n ườ dùn

Độ sâu Thời gian thực hi n (giây)

cho 1000 bản ghi Kết quả

Ghi chú: Tương tự như thiết lập MySQL, không có điều chỉnh hiệu

suất bổ sung nào được thực hiện trên phiên bản Neo4j Neo4j đang chạy ở chế độ nhúng, với cấu hình mặc định và 2.048 MB bộ nhớ heap JVM

Điều đầu tiên cần chú ý là hiệu suất của Neo4j tốt hơn đáng kể đối với tất cả các truy vấn, ngoại trừ truy vấn đơn giản nhất Chỉ khi tìm kiếm bạn bè của bạn bè (ở độ sâu 2) thì hiệu suất của MySQL mới có thể so sánh được với hiệu suất của trình duyệt Neo4j Thao tác duyệt bạn bè ở độ sâu 3 nhanh hơn bốn lần so với đối tác MySQL Khi thực hiện duyệt ở độ sâu 4, kết quả tốt hơn rất rõ ràng Kết quả độ sâu 5 nhanh hơn 10 triệu lần so với truy vấn MySQL!

Một kết luận khác có thể nhận thấy từ kết quả trong bảng 1.2 là hiệu suất của truy vấn chỉ suy giảm một chút theo độ sâu khi số lượng các nút được trả về vẫn như cũ Hiệu suất truy vấn MySQL suy giảm theo độ sâu của truy vấn do tích Descartes được thực thi trước khi hầu hết các kết quả bị loại

bỏ

Neo4j theo dõi các nút đã truy cập, vì vậy nó có thể bỏ qua các nút mà

nó đã truy cập trước đó và do đó cải thiện đáng kể hiệu suất

Để tìm tất cả bạn bè ở độ sâu 5, MySQL sẽ thực hiện một tích Descartes trên bảng t_user_friend 5 lần, kết quả là 50.0005 dòng, trong đó tất

cả bị loại bỏ chỉ còn lại ~1.000 Neo4j chỉ cần truy cập các nút trong cơ sở dữ liệu và khi không còn nút nào để truy cập, nó sẽ dừng thao tác duyệt Đó là lý

do tại sao Neo4j có thể duy trì hiệu suất không đổi miễn là số lượng nút trả về

vẫn giữ nguyên, trong khi có sự suy giảm đáng kể về hiệu suất khi sử dụng các truy vấn MySQL

Duyệt đồ thị hoạt động tốt hơn đáng kể so với các truy vấn MySQL tương đương (tốt hơn hàng nghìn lần với độ sâu là 4 và 5) Đồng thời, hiệu suất không giảm đột ngột theo độ sâu - tốc độ ở độ sâu 5 chỉ chậm hơn 0,03 giây so với tốc độ ở độ sâu 2 Hiệu suất của các truy vấn MySQL phức tạp nhất chậm hơn 10.000 lần so với truy vấn đơn giản

1.1.2.4 Truy vấn SQL và duyệt đồ thị trên quy mô lớn

Đối với thử nghiệm này, sử dụng chính xác các cấu trúc dữ liệu như trước đây; sự khác biệt duy nhất là số lượng dữ liệu

Trong MySQL, có 1.000.000 bản ghi trong bảng t_user và khoảng 1.000.000*50 = 50.000.000 bản ghi trong bảng t_user_friend Chúng ta chạy bốn truy vấn giống nhau đối với tập dữ liệu này (bạn bè ở độ sâu 2, 3, 4 và 5) Bảng 1.3 cho thấy các kết quả thu thập được về hiệu suất của các truy vấn SQL trong trường hợp này

Bản 1 3 T ờ an t ự t o n ều truy vấn ết ợp sử dụn n ụ ơ sở dữ l u

MySQL tr n tập dữ l u 1 tr u n ườ dùn

Độ sâu Thời gian thực hi n (giây)

cho 1 tri u bản ghi Kết quả

Bản 1 4 T ờ an t ự n đ duy t đồ t ị ằn Neo4j tr n tập dữ l u 1 tr u n ười dùng

Độ sâu Thời gian thực hi n (giây) cho 1 tri u

Lý do chính cho khả năng dự đoán của Neo4j là bản chất cục bộ của việc duyệt đồ thị; bất kể có bao nhiêu nút và mối quan hệ trong đồ thị, thao tác duyệt sẽ chỉ truy cập những nút được kết nối với nút bắt đầu, theo quy tắc duyệt Một lần nữa, join trong SQL tạo ra tích Descartes dữ liệu trước khi loại bỏ các kết quả không liên quan, ảnh hưởng đến hiệu suất theo cấp số nhân cùng với sự tăng trưởng của tập dữ liệu Neo4j chỉ truy cập vào các nút

có li n quan đến quy tắc duyệt, vì vậy nó có thể duy trì hiệu suất có thể dự đoán được bất kể tổng k ch thước tập dữ liệu là bao nhiêu Càng nhiều nút mà duyệt phải truy cập, thì đường truyền càng chậm Nhưng sự gia tăng này là tuyến tính và vẫn độc lập với tổng k ch thước đồ thị

Các thí nghiệm này chứng minh rằng cơ sở dữ liệu đồ thị Neo4j truy vấn dữ liệu đồ thị nhanh hơn đáng kể so với việc sử dụng cơ sở dữ liệu quan

hệ T nh độc lập của hiệu suất duyệt tr n k ch thước đồ thị là một trong những khía cạnh quan trọng khiến Neo4j trở thành ứng cử vi n lý tưởng để giải quyết các vấn đề về đồ thị, ngay cả khi tập dữ liệu rất lớn

1.1.3 Một số ứng dụng của cơ sở dữ liệu đồ thị

Khi áp dụng cơ sở dữ liệu đồ thị vào thực tế, với thực trạng kỹ thuật

và các ràng buộc về tài chính, các tổ chức/doanh nghiệp vẫn chọn cơ sở dữ liệu đồ thị bởi những lý do sau :

- Hiệu quả ―Từ phút đến mili giây‖: t nh hiệu quả và t nh đáp ứng của truy vấn là những vấn đề được quan tâm nhất của các bài toán Các hệ thống giao dịch trực tuyến, các ứng dụng web lớn cụ thể thì đều phải đáp ứng, phản hồi lại cho khách hàng (người dùng đầu cuối) trong một số mili giây nhất định nếu họ muốn thành công Cơ sở dữ liệu đồ thị tỏ ra hiệu quả hơn rất nhiều so với cơ sở dữ liệu quan hệ

- Chu kỳ phát triển có gia tốc lớn

- Đáp ứng t nh thương mại cực ổn: không phải di chuyển dữ liệu nhiều, đáp ứng được t nh hay thay đổi của kinh doanh

- Tính sẵn sàng cho doanh nghiệp: dữ liệu rất quan trọng, làm việc trong các ứng dụng kinh doanh quan trọng cần một công nghệ mạnh mẽ, có khả năng mở rộng và có tính giao dịch…

1.1.3.2 Các Hệ gợi ý

Các gợi ý hiệu quả là ví dụ điển hình của việc đưa đến cho người dùng đầu cuối những giá trị thông qua việc áp dụng khả năng suy luận hoặc gợi ý

Các thuật toán được sử dụng là quy nạp, gợi ý, xác định con người, sản phẩm hoặc dịch vụ mà các cá nhân hoặc nhóm quan tâm đến Chúng thiết lập mối quan hệ giữa người và người, người và sản phẩm hay bất cứ thứ gì trong phạm vi lĩnh vực đang được gợi ý Các mối quan hệ được thiết lập dựa trên hành vi của người sử dụng Từ đó bộ máy làm việc sẽ xác định nguồn lực quan tâm đến cá nhân hay nhóm có sở thích về một lĩnh vực của một tổ chức nào đó Đây là phương pháp thứ nhất

Phương pháp thứ hai là xác định người dùng hoặc nhóm người dùng cho một nguồn lực cụ thể, tập trung vào các đặc tính của nguồn lực đó bằng các câu hỏi Từ đó bộ máy làm việc xác định các nguồn lực tương tự như thế

và để người dùng kết hợp với chúng

1.1.3.3 Địa lý

Các ứng dụng về không gian địa lý của cơ sở dữ liệu đồ thị đặc biệt có

li n quan đến các lĩnh vực viễn thông, hậu cần, du lịch, lập lịch và quy hoạch tuyến đường

1.1.3.4 Quản lý dữ liệu chủ

Cơ sở dữ liệu đồ thị không cung cấp một giải pháp hoàn thiện về quản

lý dữ liệu chủ Nhưng chúng đang là giải pháp tốt nhất được áp dụng cho việc

mô hình, lưu trữ và truy vấn của hệ thống phân cấp, siêu dữ liệu chủ và các

mô hình dữ liệu chủ

1.1.3.5 Quản lý trung tâm dữ liệu và quản lý trung tâm mạng

Giải pháp cơ sở dữ liệu đồ thị hỗ trợ các công cụ phân tích và quản lý mạng hiện tại Như trường hợp của quản lý dữ liệu chủ, chúng có thể sử dụng

để cùng mang lại dữ liệu từ các hệ thống kiểm kê khác nhau, cung cấp một cái nhìn duy nhất đối với mạng và khách hàng của chúng, từ các phần tử nhỏ nhất đến các ứng dụng và các dịch vụ hay khách hàng sử dụng chúng Một cơ sở

dữ liệu đồ thị đại diện cho một mạng có thể được sử dụng để làm giàu cho tri thức hoạt động dựa trên các mối tương quan sự kiện Có thể giải th ch rõ hơn như sau: mỗi khi có một bộ máy tương quan sự kiện suy luận một sự kiện phức tạp từ một dòng các sự kiện mạng ở mức thấp, nó có thể đánh giá tác động của sự kiện đó bằng cách sử dụng mô hình đồ thị và sau đó k ch hoạt bất

kỳ hoạt động giảm nhẹ cần thiết nào

Ngày nay, cơ sở dữ liệu đồ thị đã đươc sử dụng thành công trong các lĩnh vực viễn thông, quản lý và phân tích mạng, quản lý nền tảng đám mây, trung tâm dữ liệu và quản lý phần tử IT Hiệu suất cao, tính linh hoạt trong việc đối mặt với sự thay đổi các lược đồ mạng cũng như phù hợp với miền là các yếu tố quan trọng của cơ sở dữ liệu đồ thị

1.1.3.6 Ủy quyền và kiểm soát truy cập (truyền thông)

Một cơ sở dữ liệu đồ thị có thể lưu trữ các cấu trúc phức tạp, cũng như các cấu trúc kiểm soát truy cập có kết nối dày đặc bao trùm hàng tỉ các bên tham gia và các nguồn tài nguyên Nó cấu trúc các mô hình dữ liệu không lược đồ hỗ trợ cả cấu trúc phân cấp và không phân cấp, trong khi mô hình thuộc tính mở rộng của nó cho phép nắm bắt siêu dữ liệu phong phú liên quan đến mỗi phần tử của hệ thống Với một công cụ truy vấn có thể đi qua hàng triệu mối quan hệ mỗi giây, thì xử lý tìm kiếm lớn, cấu trúc phức tạp chỉ thực hiện trong mili giây

1.2 Cơ sở dữ li u đồ thị Neo4j

1.2.1 Giới thiệu chung

Như từ đầu luận văn này, lý thuyết đồ thị cung cấp cho chúng ta nhiều kiểu đồ thị khác nhau để làm việc Đồ thị có nhiều hình dạng và kích cỡ khác nhau, và do đó, Neo4j cần chọn một loại cấu trúc dữ liệu rất cụ thể đủ linh hoạt để hỗ trợ tính linh hoạt theo yêu cầu của các bộ dữ liệu trong thế giới

thực Đây là lý do tại sao mô hình dữ liệu cơ bản của Neo4j, đồ thị thuộc tính được gắn nhãn, là một trong những mô hình đồ thị chung và linh hoạt nhất

Mô hình dữ liệu đồ thị này cung cấp cho chúng ta bốn cấu trúc cơ bản khác nhau để lưu trữ dữ liệu Đó là: Nodes, Labels, Relationships và Properties

Đây là cơ sở dữ liệu đồ thị đơn

giản nhất với 1 nút

1.2.2.2 Nhãn (Label)

Nhãn được sử dụng để định hình miền bằng cách nhóm các nút thành các tập hợp mà tất cả các nút có một nhãn nhất định thuộc cùng một tập hợp

1.2.2.3 Quan hệ (Relationships)

Mối quan hệ giữa các nút trong đồ thị là một phần quan trọng, dựa vào

đó có thể tìm kiếm dữ liệu có liên quan Mối quan hệ cũng có thể có thuộc tính

Mối quan hệ kết nối 2 nút được

đảm bảo hợp lệ từ nút bắt đầu đến nút

kết thúc

* Hướng (loại) quan h (Relationship types)

Một Relationships phải có chính xác một Relationship types

Mối quan hệ luôn có hướng, được xác định theo hướng đi vào hoặc đi

ra một nút Đây là yếu tố quan trọng được sử dụng khi duyệt đồ thị

1.2.2.4 Thuộc tính (Properties)

Cả mối quan hệ và nút đều có thể có

thuộc tính Các thuộc tính sẽ là cặp

khóa-giá trị mà khóa chính là một chuỗi Giá trị

của thuộc tính có thể là một kiểu giá trị

nguyên thủy hoặc mảng giá trị nguyên thủy

Ví dụ: String, int, int[]

Ví dụ:

Trong ví dụ trên, đồ thị có 1 thuộc

tính tên là “name”, với giá trị là “ Thu”

vì bị mất thời gian vào quyền truy cập cơ sở dữ liệu

Về cấu trúc, Cypher mƣợn cấu trúc của nó từ SQL - các truy vấn đƣợc xây dựng bằng cách sử dụng các mệnh đề khác nhau Các mệnh đề đƣợc liên kết với nhau và chúng cung cấp các tập kết quả trung gian giữa nhau

Name: Thu

1.2.3.2 Thực thi truy vấn Cypher

Có một số cách có thể thực hiện các truy vấn Cypher Neo4j đi kèm với một số công cụ hỗ trợ thực thi Cypher và Cypher cũng có thể đƣợc thực thi từ mã Python, giống nhƣ SQL Bảng 1.4 cho thấy các tùy chọn thực thi Cypher

Bảng 1 5 Công cụ và kỹ thuật đ thực hi n các truy vấn Cypher

Neo4j Web Admin Console Giao diện dựa trên web

1.2.3.3 Các lệnh cơ bản trong Cypher

Đọc thêm tài liệu về các câu lệnh Cypher tại:

a MATCH và RETURN

Ví dụ: Hiển thị User có id là ‗User 1‘

Mã lệnh Cypher:

MATCH (u:User {id:'User 1'}) RETURN u

b CREATE với Cypher

944‟}

Mã lệnh Cypher:

CREATE (u: User {id: ‘User 944’}) RETURN u

c UPDATE với Cypher

Ví dụ 1: Thêm thuộc tính birthday cho Person Jennifer

Mã lệnh Cypher:

MATCH (p: Person {name: ‚Jennifer‛})

SET p.birthday = date(‚1999-01-01‛)

Ví dụ 2: Jennifer làm việc ở công ty "Neo4j" từ năm 2018

Mã lệnh Cypher:

MATCH (:Person {name: ‚Jennifer‛})

-[rel:WORK_FOR]->(:Company {name: ‚Neo4j‛)

SET rel.start_year = date({year:2018})

d DELETE với Cypher

Ví dụ 1: Xóa mối quan hệ bạn bè giữa Jennifer và Mark

Mã lệnh Cypher:

MATCH (j: Person {name: ‚Jennifer‛})

-[friend: IS_FRIEND_WITH]->(m: Person {name: ‚Mark‛}) DELETE friend

Ví dụ 2: Xóa nút Person có property {name: "Mark"}

Mã lệnh Cypher:

MATCH (p: Person {name: ‚Mark‛) DELETE p

Ví dụ 3: Xóa đồng thời nút và mối quan hệ của nó

Mã lệnh Cypher:

MATCH (p: Person {name: ‚Mark‛}) DETACH DELETE p

e REMOVE với Cypher

Xóa hoàn toàn thuộc tính khỏi nút và không lưu trữ nó nữa

Ví dụ: Xóa thuộc tính birthday của Jennifer

Mã lệnh Cypher:

MATCH (p: Person {name: ‚Jennifer‛})

REMOVE p.birthday

f MERGE trong Cypher

MERGE thực hiện chọn lọc và kiểm tra dữ liệu có tồn tại trong CSDL hay không, trước khi chèn vào CSDL

Ví dụ 1: Chèn Person Mark vào CSDL bằng MERGE

MATCH (j: Person {name: ‚Jennifer‛})

MATCH (m: Person {name: ‚Mark‛})

MERGE (j)-[r: IS_FRIEND_WITH]->(m)

RETURN j, r, m

Sử dụng MATCH để thực hiện khớp dữ liệu trước khi tạo mối quan

hệ Nếu chỉ sử dụng MERGE mà không khớp dữ liệu sẽ dẫn đến việc lệnh MERGE tạo lại các nút đã tạo nếu không tìm thấy mối quan hệ giữa các nút

đó -> bị lặp dữ liệu

g Kết hợp MERGE, CREATE, MATCH và SET

Nếu muốn sử dụng MERGE để đảm bảo không tạo ra các bản sao,

đồng thời khởi tạo một số thuộc tính mới hoặc cập nhật lại các thuộc tính khác nếu nó chỉ được khớp, trong trường hợp này, ta sử dụng ON CREATE hoặc ON MATCH với SET

Mã lệnh Cypher:

MERGE (m: Person {name: ‚Mark‛})

-[r:IS_FRIEND_WITH]-(j: Person {name: ‚Jennifer‛})

ON CREATE SET r.since = date(‚2018-01-01‛)

ON MATCH SET r.update = date()

h WHERE trong Cypher

Mã lệnh Cypher với WHERE:

MATCH (person: Person)

WHERE person.name = ‚Jennifer‛

RETURN person

• WHERE NOT: trả về thuộc tính không khớp với mẫu

Mã lệnh Cypher:

MATCH (person: Person)

WHERE NOT person.name = ‚Jennifer‛

Mã lệnh Cypher:

MATCH (varname: NodeLabel)

WHERE varname.property IN your_array

RETURN varname

1.2.4 Python với Neo4j Desktop

1.2.4.1 Thư viện py2neo

Để thực thi các truy vấn Cypher trên Neo4j bằng NNLT Python, luận văn sử dụng thư viện py2neo

Tham khảo thêm tại: https://py2neo.org/2021.1/#

1.2.4.2 Thực thi truy vấn Cypher bằng NNLT Python

Đoạn mã sau minh họa việc thực thi một truy vấn Cypher bằng Python trên Jupyter, tìm tất cả các phim cùng rating mà một người dùng cụ thể đã xem và đánh giá:

#Kết nối Neo4j qua thư viện py2neo

from py2neo import Graph, Node

graph=Graph("bolt://localhost:7687",auth=("neo4j", "123456789"))

#Thực thi truy vấn Cypher

query = 'MATCH (u:User{id:’User 1’})-[r:RATED]->(m:Movie) RETURN u.id AS uid, m.id AS mid, r.rating AS rating '

mối quan hệ giữa các node, và đến các thuộc tính của các node và các mối quan hệ đó Để thực hiện truy vấn trong 1 cơ sở dữ liệu đồ thị, ta thực hiện một phép duyệt đồ thị dựa trên một giải thuật để xác định đường đi theo thứ

tự của các node

1.2.5.1 Tạo chỉ mục

- Tạo chỉ mục thuộc t nh đơn tr n các nút: Có thể tạo chỉ mục được đặt tên trên một thuộc tính cho tất cả các nút có nhãn cụ thể CREATE INDEX index_name FOR (n:Label) ON (n.property) Lưu ý rằng chỉ mục không có sẵn ngay lập tức mà được tạo ở chế độ nền

CREATE INDEX node_index_name FOR (n:Person) ON (n.surname) Lưu ý rằng tên chỉ mục cần phải là duy nhất

- Tạo chỉ mục thuộc t nh đơn tr n các mối quan hệ: Có thể tạo chỉ mục được đặt tên trên một thuộc tính cho tất cả các mối quan hệ có kiểu quan hệ

cụ thể CREATE INDEX index_name FOR ()-[r:TYPE]-() ON (r.property) Lưu ý rằng chỉ mục không có sẵn ngay lập tức mà được tạo ở chế độ nền

CREATE INDEX rel_index_name FOR ()-[r:KNOWS]-() ON (r.since) Lưu ý rằng tên chỉ mục cần phải là duy nhất

- Chỉ tạo một chỉ mục thuộc tính duy nhất nếu nó chưa tồn tại:

CREATE INDEX node_index_name IF NOT EXISTS FOR (n:Person) ON (n.surname)

Lưu ý rằng chỉ mục sẽ không được tạo nếu đã tồn tại một chỉ mục có cùng tên, cùng một lược đồ hoặc cả hai

- Tạo chỉ mục thuộc t nh đơn với indexProvider được chỉ định

CREATE BTREE INDEX index_with_provider FOR ()-[r:TYPE]-() ON