Tiểu luận môn cơ sở dữ liệu nâng cao Cơ sở dữ liệu đồ thị Neo4j

Tuy nhiên, thuật ngữ này thường dùng trong công nghệ thông tin và nó thường được hiểu rõ hơn dưới dạng một tập hợp liên kết các dữ liệu, thường đủ lớn để lưu trên một thiết bị lưu trữ nh

LỜI MỞ ĐẦU

˜«˜

Dữ liệu đã ra đời rất lâu, ngay cả lúc ngành công nghệ thông tin chưa khai sinh

đã có khái niệm dữ liệu rồi Dữ liệu là tập hợp thông tin có cấu trúc Tuy nhiên, thuật ngữ này thường dùng trong công nghệ thông tin và nó thường được hiểu rõ hơn dưới dạng một tập hợp liên kết các dữ liệu, thường đủ lớn để lưu trên một thiết bị lưu trữ như đĩa hay băng Dữ liệu này được duy trì dưới dạng một tập hợp các tập tin trong hệ điều hành hay được lưu trữ trong các hệ quản trị cơ sở dữ liệu

Ngày nay, với lượng dữ liệu khổng lồ, việc cập nhật và truy xuất dữ liệu thường xuyên, đây là một thách thức không nhỏ đối với các hệ cở sở dữ liệu Quá trình tìm kiếm, phân tích cấu trúc dữ liệu của thông tin, các chuyên gia nghiên cứu cơ sở dữ liệu đã cho ra đời một hệ cơ sở dữ liệu mới mà thừa kế từ cơ sở dữ liệu quan hệ, cơ sở dữ liệu dạng key-value, cơ sở dữ liệu tài liệu, Column-Family,

đó là cấu trúc cơ sở dữ liệu đồ thị. Dữ liệu đồ thị là cách thức lưu trữ thông tin ở dạng đồ thị những nút và cạnh.Nút của đồ thị sẽ có quan hệ đối với những nút khác thông qua các cạnh của đồ thị Với cách thức lưu trữ này, việc quản lý dữ liệu trở nên mềm dẽo

và dễ dàng hơn ngay cả trong việc ứng dụng tri thức vào khối dữ liệu lưu trữ.

Tiểu luận này trình bày một mã nguồn mở mà lưu dữ liệu dưới dạng cấu trúc sở

dữ liệu đồ thị, đó là Neo4j và ngôn ngữ truy vấn đồ thị thông minh Cypher.

Tiểu luận gồm có 5 chương:

Chương 1 Neo4j là một cơ sở dữ liệu đồ thị: giới thiệu về Neo4j và so sánh neo4j với RDBMS, Key-Value, cơ sở dữ liệu tài liệu.

Chương 2 Cơ sở dữ liệu đồ thị Neo4j: đi vào chi tiết cơ sở dữ liệu được lưu trữ trên Neo4.

Chương 3.Framework Java API: Các khái niệm cơ bản để duyệt đồ thị bằng Java API.

Chương 4 Ví dụ về mồ hình đồ thị và duyệt đồ thị: Chương này có ta các ví dụ về đồ thị và truy vấn dữ liệu thông qua Java API và ngôn ngữ truy vấn đồ thị Cypher.

Chương 5 Ngôn ngữ truy vấn đồ thị Cyper: Chương này trình bày văn phạm trong Cypher, các qui định và cách truy vấn đồ thị băng Cypher.

Chương 6 Kết luận

Em xin chân thành cảm ơn PGS.TS Đỗ Phúc – Giảng viên môn học cơ sở dữ liệu nâng cao đã truyền đạt những kiến thức vô cùng quý báu, xin chân thành cám ơn ban cố vấn học tập và ban quản trị chương trình đào tạo thạc sĩ Công nghệ thông tin qua mạng của Đại Học Quốc Gia TPHCM đã tạo điều kiện về tài liệu tham khảo để em có thể hoàn thành môn học này.

Em xin chân thành cảm ơn

Nguyễn Thành Đệ

