Báo cáo: Nghiên cứu và tìm hiểu về Neo4j

MỤC LỤC
I. Giới thiệu chung 4
II. Tìm hiểu về Neo4j 4
II.1. Đối tượng, mô hình lưu trữ, mô hình dữ liệu 4
II.1.1. Graph Database 4
II.1.2. Mô hình lưu trữ và tổ chức dữ liệu trên Neo4j.
6
II.2. Phương pháp, kĩ thuật xử lý truy vấn đồng thời. 10
II.2.1.Transaction Management 10
II.2.2. Interaction cycle 10
II.2.3. Isolation levels 11
II.2.4. Default locking behavior 11
II.2.5. Deadlocks 12
II.2.6. Delete semantics 12
II.2.7. Create Unique node 13
II.2.8. Transaction Event 13
II.3. Giao diện lập trình ứng dụng (API) và tính trong
suốt (transparency) với các ứng dụng ở mức cao 14
II.3.1. Giao diện lập trình ứng dụng (API) 14
1 | P a g e
II.3.2. Tính trong suốt với ứng dụng mức cao 25
II.4. Yêu cầu về môi trường hoạt động 26
II.4.1. Yêu cầu phần cứng 26
II.4.2. Yêu cầu phần mềm 27
II.4.3. Chi phí 27
II.5. Tính mở 29
II.6. Khả năng và giới hạn 29
II.6.1. Khả năng 29
II.7. Ưu nhược điểm 31
II.7.1. Ưu điểm 31
II.7.2. Nhược điểm 33

III. Chương trình mô phỏng thao tác với Neo4j trên ngôn
ngữ Java 36
III.1. Tương tác với cơ sở dữ liệu Neo4J 36
III.2. So sánh giữa cơ sở dữ liệu MySQL và cơ sở dữ
liệu Neo4J tương đương 37
IV. Khó khăn và kết quả đạt được 37
IV.1. Khó khăn 37
IV.2. Kết quả đạt được 37
2 | P a g e
3 | P a g e
NEO4J
I. Giới thiệu chung.
2001, Windh Technologies, công ty quản lý tài sản phương tiện truyền
thông, giám đốc công nghệ Peter với Emil, Johan dựng một giao diện đồ thị thích
hợp
2003, Neo4j đi vào 24/7 sản xuất
2006-2007, Neo4j được tách ra thành một dự án mã nguồn mở
2009, tài trợ hạt giống cho công ty
2010, Neo4j Server đã được tạo ra (trước đây chỉ có một DB nhúng)
2011, tài trợ hoàn toàn khởi động công nghệ Neo
II. Tìm hiểu về Neo4j.
II.1. Đối tượng, mô hình lưu trữ, mô hình dữ liệu.
II.1.1. Graph Database.
Cơ sở dữ liệu đồ thị (Graph Database) là kiểu dữ liệu có cấu trúc lưu trữ
chung nhất trong các kiểu cấu trúc lưu trữ cơ sở dữ liệu. Kiểu dữ liệu này có khả
năng mô phỏng cho tất cả các kiểu dữ liệu khác, nó giống như một kiểu mô hình
dữ liệu cơ sở để xây dựng lên các cơ sở dữ liệu phức tạp hơn.
Đối tượng lưu trữ của một cơ sở dữ liệu dạng đồ thị là một nút (node) trong
đó các node sẽ giống như một bản ghi dữ liệu chứa các thông tin về node.
Relationships là các quan hệ để liên kết các node với nhau, người dùng định