CHƯƠNG 1 NEO4J LÀ MỘT CƠ SỞ DỮ LIỆU ĐỒ THỊ

*Một cơ sở dữ liệu đồ thị : quản lý một → đồ thị và → cũng quản lý những mối quan

hệ → lập chỉ mục

Neo4j là một cơ sở dữ liệu mã nguồn mở Nó được thiết kế dựa trên cơ sở dữ liệu quan

hệ Tối ưu hóa bằng cấu trúc dữ liệu đồ thị thay vì là dữ liệu bảng Khi làm việc với Neo4j, cơ sở dữ liệu ứng dụng của bạn sẽ được biểu diễn bằng đồ thị, như đồ thị dưới đây:

Hình 1 Cở sở dữ liệu đồ thị

1.1 So sánh các mô hình cơ sở dữ liệu

Cơ sở dữ liệu đồ thị lưu trữ cấu trúc dữ liệu bằng nút ( node) và mối quan hệ(relationship) trong đồ thị Vậy làm thế nào để ta so sánh với các mô hình cơ sở dữ liệu khác? Bởi vì một đồ thị là một cấu trúc chung, sau đây là một vài so sánh với một vài mô hình cơ sở dữ liệu khác

1.1.1 Cơ sở đồ thị biến đổi thành RDBMS

Xóa bỏ cấu trúc ngăn xếp của bản tin trong cở sở dữ liệu quan hệ nhưng vẫn giữtất cả các quan hệ, và nó như một đồ thị gồm có cạnh(edges) và nút(node) RDBMS được sử dụng để tối ưu hóa dữ liệu tổng hợp, còn Neo4j được dùng để tối ưu hóa kết nối dữ liệu

Hình 2.1 RDBMS

Hình 2.2 Cơ sở dữ liệu đồ thị bằng RDBMS

1.1.2 Xây dựng một cơ sở dữ liệu đồ thị như một cách lưu trữ Key-Value

Mô hình Key-value là một mô hình rất tốt và phổ biến cho việc tìm kiếm những danh sách khóa hay giá trị Khi các giá trị được kết nối với nhau, bạn sẽ nhận được một

đồ thị Neo4j cho phép ta tạo cấu trúc dữ liệu đơn giản từ một cấu trúc phức tạp, dữ liệu được kết nối

Hình 2.3 Lưu trữ dạng Key-Value

Ghi chú: K* đại diện cho khóa(key) và V* đại diện cho giá trị(value) Một vài khóa cũng có thể trỏ đến những khóa khác như trỏ đến giá trị vậy.

Hình 2.4 Cơ sở dữ liệu đồ thị lưu dạng Key-value

1.1.3 Cơ sở dữ liệu đồ thị cũng có liên quan đến mô hình Column-Family

Cơ sở dữ liệu Column-Family(BigTable) là mô hình cái tiến của key-value, sử dụng từ “families” cho phép nhóm các dòng Việc lưu trữ trong đồ thị, gia

đình(families) trở thành phân cấp, và giữ mối quan hệ giữa các dữ liệu, dữ liệu trở nên tường mình

1.1.4 Điều hướng cơ sở dữ liệu đồ thị như một lưu trữ tài liệu

Cơ sở dữ liệu tài liệu chứa những phân cấp rõ ràng, mô hình dữ liệu đơn giản

mà có thể dễ dàng chuyển đổi như mô hình cây Dĩ nhiên đó là mô hình đồ thị Tham chiếu đến tài liệu khác(hoặc những phân tử trong tài liệu) như một cây và sẽ có nhiều

dữ liệu điện điện cho những dữ liệu tương tự nhau Khi dùng Neo4j, mối quan hệ đó sẽ

dễ dàng hơn

Hình 2.5 Lưu trữ dạng tài liệu

Ghi chú: D=tài liệu, S=tài liệu con,V=giá trị, D/S = tham chiếu đến tài liệu khác

Hình 2.6 Cơ sở dữ liệu đồ thị lưu trữ dạng tài liệu