nghĩa các quan hệ này và hoàn toàn tự mình tổ chức để tạo ra một cấu trúc lưu trữ
riêng như tree, danh sách, bảng ma trận…
Ví dụ: node {id:1; name: node1; class: myNode} node này lưu các thông tin
gồm id, name, class của bản ghi này. Id, name, class là các thuộc tính của bản ghi
đó và cũng là key tương ứng với các value: {1,node1,myNode}.
4 | P a g e
Hình 1.1. Mô tả mô hình của một node dữ liệu.
5 | P a g e
II.1.2. Mô hình lưu trữ và tổ chức dữ liệu trên Neo4j.
Neo4j là cơ sở dữ liệu dạng đồ thị nên mô hình lưu trữ, cấu trúc lưu trữ và
đối tượng mang đặc điểm của cơ sở dữ liệu dạng đồ thị nói chung. Tức là Neo4j
lưu trữ dữ liệu trên các nút (node), xây dựng lên các cấu trúc dữ liệu khác nhau
bằng các relationships.
II.1.2.1.Node
Các đơn vị cơ bản đã hình thành một đồ thị là các nút và các mối quan
hệ. Trong Neo4j, cả nút và các mối quan hệ đều có thể chứa thuộc tính. Các
nút thường được sử dụng để đại diện cho các thực thể, nhưng tùy thuộc vào
mối quan hệ miền có thể được sử dụng cho mục đích đó là hợp lí.
Đây là cơ sở dữ liệu đồ thị đơn giản nhất với 1 nút
II.1.2.2. Quan hệ
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
6 | P a g e
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
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ị.
Mối quan hệ là như nhau khi đi qua một trong hai hướng. Điều này có
nghĩa rằng không có cần phải thêm các mối quan hệ trùng lặp theo hướng
ngược lại. Trong khi mối quan hệ luôn luôn có một hướng, bạn có thể bỏ qua

hướng nếu không sử dụng đến. Lưu ý rằng một nút có thể có mối quan hệ với
chính nó sau đây:
II.1.2.3. Thuộc tính
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[].
7 | P a g e
“null” không phải là giá trị thuộc tính hợp lệ. Null có thể được mô hình hóa
bởi một … (the absence of key).
 Nhận xét: Đây sẽ là một cơ sở dữ liệu hết sức mở đối với người dùng, mọi
cấu trúc lưu trữ sẽ phụ thuộc vào mục đích của người dùng, hướng tới người
dùng hơn.
II.1.2.4. Traversal
Traversal của một đồ thị nghĩa là duyệt qua các nút của nó, kế tiếp các mối
quan hệ theo một số quy tắc. Trong nhiều trường hợp chỉ là một đồ thị con được
truy cập, tìm thấy các nút và các mối quan hệ của nó.
8 | P a g e
II.1.2.5. Đường dẫn
Một đường dẫn là một hoặc nhiều nút với các mối quan hệ kết nối chúng,
thường lấy như một truy vấn.
Đây là đường dẫn ngắn nhất có chiều dài là 0:
Đường dẫn độ dài 1:

9 | P a g e
II.2. Phương pháp, kĩ thuật xử lý truy vấn đồng thời.
II.2.1.Transaction Management.
Để duy trì tính đầy đủ và toàn vẹn dữ liệu và đảm bảo hành vi transaction
tốt, Neo4j hỗ trợ thuộc tính ACID :
• Atomicity : bất kỳ một transaction nào không thành công trạng thái cơ sở
dữ liệu không thay đổi.

• Consistency (tính thống nhất): bất kỳ một transaction nào đều để lại một
cơ sở dữ liệu thống nhất.
• Isolation (tính đọc lập): trong một transaction, dữ liệu được sửa đổi
không thể được truy cập bởi các operator khác.
• Durability: DBMS luôn luôn có thể phục hồi một kết quả mà transaction
đã được commited.
Cụ thể là:
• Tất cả các sửa đổi dữ liệu phải được bọc trong một transaction.
• Mức độ tách biệt mặc định là: READ_COMMITTED
• Dữ liệu được lấy bằng phương pháp duyệt không được bảo vệ từ sửa đổi
bởi các transaction khác.
• Không lặp lại các lần đọc có thể xảy ra.(ví dụ: chỉ được ghi các lock và
giữ chúng cho đến khi kết thúc transaction).
• Có thể làm thủ công việc ghi các lock trên node và quan hệ ở mức độ
tách biệt cao hơn.
• Các lock được cài đặt ở mức độ Node và quan hệ.
• Phát hiện bế tắc được xây dựng trong quản lý transaction lõi.
II.2.2. Interaction cycle.
Tất cả các lệnh ghi làm việc với đồ thị phải được thực hiện trong 1
transaction. Transaction là 1 luồng giới hạn và được lồng vào nhau như “flat
nested transactions”. flat nested transaction có nghĩa là các nested transactions
được thêm phạm vi transaction cao nhất. Nested transactions có thể được đánh
10 | P a g e
giấu là transaction cấp cao cho việc rollback, có nghĩa là tất cả transaction sẽ được
rollback.
Chu kì thực hiện 1 transaction có chu kì như sau:
- Bắt đầu transaction.
- Thực hiện các hoạt động cơ sở dữ liệu
- Đánh dấu transaction thành công hoặc không thành công.
- Kết thúc transaction.

Transaction sẽ không giải phóng lock hay bộ nhớ cho đến khi nó được hoàn
thành. Transaction sẽ được commit hay rollback tùy thuộc vào trạng thái thành
công hoặc không thành công.
Tất cả các thay đổi của Transaction đều được lưu trong bộ nhớ. Điều này có
nghĩa là các cập nhập lớn sẽ được chia thành các transaction cấp cao để tránh tràn
bộ nhớ. Nó phải là transaction cấp cao nhất trước khi chia công việc thành các
nested transaction có thể thêm các công việc vào transaction cấp cao nhất.
II.2.3. Isolation levels.
Theo như mặc định một lệnh đọc sẽ đọ các giá trị được commit cuối cùng,
trừ khi một thay đổi bên trong transaction hiện tại là tồn tại. Mức độ cô lập mặc
định giống với READ_COMMITTED: Đọc không chặn hay thực thi các lock vậy
thì việc không lặp lại các lần đọc có thể xảy ra. Nó có thể đạt được mức độ tách
biệt cao hơn (REPETABLE_READ, SERIALIZABLE) bằng cách thủ công được
đọc và viết locks.
II.2.4. Default locking behavior.
Khi bổ xung, thay đổi, hay loại bỏ một giá trị trên node hoặc quan hệ một
ghi lock sẽ được thực trên các node, quan hệ cụ thể.
Khi xóa, tạo một node một ghi lock sẽ được thực thi cho một node, quan hệ
cụ thể.
Khi xóa, tạo 1 mối quan hệ một ghi lock sẽ được thực thi trên các quan hệ cụ
thể, và các nút của nó.
11 | P a g e
Các lock sẽ được thêm vào các transaction và được giải phóng khi
transaction kết thúc.
II.2.5. Deadlocks.
Khi các lock được sử dụng – bế tắc có thể xảy ra. Neo4j tự động phát hiện
các bế tắc trước khi chúng xảy ra và ném ra ngoại lệ. Trước khi ngoại lệ được ném,
các transaction được đánh dấu để rollbacks. Tất cả các locks sẽ được dữ bởi các
transactions nhưng được giải phóng khi chúng kết thúc.
Một khi các lock được giải phóng, các transaction đang đợi lock được giữ

bởi các transaction gây ra bế tắc: được tiến hành. Các transation gây ra bế tắc có
thể được dùng lại bởi người sử dụng nếu cần thiết.
Các bế tắc xảy ra thường xuyên là dấu hiệu của các yêu cầu ghi đồng thời
xảy ra cùng 1 lúc mà nó không thể thực hiện chúng trong 1 thời gian mà có thể
đảm bảo tính độc lập và thống nhất. Giải pháp là để đảm bảo đồng thời xảy ra 1
cách hợp lý. Ví dụ: cho 2 node cụ thể A, B thêm hoặc xóa quan hệ của 2 node này
1 cách ngẫu nhiên cho mỗi transaction có thể dẫn đến sự bế tăc khi có 2 hoặc nhiều
hơn transaction thực hiện chúng đồng thời. Một giải pháp là để cho cập nhập được
xảy ra theo 1 thứ tự đứng trước ( vd: A rồi B). Một giải pháp khác là để đảm bảo
cho mỗi luồng/transaction không có bất kì xung đột khi ghi vào node hay quan hệ
như một số giao dịch đồng thời khác. Một ví dụ có thể đạt được điều này : Cho
phép 1 luồng duy nhất làm cho tất cả các bản cập nhập có thể.
Bế tắc gây ra bởi: sự đồng bộ đồng bộ hóa khác với quản lý lock bởi
Neo4j: có thể xảy ra. Vì tất cả các hoạt động trong Neo4j API là luồng an toàn trừ
khi có quy định khác, không cần có sự đồng bộ hóa bên ngoài.Một số code đòi hỏi
sự đồng bộ phải được đồng bộ bởi 1 cách mà nó không được sử dụng các operator
của Neo4j trong khối đồng bộ.
II.2.6. Delete semantics.
Khi xóa 1 node, quan hệ thì tất cả các thuộc tính cho thực thể được sẽ được
xóa bỏ, nhưng các mối quan hệ giữa các node không bị xóa đi.
Neo4j có 1 ràng buộc là tất cả các mối quan hệ phải có node bắt đầu và node
kết thúc. Điều này cón nghĩa là, xóa 1 node mà có mối quan hệ gắn liền với nó sẽ
12 | P a g e
ném ra 1 ngoại lệ. Tuy nhiên, nó có thể lựa chọn thứ tự để xóa node và các mối
quan hệ kèm theo miễn là không có các mối quan hệ tồn tại khi thực hiện
transaction.
Tổng kết về delete semantics:
Tất cả các thuộc tính của 1 node, quan hệ sẽ được loại bỏ khi nó bị
loại bỏ.
Một nút được xóa không có các quan hệ kèm theo khi nó commit.