CHƯƠNG 2 CƠ SỞ DỮ LIỆU ĐỒ THỊ NEO4J

Chương này sẽ nói rõ mô hình và cách thức hoạt động của Neo4j

2.1 Nút(Nodes)

Nền tản của mô hình đồ thị là nút(nodes) và các mối quan hệ(relationships) của chúng Trong Neo4j, cả hai nút và mối quan hệ của chúng có thể chưa thuộc tính của chúng

Nút thường được đại diện cho thực thể(entities), nhưng phục thuộc vào các mối quan

hệ cụ thể mà có thể được sử dụng với mục đích khác nhau

Hình 2.7 Nút

Chúng ta bắt đầu với một đồ thị đơn giản là chỉ có một nút

2.2 Mối quan hệ (Relationships)

Name: Marko

Mối quan hệ giữa các nút là một bộ phận khóa của cơ sở dữ liệu đồ thị Chúng cho phép ta tìm mối liên hệ của dữ liệu Cũng giống như nút, mối quan hệ có thể là thuộc tính của thực thể(entities)

Hình 2.8 Mối quan hệ của các nút

Một quan hệ kết nối 2 nút và đảm bảo phải có nút bắt đầu và nút kết thúc

Những mối quan hệ trực tiếp, chúng có thể được xem như là cung đi ra(outgoing) và cung đi vào(incoming) của nút Ví dụ xem hình sau:

Tất cả các mối liên hệ có một kiểu quan hệ(relationship type) Ví dụ sau đây cho thấy việc follow của một mạng xã hội đơn giản với hai kiểu quan hệ(relationship type)

Hình 2.9 Mối quan hệ có hướng và kiểu quan hệ

Sử dụng mối quan hệ có hướng và kiểu (type)

Ví dụ sau là một mô hình đơn giản của hệ thông tập tin:

Hình 2.10 Đồ thị và kiểu quan hệ

Để tìm kiếm file nào đó, chúng ta sử dụng mối quan hệ có hướng và kiểu của nút để duyệt

Lấy đường dẫn của tập tin Mối quan hệ tập tin đi vào

Lấy toàn bộ đường dẫn của tập tin Mối quan hệ tập tin và symbolic link đi

vàoLấy tất cả các tập tin trong một thư mục Mối quan hệ tập tin và symbolic link đi ra,

độ sâu 1Lấy tất cả các tập tin trong thư mục và

chạy liên kết

Mối quan hệ tập tin đi ra, độ sâu 1

Lấy tất cả các tập tin trong thư mục, đệ

qui

Mối quan hệ tập tin và symbolic link đi ra

2.3 Thuộc tính(properties)

Cả hai nút(nodes) và mối quan hệ(relationship) đều có thể có thuộc

tính(properties) Thuộc tính là khóa-giá trị mà khóa là chuỗi Giá trị thuộc tính có thể làgiá trị của một kiểu dữ liệu nào đó hoặc có thể làm mảng của một kiểu dữ liệu nào đó

Ví dụ giá trị string, int[] là giá trị hợp lệ của thuộc tính

Chú ý rằng NULL không là giá trị hợp lệ của giá trị thuộc tính Nulls có thể được thay thế là sự vắng mặt của khóa

Hình 2.11 Kiểu dữ liệu đồ thị

Bảng kiểu giá trị thuộc tính:

2147483647

-9223372036854775808 đến 9223372036854775807

floating-point number

floating-point number

2.4 Đường kết nối (Paths)

Một đường kết nối có thể qua nhiều nút với việc kết nối qua các mối quan hệ, thông thường là một truy vấn hay kết quả phép duyệt

Đường kết nối ngắn nhất có độ dài bằng 0, là độ thì có một nút Độ dài của đường dẫn:

Nút 1

Nút 2

Mối quan hệ 1

2.5 Duyệt đồ thị

Duyệt đồ thị có nghĩa là viến thăm các nút, những mối quan hệ theo một số luật.Hầu như các trường hợp chỉ là một đồ thị con được viến thăm Như bạn đã biết mối quan tâm lớn nhất của đồ thị là nút và mối quan hệ của nút

Neo4j cung cấp cho chúng ta API mà cho phép chúng ta duyệt đồ thị theo nhiều phép duyệt khác nhau Chúng ta có thể duyệt theo chiều rộng, duyệt theo chiều sâu

Neo4j cung cấp một framework Java API cho duyệt đồ thị, framework Java API này cóthể tham khảo ở địa chỉ www.neo4j.org Ngoài ra cũng có lựa chọn khác ở Neo4j cho phép duyệt đồ thị hoặc truy vấn đồ thị đó là Cypher và Grelin

CHƯƠNG 3 FRAMEWORK NEO4J ĐỂ DUYỆT ĐỒ THỊ

Gói Neo4j Traversal API cung cấp ở địa chỉ:

http://components.neo4j.org/neo4j/1.8.M07/apidocs/org/neo4j/graphdb/traversal/package-summary.html

3.1 Những khái niệm:

Sau đây là một số khái niệm:

- Expanders: Định nghĩa những gì sẽ duyệt, đặc biệt trong những mối quan hệ có hướng và kiểu

- Order: Ví dụ như duyệt chiều sâu-chiều rộng

- Uniqueness: Thăm nút (Mối quan hệ, đường kết nối) chỉ một lần

- Evaluator: Khi dừng hoặc tiếp tục duyệt đồ thị thì những gì sẽ được trả về

- Starting node: Nút bắt đầu duyệt

3.2 Duyệt bằng Framework Java API

Framework duyệt đồ thị bao gồm một vài màn hình chính như Nút đến các mối

quan hệ như: TraversalDescription, Evaluator, Traverser và Uniquenese Giao diện

paths cũng được hỗ trợ trong phép duyệt

CHƯƠNG 4 VÍ DỤ VỀ MÔ HÌNH ĐỒ THỊ VÀ DUYỆT ĐỒ THỊ

Chương này cung cấp cho chúng ta những ví dụ về việc sử dụng Neo4j để tạo nút, quan

hệ, và dùng các phép duyệt đồ thị

Chúng ta nên tham khảo chương sau để biết việc sử dụng truy vấn Cypher

4.1 Qui tắc user trong đồ thị

Đây là một đồ thị cho thấy qui tắc phân cấp Sự quan tâm về cây đồ thị thật sự có lưu trữ đủ cấu trúc dữ liệu này hay không, như nó có thể:

Hình 4.1 Ví dụ về cấu trúc dữ liệu đồ thị

Có thể xem chi tiết bài báo thảo luận về cách lưu trữ trực tiếp bằng đồ thị trong SQL dựa trên DBs, cách lưu trữ Store Procedured.tại địa chỉ:

Graphs-DAG-o

http://www.codeproject.com/Articles/22824/A-Model-to-Represent-Directed-Acyclic-DAGs là hầu như là cây, như với một phép xoay nó có thể tìm đến những nút giống nhau thông qua nhưng đường kết nối khác nhau Những cây giới hạn bởi khả năng này,

mà đảm bảo chúng xử lý dễ dàng hơn Trong trường hợp của chúng ta nó là “Ali” và

“Engin”, họ là admin và user như thật ra có thể truy cập thông qua những nút trong nhóm đó của họ

Trong bài báo giải pháp SQL Stored Procedured được cung cấp Ý chính đã có một vài

hỗ trợ từ các nhà khoa học, việc tính toán lại tất cả các đường kết nối Ưu nhược điểm của hướng tiếp cận này:

- Giảm hiệu năng cho việc đọc.

- Hiệu năng thấp khi thêm dữ liệu

- Quá nhiều không gian lãng phí

- Tin cậy vào Store procedured

Trong Neo4j có những qui tắt lưu trữ khá đơn giản Trong trường hợp này, chúng ta sử dụng mối quan hệ PART_OF(hình 4.1) đến các nhóm phân cấp và quan hệ