Có thể tham chiếu đến một mối quan hệ đã bị xóa hoặc hoặc nó chưa
được commit.
Bất kì 1 phương thức viết nào lên một quan hệ khi nó bị xóa sẽ ném ra
1 ngoại lệ.
II.2.7. Create Unique node.
Trong một số trường hợp, cần có sự độc nhất của thực thể. Ví dụ: chỉ có 1
người dùng với 1 email trong hệ thống, nếu nhiều luồng tạo ra các người dùng thì
các bản sao sẽ được tạo ra. Có 3 chiến lược chinh để tạo ra tính độc nhất, Tất cả
đều được thực thi trên HA(High Availability
và triển khai đơn. Chẳng hạn:
- Luồng đơn: Bằng cách sử dụng 1 luồng đơn , không có 2 luồng cùng tạo 1
thực thể đặc biệt cùng 1 lúc. Trên HA, một luồng đơn bên ngoài có thể thực
hiện các toán tử trên cụm.
- Get hoặc Create: Bằng cách sử dụng chức năng put-if-absent, thực thể duy
nhất có thể được đảm bảo sử dụg 1 index. Index hoạt động như lock và chỉ
khóa 1 phần nhỏ cần thiết đê đảm bảo tính độc nhất của transaction và
luồng.
- Pessimistic locking.
II.2.8. Transaction Event.
Transaction event có thể được đăng ký để nhận các sự kiện transaction.
Đăng ký tại GraphDatabaseService nó sẽ nhận được sự kiện xảy ra ở mỗi
13 | P a g e
transaction đã commit. Handler không lấy các thông báo về transaction đã không
thực hiện bất kì hoạt động ghi hay chưa commit (hoặc Transaction#success() được
không được gọi hoặc transaction được đánh giấu là thất bại Transaction#failure().
Trước khi Transaction được commit phương thức beforeCommit được gọi với toàn
bộ sự sai khác trong transaction). Tại thời điểm này các transaction đang chạy để
thay đổi vẫn có thể được thực hiện. Tuy nhiên không có gì đảm bảo rang các xử lý
khác sẽ thấy những thay đổi như vậy vì thứ tự xử lý là không xác định. Phương
thức này có thể ném 1 ngoại lệ, trong trường hợp này sẽ không cho các

Transaction được commit (rollback sẽ được áp dụng tiếp theo đó). Nếu
beforeCommit được thực hiện thành công các Transaction sẽ được thực hiện và
phương thức afterCommit sẽ được gọi cùng với 1 dữ liệu transaction như trước
giống như đối tượng được trả về bởi beforeCommit. Điều này đi với giả định là
các xử lý khác cũng được thực hiện beforeCommit thành công.
II.3. Giao diện lập trình ứng dụng (API) và tính trong suốt (transparency) với
các ứng dụng ở mức cao.
II.3.1. Giao diện lập trình ứng dụng (API).
Để tạo và sử dụng cũng như truy vấn cơ sở dữ liệu Neo4j thì các ứng dụng
phải sử dụng REST API để truyền tải dữ liệu bao gồm các truy vấn, các thiết lập
lên server.
REST API là API nhận các Http Request từ phía client và trả về Http
Response tương ứng dưới dạng tập tin json chứa dữ liệu cần thiết cho lần gọi của
client.
Điểm mạnh: Hầu hết REST API truyền qua client chỉ với luồng JSON, vì nó
giúp kết quả trả về nhanh hơn mà lại giảm chi phí bộ nhớ trên server.
Gọi API gốc để lấy về các đường dẫn đến các API chức năng, đây là API
quan trọng nhất cung cấp thông tin cho biết toàn bộ các API chức năng.
Ví dụ:
Với quan hệ sau trong CSDL:
14 | P a g e
Khi request lên CSDL sẽ nhận được:
Phía dưới là các API mức cao hơn sử dụng các REST API để tạo ra những
cách kết nối và thao tác với cơ sở dữ liệu Neo4j trực quan và phù hợp mục đích
người sử dụng.
A. Cypher API:
REST API cũng cho phép truy vấn với Cypher. Nghĩa là chúng ta sẽ có thể
gửi truy vấn lên trên server để nhận lại kết quả như ý. Giá trị trả về là một danh
sách các column, và 1 phần dữ liệu, bao gồm danh sách các hàng, mỗi hàng bao
gồm một danh sách các trường giá trị đại hiện cho REST đó: Node, Relationship,

path hoặc một vài giá trị đơn giản.
Lấy về thông tin 1 node thỏa mãn điều kiện sau “where”.
15 | P a g e
Ví dụ query sau:
Start x=node:node_auto_index(name={startName})
Match path=(x-[r]-friend)
Where friend.name={name}
Return type (r)
Ứng với bảng:
Request sẽ có dạng:
Response trả về:
16 | P a g e
Trả lại PATH của dữ liệu với câu lệnh truy vấn.
Ví dụ:
Start x=node(329)
Match path=(x friend)
Return path, friend.name
Request và response trả về:
17 | P a g e
Gọi truy vấn lồng nhau:
Khi gửi các truy vấn mà trả về kết quả lồng nhau như danh sách hay đồ thị,
chúng sẽ được trả về lồng nhau.
Ví dụ:
Truy vấn:
Start n = node(337,338)
Return connect(n.name)
Ngoài ra còn có các API cho phép tạo node, lấy dữ liệu node, xóa một node,
tạo quan hệ giữa các node.
B. Core java API.
18 | P a g e

Được khuyên nên dùng để tận dụng tối đa sức mạnh của neo4j, nó làm tăng
tốc độ xử lý của truy vấn lên rất nhiều, điều này đã được thử nghiệm thực thế.
Đây là 1 trong 3 cách để giao tiếp với neo4j cùng với traverser framwork
và cypher query language.
C. TraverseFramework.
Là 1 framework hỗ trợ việc giao tiếp với cơ sở dữ liệu Neo4j, về bản chất nó
vẫn xử dụng giao thức REST để lấy xử lý dữ liệu dưới dạng file json nhưng lại có
những ưu điểm khác biệt so với cypher language.
Traversals được tham chiếu từ một node trong csdl. Nó được điều kiển bằng
địa chỉ URI và body của request.
Các thành phần của traversal:
Returntype
Xác định kiểu giá trị trả về. Nó có thể thuộc các loại sau: node,
relationship,path, fullpath.
Order
Xác định kiểu thăm, duyệt các node. Có 2 dạng:
breadth_first: see Breadth-first search(BFS)
depth_first: see Depth-first search(DFS)
Relationships
Quyết định xem kiểu quan hệ nào được dùng. Nó có thể là 1 trong 3:in, out,
all.
Uniqueness(tính duy nhất)
Các kiểu được đưa ra trong bảng dưới đây:
NODE_GLOBAL
một Node global, không thể định nghĩa quá 1 lần.
19 | P a g e
NODE_LEVEL
các đối tượng trên cùng level được đảm bảo là duy nhất.
NODE_PATH
với mỗi node trả về có một path duy nhất từ node bắt đầu đến đó.

NODE_RECENT
giống với Node_GLOBAL. Nhưng chỉ đảm bảo tính duy nhất giữa các node
truy cập gần đây nhất (với một số cấu hình cụ thể)
NONE
không bị hạn chế và người dùng phải quản lý nó.
RELATIONSHIP_GLOBAL
relationship không thể được traverser quá 1 lần.
RELATIONSHIP_LEVEL
các thực thể trên cùng level được đảm bảo là duy nhất.
RELATIONSHIP_PATH
với mỗi node trả về có một path quan hệ duy nhất từ node bắt đầu tới nó.
RELATIONSHIP_RECENT
giống NODE_RECENT, nhưng cho relationships.
Prune_evaluator: Quyết định xem traserval có tiếp tục đi theo path đó hay
không, thường sử dụng: built-in none.
Return_filter: Quyết định xem vị trí hiện tại có cần được đóng gói vào
trong kết quả đầu ra hay không. Có thể tự code rule filter hoặc sử dụng 1
trong 2 tùy chọn: all, all_but_start_node.
20 | P a g e
Max_depth: quy định độ xâu tối đa để cắt lấy kết quả đầu ra (giống limit
trong mysql). nếu không cho thì mặc định sẽ là max_depth=1. Nhưng nếu
prune_evaluator được chỉ định thì sẽ không có giới hạn cho max_depth.
Ví dụ minh họa:
Ta có đồ thị quan hệ sau:
Request với phần thân là query của traversal:
21 | P a g e
Giải thích:
Order: truy vấn này sẽ duyệt đồ thị theo kiểu BFS nghĩa là duyệt đồ thị
theo chiều rộng.
Return_filter: truy vấn sẽ lọc và lấy các Node có thuộc tính Name chưa kí

tự t không phân biệt chữ hoa, chữ thường.
Prune_evaluator: yêu cầu là khoảng các từ Node bắt đầu tới Node đang
tham chiếu phải lớn hơn 10.
Uniqueness: sử dụng node_global.
Relationships: ví dụ này lấy theo cả 2 hướng với kiểu knows và loves.
Max_length: giới hạn số lượng trả về là 3(không kể Node bắt đầu).
Chú ý:
Đối tượng position sẽ trả về một path tham chiếu từ Node bắt đầu tới Node
đang xét. Đối tượng bắt đầu được nhìn thấy trong phần header của request,
nó có thể là Node, relationship hoặc path.
Ví dụ:
POST http://localhost:7474/db/data/node/215/traverse/relationship
POST http://localhost:7474/db/data/node/224/traverse/node
Creating a paged traverser:
22 | P a g e
Ví dụ:
Request dạng này sẽ tạo thêm 1 node với data =1, có relationship với tất cả
các node có type = Next. Chú ý paged traverser có thể thuộc 1 trong 3 loại: node,
path, fullpath.
Paging through the results of a paged traverser:
Paged traversers lưu trạng thái trên server, nó cho phép các client truy cập
tới page thông qua kết quả của traveral. Để truy cập tới page tiếp theo của kết quả
traversal trả về, client sẽ lấy URI của traversal này để phục vụ cho truy vấn đó.
Chú ý: nếu một traverser bị hết hạn nó sẽ báo lỗi 404 trong request GET tiếp
theo. Hết hạn ở đây có thể hiểu là giới hạn về thời gian của truy vấn để đạt được
kết quả mong đợi.
Paged traverser page size:
Mặc định là page có tối đa 50 đối tượng, nhưng có thể tùy chỉnh sau cho phù
hợp với ứng dụng và các page, ví dụ:
POST

http://localhost:7474/db/data/node/544/paged/traverse/node?pageSize=1
Paged traverser timeout:
Mặc định là 60s nhưng cũng có thể tùy chỉnh. Ví dụ:
POST
http://localhost:7474/db/data/node/577/paged/traverse/node?
leaseTime=10
23 | P a g e
Dưới đây là kết quả so sánh thực tế:
24 | P a g e
 Qua hai đồ thị khảo sát trên ta thấy rằng số query/s của Core java API luôn
là tối ưu nhất.
II.3.2. Tính trong suốt với ứng dụng mức cao.
Bằng việc sử dụng các API để thao tác xây dựng hay truy vấn cơ sở dữ liệu
một cách ngầm định mà người dùng không hề hay biết thì tính trong suốt với ứng
dụng mức cao hơn là đặc tính nổi bật của hầu hết các cơ sở dữ liệu lưu trữ trên
server.
- Với người dùng thao tác với cơ sở dữ liệu Neo4j thông qua giao diện
console, người dùng thao tác các lệnh truy vấn một cách tự nhiên như khi
thao tác trên mysql hay các cơ sở dữ liệu khác. Họ không hề nhìn thấy được
cũng như không cần biết rằng bên dưới lớp giao diện thao tác lệnh đó Neo4j
đóng gói các truy vấn thành các gói tin theo phương thức REST để trao đổi (
dữ liệu đóng gói dưới dạng các tập tin json ) và gửi đến server và nhận lại
reponese sau đó phân tích nó và trả lại dữ liệu cho người dùng (thông qua
RestAPI ).
25 | P a g e