MEMBER_OF(hình 4.1) đến mô hình thành viên trong những nhóm Chúng ta cũng kết nối những nhóm mức độ cao nhất đến những nút tham chiếu bởi quan hệ ROOT Điều này giúp chúng ta có được sự phân chia hữu ích của đồ thị Neo4j không có những kiểu quan hệ(relationship type) được xác định trước, bạn có thể tự do tạo bất kỳ kiểu quan hệ và gán cho chúng bất kỳ ngữ nghĩa nếu bạn muốn

4.1.1 Lấy thông tin admins

Node admins = getNodeByName( "Admins" );

Traverser traverser = admins.traverse(

Kết quả xuất ra:

Found: Ali at depth: 0

Found: HelpDesk at depth: 0

Found: Engin at depth: 1

Found: Demet at depth: 1

Kết quả thu thập từ phép duyệt sử dụng đoạn mã này:

4.1.2 Lấy ra những thành viên nhóm của một user

Sử dụng phép duyệt của Framework Java API, cấu truy vấn giống như thế này:Node jale = getNodeByName( "Jale" );

traverser = jale.traverse(

Traverser.Order.DEPTH_FIRST,

StopEvaluator.END_OF_GRAPH,

ReturnableEvaluator.ALL_BUT_START_NODE,

RoleRels.MEMBER_OF, Direction.OUTGOING,

RoleRels.PART_OF, Direction.OUTGOING );

Và kết quả:

Found: ABCTechnicians at depth: 0

Found: Technicians at depth: 1

Found: Users at depth: 2

RoleRels.PART_OF, Direction.INCOMING );

Kết quả:

Found: Admins at depth: 0

Found: Users at depth: 0

Found: HelpDesk at depth: 1

Found: Managers at depth: 1

Found: Technicians at depth: 1

Found: ABCTechnicians at depth: 2

Relationship rel = currentPos.lastRelationshipTraversed();

return rel.isType( RoleRels.MEMBER_OF );

Found: Ali at depth: 1

Found: Engin at depth: 1

Found: Burcu at depth: 1

Found: Can at depth: 1

Found: Demet at depth: 2

Found: Gul at depth: 2

Found: Fuat at depth: 2

Found: Hakan at depth: 2

Found: Irmak at depth: 2

Found: Jale at depth: 3

Trong Cypher:

START refNode=node(16)

MATCH refNode<-[:ROOT]->root, user

p=root<-[PART_OF*0 ]-()<-[:MEMBER_OF]-RETURN user.name, min(length(p))

ORDER BY min(length(p)), user.name

Và kết quả:

4.2 Cấu trúc ACL trong đồ thị

Ví dụ này cho ta một cái nhìn tổng quát của hướng tiếp cận danh sách điều khiển truy cập(Access Control Lists) trong đồ thị và đơn giản hóa những câu truy vấn phức tạp.

4.2.1 Hướng tiếp cận tổng quát:

Trong nhiều kịch bản, một ứng dụng cần phải xử lý bảo mật trên một vài hình thức của đối tượng quản lý Ví dụ này mô tả một mẫu để xử lý điều này thông qua việc

sử dụng cấu trúc đồ thị và phép duyệt đồ thị mà xây dựng một cơ cấu cấp phép đầy đủ cho bất kỳ một đối tượng quản lý với khả năng ghi đè hoặc loại trừ chúng Chức năng này được xây dựng động của ACLs dựa trên vị trí và ngữ cảnh của đối tượng

Kết quả là một mô hình an ninh phức tạp mà có thể dễ dàng được cài trong cấu trúc đồ thị Hỗ trợ chỉnh sửa cấp phép Thành phần nội dung và dữ liệu, đảm bảo dữ liệu khôngtrùng bất kỳ nơi nào

Hình 4.2 Ví dụ về ACL

Kỹ thuật

- Như đã thấy trong ví dụ trên: Có một vài khái niệm khóa trong mô hình này

- Quản lý nội dung(tập tin, thư mục) được kết nối bằng mối quan hệ

- Mối quan hệ Security : Việc kết nối cấu trúc hỗn hợp nội dung với cấu trúc hỗn hợp principals, chứa thuộc tính thêm/xóa(“+RW”)

Xây dựng ACLs

Tính toán các quyền có hiệu lực(ví dụ: đọc,ghi,thực thi)cho một principal để đưa ra bất

kỳ nút quản lý ALC(nội dung) cho phép một số qui tắc thành viên mà có thể được mã hóa vào trong quyền duyệt :

2. Bắt đầu với một danh sách hiệu quả bảo mật “được phép” được mã hóa là 111 hoặc nếu không đảm bảo kbaor mật thì sẽ được mã hóa là 000(mọi thứ sẽ cấm nếu như nó không tường minh)

3 Bắt đầu với nút content trên cùng, tìm kiếm bất kỳ mối quan hệ SECURITY trênnó

4. Nếu tìm thấy, nếu câu hỏi principal là một bộ phận của mối quan hệ

2 Có hai mối quan hệ SECURITY đến folder đó User 1 chứa hai mối quan hệ

đó, nhưng “root” mang tính chất chung hơn, vì thế nó cấp quyền “All

principals” +W +R ->11

3 “Home” không có mối quan hệ SECURITY, và tiếp tục

4 “user1 Home” có quan hệ SECURITY, đầu tiên cấp quyền "Regular Users" (-R -W) → 00, sau đó "user 1" (+R +W) → 11

5 Nút mục tiêu là "My File.pdf" không có quan hệ SECURITY Vì thế cấp quyền cho “user 1” trên “My File.pdf” là ReadWrite->11

4.2.2 Ví dụ quyền đọc

Trong ví dụ này, chúng ta sẽ kiểm tra một cấu trúc cây directories và files Có những file của users tạo và có những qui tắc mà users có thể được gán Những qui tắc

có thể là quyền truy cập đến directories hoặc files (và ở đây mô hình của chúng ta là cóthể đọc ).

Tìm tất cả các files trong directories

Lệnh để tìm các files chứa trong cấu trúc directories này, chúng ta cần có một biến

để chứa tất cả mối quan hệ và thông tin nút đến nút lá

START root=node:node_auto_index(name = 'FileRoot')

MATCH root-[:contains*0 ]->(parentDir)-[:leaf]->file

RETURN file

Và kết quả:

Những files gì được sở hữu bởi ai?

Nếu chúng ta có khái niệm về quyền sở hữu files Chúng ta có thể yêu cầu người

ta files thêm vào nút files thông qua mối quan hệ “owns”

START root=node:node_auto_index(name = 'FileRoot')

MATCH root-[:contains*0 ]->()-[:leaf]->file<-[:owns]-user

RETURN file, user

Kết quả truy vấn sẽ trả về tất cả users tạo files dưới nút FileRoot:

Ai có quyền truy cập file?

Nếu chúng ta muốn kiểm tra user nào có quyền đọc tất cả các files, và định nghĩa ACL của chúng ta như sau:

- Thư mục root không có quyền truy cập

- Bất kỳ user nào có một qui tắc mà cũng được cấp quyền truy cập có thể

đọc(canRead) đến file của thư mục cha có quyền đọc

Lệnh để tìm những users mà có quyền đọc những files bất kỳ trên thư mục cha trong Cypher như sau:

START file=node:node_auto_index('name:File*')

MATCH file<-[:leaf]-()<-[:contains*0 ]-dir<-[?:canRead]-role-[:member]->readUserRETURN file.name, dir.name, role.name, readUser.name

Và đây là kết quả

Và tạo những mối quan hệ trong nút mới đó:

Query

START root=node:node_auto_index(name = "ROOT")

MATCH root-[:LINK*0 ]->before,// before could be same as root

after-[:LINK*0 ]->root, // after could be same as root

before-[old:LINK]->after

WHERE before.value? < 25 // This is the value, which would normally

AND 25 < after.value? // be supplied through a parameter