NGHIÊN cứu về CHUYỂN đổi lược đồ cơ sở dữ LIỆU QUAN hệ SANG cơ sở dữ LIỆU NOSQL

Trong hơn 30 năm qua, hệ thống quản lý cơ sở dữ liệu quan hệ RDBMS được chạy trong trung tâm dữ liệu của mỗi công ty lưu trữ một lượng dữ liệu lớn trên thế giới.. Cơ sở dữ liệu quan hệ đ

ĐẠI HỌC QUỐC GIA TP.HCM

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN

PHẠM XUÂN BÌNH

NGHIÊN CỨU VỀ CHUYỂN ĐỔI LƯỢC ĐỒ CƠ SỞ

DỮ LIỆU QUAN HỆ SANG CƠ SỞ DỮ LIỆU NOSQL

KHÓA LUẬN THẠC SĨ

Ngành: Khoa học máy tính

Mã số: 68.48.01.01

TP HỒ CHÍ MINH – 2017

LỜI CẢM ƠN

Em xin cảm ơn thầy Nguyễn Đình Thuân đã giúp đỡ tạo điều kiện cho em hoàn thành khóa luận này Thầy đã tận tình hướng dẫn động viên và đưa ra những câu hỏi quý báu giúp em tìm hiểu và tiếp cận vấn đề tốt hơn

Em cũng gửi lời cám ơn đến quý Thầy Cô trường Đại học Công nghệ Thông tin – ĐH Quốc gia TP HCM đã cung cấp kiến thức và tạo điều kiện tốt nhất để em hoàn thành luận văn này

Bên cạnh đó, con cũng gửi lời cảm ơn đến ba mẹ và gia đình Mình cảm ơn các bạn trong nhóm happy đã động viên, giúp đỡ rất nhiều trong quá trình học tập cũng như trong cuộc sống

Xuân Bình

LỜI CAM ĐOAN

Tôi xin cam đoan đây là công trình nghiên cứu của tôi Các số liệu, kết quả nêu trong luận văn là trung thực và chưa từng được công bố ở công trình khác

Tôi xin cam đoan các thông tin trích dẫn trong khóa luận đã được ghi rõ nguồn gốc

Tp Hồ Chí Minh, ngày … tháng… năm 2017

Học viên thực hiện

Phạm Xuân Bình

LỜI CẢM ƠN………

Lời cam đoan………

MỤC LỤC……… 1

Danh mục các chữ viết tắt……… 3

Danh mục bảng………3

Danh mục hình, lược đồ……… 4

LỜI MỞ ĐẦU 5

CHƯƠNG 1 TỔNG QUAN 6

1.1 Tình hình chuyển đổi 6

1.2 Mục tiêu, nội dung, phương pháp nghiên cứu 6

CHƯƠNG 2 TÌM HIỂU NOSQL 8

2.1 Tìm hiểu MongoDB 8

2.1.1 Các khái niệm cơ bản trong MongoDB 8

2.1.2 Các thao tác cơ bản với MongoDB 14

2.1.3 Điểm nổi bật của MongoDB 19

2.2 Tìm hiểu Neo4j 21

2.2.1 Các khái niệm cơ bản trong Neo4J 21

2.2.2 Các thao tác cơ bản trong Neo4J 23

2.2.3 Điểm nổi bật của Neo4J 26

2.3 Một số cơ sở dữ liệu khác 26

2.3.1 Key Value Store 26

2.3.2 Wide Column Store 27

CHƯƠNG 3 CHUYỂN ĐỔI LƯỢC ĐỒ RDBMS SANG NOSQL 28

3.1 Chuyển đổi từ SQL sang MongoDB 28

3.1.1 Mô hình hóa lược đồ 28

3.1.2 Các bước chuyển đổi 28

3.2 Chuyển đổi từ SQL sang Neo4J 32

3.2.1 Mô hình hóa lược đồ 32

3.2.2 Các bước chuyển đổi 33

CHƯƠNG 4 CÀI ĐẶT VÀ ĐÁNH GIÁ 36

4.1 Tiến hành chuyển đổi lược đồ MongoDB 36

4.1.1 So sánh tốc độ truy vấn 37

4.1.2 Đánh giá 40

4.2 Tiến hành chuyển đổi sang Neo4J 41

4.2.1 Thực nghiệm một số câu truy vấn 44

4.2.2 Đánh giá 45

CHƯƠNG 5 KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN 46

TÀI LIỆU THAM KHẢO……….47

DANH MỤC CHỮ VIẾT TẮT

3 RDBMs Relational database management system (Hệ

quản trị cơ sở dữ liệu quan hệ)

4 SQL Structured Query Language (Ngôn ngữ truy vấn

DANH MỤC HÌNH, LƯỢC ĐỒ

trang

Hình 2.1: Hình minh họa có 2 bộ sưu tập students và courses……….…11

Hình 2.2: Sơ đồ của một truy vấn văn bản sử dụng một chỉ số………12

Hình 2.3: Sơ đồ sử dụng chỉ số để truy vấn và sắp xếp tăng dần của “score”……….13

Hình 2.4: Sơ đồ của truy vấn chỉ sử dụng chỉ số để truy vấn……… 14

Hình 2.5: Node và các quan hệ liên quan……… 22

Hình 2.6: Relationship và các quan hệ liên quan……… 22

Hình 2.7: Biểu diễn một property……… 23

Hình 2.8: Minh họa thao tác cập nhật Neo4J………25

Hình 3.1: Mô hình các bước chuyển đổi ……….29

Hình 3.2: Lược đồ quản lý dự án……… 29

Hình 3.3: Bộ trong Mongodb đại diện cho bảng tbDepartment……… 31

Hình 3.4: Bộ tbEmployee trong mongodb………31

Hình 3.5: Bộ tbAssignment trong Mongodb………32

Hình 3.6: Cơ sở dữ liệu đồ thị khi chưa có quan hệ………34

Hình 3.7: Cơ sở dữ liệu sau khi đã thêm các quan hệ……….35

Hình 4.1: Lược đồ Finance……… 36

Hình 4.2: Cấu trúc bộ FactFinance trong Mongodb………37

Hình 4.3: Giao diện chương trình chuyển đổi……….37

Hình 4.4: Giao điện demo test time……….38

Hình 4.5: Sơ đồ mối quan hệ thực thể của NorthWind………41

Hình 4.6: Mô hình dữ liệu đồ thị NorthWind……… 42

LỜI MỞ ĐẦU

Ngày nay, các ngành công nghiệp đang tìm cách thay đổi phương thức quản lý

và nơi lưu trữ dữ liệu của riêng công ty cũng như dữ liệu khách hàng cho phù hợp với

sự phát triển công nghệ hiện tại Trong hơn 30 năm qua, hệ thống quản lý cơ sở dữ liệu quan hệ (RDBMS) được chạy trong trung tâm dữ liệu của mỗi công ty lưu trữ một lượng dữ liệu lớn trên thế giới Để quản lý được lượng dữ liệu đó, các doanh nghiệp phải tốn nhiều chi phí cho phần cứng, phần mềm cũng như cho quản trị viên bảo trì và nâng cấp Điều này khó có thể tiếp tục Công nghệ RDBMS không đáp ứng được yêu cầu tốc độ, số lượng và sự đa dạng của nguồn dữ liệu trên thực tế nữa Để phục vụ lượng dữ liệu lớn (Big Data), cơ sở dữ liệu NoSQL được yêu cầu sử dụng

Cơ sở dữ liệu quan hệ được thiết kế cho những mô hình dữ liệu không quá lớn trong khi các dịch vụ mạng xã hội lại có một lượng lớn dữ liệu và cập nhật liên tục do

số lượng người dùng quá nhiều Do đó cơ sở dữ liệu NoSQL sinh ra với mục tiêu giải quyết các thiếu sót của RDBMS trong các hệ thống phần mềm hiện đại NoSQL sẽ tập trung giải quyết các vấn đề như tốc độ thực thi, khả năng lưu trữ, các nghiệp vụ phức tạp (phân trang, đánh chỉ mục …) Nhờ vậy giải pháp sử dụng cơ sở dữ liệu NoSQL sẽ

hạ thấp chi phí nếu so sánh với RDBMS truyền thống

Các doanh nghiệp CNTT đã sử dụng RDBMS từ lâu đời giờ muốn chuyển qua

cơ sở dữ liệu mở điện toán đám mây này cần phải có sự chuẩn bị kĩ lưỡng Ngày nay

đã có một số doanh nghiệp thành công khi chuyển từ cơ sở dữ liệu quan hệ sang cơ sở

dữ liệu NoSQL như Cisco, MTV NetWorks Phương pháp chuyển đổi cần được phổ biến và sử dụng rộng rãi Cách thức lưu trữ dữ liệu của RDBMS/SQL và NoSQL rất khác nhau Đề tài tìm hiểu NoSQL và đại diện là MongoDB là cơ sở dữ liệu phổ biến hiện nay Tìm hiểu cách thức chuyển đổi các dữ liệu RDBMS/SQL, lược đồ, chức năng, khóa chính, khóa ngoại sang các thành phần tương đương của MongoDB

CHƯƠNG 1 TỔNG QUAN

1.1 Tình hình chuyển đổi

Đã có nhiều doanh nghiệp chuyển cơ sở dữ liệu của họ từ SQL sang NoSQL Khi họ có yêu cầu về tốc độ hay giảm chi phí mở rộng phục vụ mục đính chính của mình Sau đây là một số trường hợp chuyển đổi

AOL tăng trưởng mạnh họ cần một cơ sở dữ liệu linh hoạt, dễ triển khai và không phải nỗ lực nhiều Hệ thống được chuyển đổi thông qua 4 giai đoạn để đảm bảo người dùng không bị ảnh hưởng trong quá trình thực thi Hai lần đọc ghi vào cả csdl

eBay cần truy vấn một chuyển phát nhanh tốt nhất trong thời gian ngắn, và một

cơ sở dữ liệu linh hoạt dễ mở rộng để phát triển nhanh Họ đã chọn Neo4J

Dù đã có nhiều công ty chuyển đổi thành công, cũng không ít người phải quay trở lại cơ sở dữ liệu quan hệ cũ Một số lý do như chi phí bỏ ra cao khi thực hiện hợp đồng với nhà quản lý cơ sở dữ liệu mới, tìm kiếm nhân lực thành thạo cơ sở dữ liệu mới và chi phí bảo trì 2 cơ sở dữ liệu quan hệ và nosql trong quá trình chuyển đổi để vận hành song song Việc chuyển đổi chỉ dựa vào trực giác và kinh nghiệm của người

sử dụng không có một chuẩn mực để thực hiện

1.2 Mục tiêu, nội dung, phương pháp nghiên cứu

Mục tiêu của đề tài là tìm hiểu, thiết kế và cài đặt một phương thức chuyển đổi lược đồ từ cơ sở dữ liệu quan hệ SQL Server sang MongoDB và Neo4J

Nội dung là tiến hành chuyển đổi một cơ sở dữ liệu quan hệ cụ thể từ SQL Server sang MongoDB và Neo4J Bỏ qua các ước tính về chi phí phạm vi chỉ tập trung

vào chuyển đổi lược đồ Từ đó rút ra được những tương đồng, điểm mạnh cũng như những hạn chế giữa hai cơ sở dữ liệu trước và sau chuyển đổi

Đầu tiên ta tìm hiểu qua về cơ sở dữ liệu MongoDB và Neo4J, là 2 cơ sở dữ liệu đại diện cho cơ sở dữ liệu tài liệu và cơ sở dữ liệu đồ thị Dựa vào những tài liệu, kinh nghiệm của những người đã chuyển đổi để xây dựng phương pháp chuyển đổi Tiếp theo ta lựa chọn cơ sở dữ liệu mở trên mạng để thực hiện chuyển đổi Từ kết quả thu được rút ra những bài học, những kinh nghiệm cho bản thân và để xuất hướng nghiên cứu tiếp cho đề tài

CHƯƠNG 2 TÌM HIỂU NOSQL

2.1 Tìm hiểu MongoDB

MongoDB là một cơ sở dữ liệu mã nguồn mở, nó có cơ chế hoạt động với hiệu suất cao, dễ dàng cấu hình, và dễ dàng mở rộng vì được xây dựng hoàn toàn trên ngôn ngữ C/C++ [1][2]

MongoDB không có các lược đồ quan hệ giống như hệ cơ sở dữ liệu quan hệ Đặc biệt, MongoDB là một “Cơ sở dữ liệu hướng tài liệu”

MongoDB quản lý các dữ liệu thành các tập dạng BSON (Binary JSON), BSON là kiểu dữ đã được mã hóa nhị phân của dạng dữ liệu JSON Các dữ liệu này có thể được lồng vào nhau, hình thành nên một cấu trúc phức tạp, nhưng vẫn dễ dàng truy suất được nhờ được đánh các chỉ mục Điều này cho phép dữ liệu được thiết kế tự nhiên và dễ dàng phù hợp cho ứng dụng

- Năm 2007, dự án MongoDB được thành lập bởi 10gen, tại New York, Mỹ

- Năm 2009, MongoDB đã chính thức trở thành mã nguồn mở

- Trong tháng 3 năm 2011, từ phiên bản 1.4, MongoDB đã được hoàn thiện phiên bản đầu tiên sẵn sàng cho các ứng dụng

- Tới tháng 4 năm 2017, phiên bản 3.4.4 là phiên bản mới nhất

2.1.1 Các khái niệm cơ bản trong MongoDB

2.1.1.1 Văn bản (Document)

MongoDB lưu trữ tất cả dữ liệu ở dạng văn bản, theo cấu trúc lưu trữ JSON có các trường và giá trị tương ứng

Nó được xem tương đương với một dòng dữ liệu trong cơ sở dữ liệu quan hệ

{“item”: “pencil”, “qty”: 500, “type”: “no.2”}

a) Định đạng văn bản (Document Format)

MongoDB lưu trữ các văn bản ở dạng BSON theo một cách tuần tự BSON là cách biễu diễn nhị phân của các cấu trúc JSON

b) Cấu trúc văn bản (Document Structure)

Văn bản MongoDB có cấu trúc bao gồm các trường (field) và các giá trị (value) tương ứng, theo cấu trúc sau:

{“greeting”: “Hello, world!”}

Văn bản trên gồm 1 trường là “greeting” với giá trị tương ứng là “Hello, world!”

Ví dụ:

{“greeting”: “Hello, world!”, “foo”: 3}

Các giá trị có thể ở bất cứ kiểu dữ liệu nào, có thể bao gồm các văn bản khác, dạng mảng, hoặc là các mảng văn bản

_id: đối tượng Objectid

Name: có một văn bản con gồm các trường là “first” và “last” cùng các giá trị tương ứng

Birth và death: giá trị có kiểu dữ liệu dạng Date

Contribs: giá trị có kiểu dữ liệu mảng của chuỗi

Views: giá trị có kiểu dữ liệu Long interger

c) Trường có một số quy luật phải được tuân thủ:

- Tên trường là một chuỗi ký tự

- Trường có nội dung “_id” được dành riêng cho các khóa chính của văn bản,

và cần được tuân thủ các điều kiện của khóa chính

- Trường không thể được bắt đầu bằng ký tự “$”

- Trường không thể chứa dấu chấm “.”

- Trường phải là một chuỗi kí tự khác rỗng “null”

- Trong một văn bản, không thể chứa các trường giống nhau, ví dụ trường hợp sau là không hợp lệ:

{“greeting”: “Hello, world!”, “greeting”: “Hello, MongoDB!”}

d) Trường khóa (_id) có một số ràng buộc sau

- Mặc định, MongoDB sẽ tự động tạo ra trường “_id” mỗi khi có một văn bản được tạo

- Trường khóa luôn luôn là trường đầu tiên của văn bản Nếu như hệ thống nhận một văn bản có trường “_id” không phải đứng đầu, thì hệ thống sẽ tự động chuyển trường “_id” lên đầu

Ví dụ các văn bản sau có thể được dùng để lưu trong một bộ sưu tập:

{“greeting”: “Hello, world!”}

{“foo”: 5}

Bộ sưu tập được xác định bởi tên của nó là một chuỗi UTF-8

Hình 2.1: Hình minh họa có 2 bộ sưu tập students và courses

Các văn bản student được nhúng văn bản address và văn bản score Trong đó, văn bản Score được tham chiếu đến Courses So sánh với lược đồ quan hệ: ta cần lưu Score vào bảng riêng và dùng khóa ngoài liên kết với Student

Chỉ số là cầu trúc đặc biệt dùng để lưu trữ một phần nhỏ dữ liệu của bộ sưu tập Chỉ số lưu trữ giá trị của một trường cụ thể hoặc được thiết lập, sắp xếp theo các giá trị của các trường

Cơ bản, chỉ số trong MongoDB tương tự như trong các hệ thống dữ liệu khác MongoDB định nghĩa các chỉ mục vào một bộ sưu tập cấp độ và hỗ trợ các trường hoặc các trường con trong văn bản trong bộ sưu tập dữ liệu MongoDB

Nếu các chỉ số được sử dụng một cách thích hợp trong truy vấn, MongoDB có thể dùng các chỉ số để giới hạn lại số lượng các văn bản cần được kiểm tra Trong một

số trường hợp, MongoDB có thể dùng dữ liệu từ các chỉ số để xác định văn bản nào phù hợp với lệnh truy vấn

Sơ đồ dưới đây minh họa một truy vấn chọn tài liệu sử dụng một chỉ số

Hình 2.2: Sơ đồ của một truy vấn văn bản sử dụng một chỉ số

MongoDB thu hẹp phạm vi tìm kiếm văn bản bằng các duyệt tất cả văn bản có giá trị score nhỏ hơn 30

• Sắp xếp kết quả

MongoDB có thể dùng các chỉ số để trả về các văn bản đã được sắp xếp bằng các chỉ mục một các trực tiếp mà không cần phải thêm một bước sắp xếp trung gian

Hình 2-3: Sơ đồ sử dụng chỉ số để truy vấn và sắp xếp tăng dần của “score”

MongoDB có thể dùng các chỉ số để duyệt theo thứ tự tăng dần hoặc giảm dần

và trả về kết quả đã được sắp xếp

▪ Tối ưu kết quả truy xuất

Khi câu truy vấn hợp lệ với yêu cầu một chỉ số cụ thể, MongoDB sẽ trả về trực tiếp kết quả tương ứng với chỉ số mà không cần phải duyệt hay ghi các văn bản vào bộ nhớ Điều này giúp cho hệ thống hoạt động hiệu quả hơn

Hình 2.4: Sơ đồ của truy vấn chỉ sử dụng chỉ số để truy vấn

MongoDB không cần phải kiểm tra dữ liệu bên ngoài của các chỉ số để thực hiện các truy vấn

2.1.2 Các thao tác cơ bản với MongoDB

2.1.2.1 Thao tác thêm văn bản

Phương thức thêm document vào trong collection là thao tác cơ bản trong MongoDB

Để thực hiện thêm, ta thực hiện theo cú pháp sau:

2.1.2.2 Thao tác xóa document, collection

Để xóa tất cả các document trong 1 collection

Ta sử dụng cú pháp sau để xóa:

[tên_CSDL].[tên_collection].remove(x);

Trong đó, x là tham số của nó là một document hay là một cú pháp được trả về

là document, thì phương thức sẽ xóa các document đó trong collection

Nếu x = {}: (Rỗng), thì collection sẽ xóa hết tất cả các document bên trong nó

Ví dụ:

db.mailing.remove({“opt-out”: true})Khi dữ liệu đã được xóa, sẽ không có cách nào để phục hồi lại dữ liệu đã bị xóa

X: là chuỗi các biểu thức xác định phương thức trả về document

Những document được xác định trả về phụ thuộc vào tham số của phương thức Nếu như x được để trống, thì nó sẽ trả về tất cả những gì có trong collection, mặc định của tham số x sẽ là {} (nghĩa là rỗng), ví dụ như:

> db.c.find({})

Hoặc

> db.c.find()

Hai cách biểu diễn phương thức find() trên hoàn toàn tương tự nhau, nó sẽ trả

về mọi thứ trong collection c

Khi muốn truy vấn dữ liệu với một giá trị cần tìm kiếm Ví dụ, khi cần tìm một Users có giá trị “age” là 27, chúng ta có thể điền điều kiện này vào trong tham số của câu truy vấn

> db.Users.find({“age”: 27})

Nếu như muốn truy vấn dựa trên một giá trị dạng chuỗi Ví dụ, tìm một Users

có trường “Username” với gía trị là “joe”, ta làm như sau:

> db.Users.find({“Username”: “joe”})

Nếu muốn truy vấn document dựa trên nhiều giá trị trên các trường khác nhau,

ta chỉ việc đặt các giá trị thành thứ tự các tham số của phương thức Ví dụ, ta cần tìm Users có trường “age” là 27 và “Username” là “joe”, ta làm như sau:

> db.Users.find({“Username”: “joe”, “age”: 27})

2.1.2.5 Làm việc với chỉ số (Index)

Để tăng tốc độ xử lý của các câu lệnh, người ta thường đánh thêm chỉ số index vào trong các trường, Tuy nhiên, với một dữ liệu lớn thì việc đánh chỉ số cáo cho document cho toàn bộ collection tốn khoảng vài phút

Giả sử ta câu lệnh cho 1 trường của document như sau:

Ví dụ, câu lệnh dưới đây không nhanh hơn với chỉ số Index được tạo phía trên

> db.people.find({“date”: date1}).sort({“date”: 1, “Username”: 1})

Với câu lệnh này, mặc dù trường “Username” đã sở hữu index, nhưng

“Username” lại nằm ở phương thức “sort” cùng với trường “date” nên index không phát huy được tác dụng của nó Đầu tiên, server cần phải duyệt tất cả các document có trong collection để tìm thấy điều kiện so khớp của “date” trong phương thức “find”, vì trường “date” không có Index, điều này sẽ được thực khi rất chậm nếu số lượng document trong collection lớn

Để giải quyết được tình trạng trên, chúng ta nên tạo nên những chỉ số index bao gồm tất cả các trường trong câu lệnh Trong trường hợp này, để tối ưu câu truy suất trên, chúng ta cần tạo index bao gồm cả “date” và “Username” như sau:

> db.ensureIndex({“date”: 1, “Username”: 1})

Các đối số truyền vào phương thức tạo index ensureIndex() cũng tương tự như đối số truyền vào phương thức sort(), giá trị của mỗi trường là 1 hoặc -1, tùy vào chiều tăng giảm của các giá trị trường mà thiết đặt, 1 là tăng dần, -1 là giảm dần

Nếu như chúng ta có nhiều hơn 1 trường thể đánh chỉ mục index, ta cần nghĩ đến thứ tư ưu tiên sắp xếp, ví dụ ta có 1 collection như sau:

{“_id”: , “Username”: “smith”, “age”: 48, “Users_id”: 0} {“_id”: , “Username”: “smith”, “age”: 30, “Users_id”: 1} {“_id”: , “Username”: “john”, “age”: 36, “Users_id”: 2} {“_id”: , “Username”: “john”, “age”: 18, “Users_id”: 3} {“_id”: , “Username”: “joe”, “age”: 36, “Users_id”: 4}

{“_id”: , “Username”: “john”, “age”: 7, “Users_id”: 5}

{“_id”: , “Username”: “simon”, “age”: 3, “Users_id”: 6} {“_id”: , “Username”: “joe”, “age”: 27, “Users_id”: 7}

{“_id”: , “Username”: “jacob”, “age”: 17, “Users_id”: 8} {“_id”: , “Username”: “sally”, “age”: 52, “Users_id”: 9} {“_id”: , “Username”: “simon”, “age”: 59, “Users_id”: 10}

Nếu ta thiết lập index với các thông số như sau {“Username”: 1, “age”: -1} MongoDB sẽ tổ chức lại cho chúng ta như sau:

{“_id”: , “Username”: “jacob”, “age”: 17, “Users_id”: 8}

{“_id”: , “Username”: “joe”, “age”: 36, “Users_id”: 4}

{“_id”: , “Username”: “joe”, “age”: 27, “Users_id”: 7}

{“_id”: , “Username”: “john”, “age”: 36, “Users_id”: 2}

{“_id”: , “Username”: “john”, “age”: 18, “Users_id”: 3}

{“_id”: , “Username”: “john”, “age”: 7, “Users_id”: 5}

{“_id”: , “Username”: “sally”, “age”: 52, “Users_id”: 9}

{“_id”: , “Username”: “simon”, “age”: 59, “Users_id”: 10}

{“_id”: , “Username”: “simon”, “age”: 3, “Users_id”: 6}

{“_id”: , “Username”: “smith”, “age”: 48, “Users_id”: 0}

{“_id”: , “Username”: “smith”, “age”: 30, “Users_id”: 1}

Trường “Username” được sắp xếp theo thứ tự alphabet tăng dần, nếu như có một nhóm tên trùng nhau, thì “age” sẽ được sắp xếp giảm dần Sự sắp xếp tăng dần hay giảm dần phụ thuộc vào thông số được thiết lập trong câu lệnh tạo Index

Chỉ số index cho 2 trường “Username” và “age” cũng làm cho câu lệnh của một trường “Username” nhanh hơn

Theo nguyên tắc, nếu chỉ số index có N trường, nó sẽ giúp cho các cậu lệnh truy vấn có các tiền tố của index chạy nhanh hơn Ví dụ, nếu như ta có chỉ số index có các trường {“a”: 1, “b”: 1, “c”: 1, , “z”: 1}, có cũng có chức năng như các index {“a”: 1}, {“a”: 1, “b”: 1}, {“a”: 1, “b”: 1, “c”: 1}, hoặc tương tự là tiền tố của index được tạo Nhưng các câu lệnh có các index có các trường không theo đúng thứ tự {“b”: 1}, {“a”: 1, “c”: 1}, hoặc tương tự sẽ không có tác dụng (không là tiền tố của index được tạo) Chỉ có các index là tiền tố của index được tạo mới có tác dụng

Nhược điểm của việc sử dụng index là sẽ phát sinh chi phí trong các trình insert, update, remove Điều này xảy ra là do database không chỉ thực hiện các câu lệnh trên mà còn phải thực hiện cập nhật lại index sau khi thực thi các câu lệnh trong collection

• Chỉ số index cho các document con

Chỉ số index có thể được tạo cho các trường của các document con, cách tạo cũng tương tự đối với những trường thông thường Ví dụ, nếu chúng ta muốn tìm những bình luận trong document blog theo ngày tháng, ta co thể tạo chỉ số index cho trường

“date” trong document con của document “comments”, ta thực hiện như sau:

> db.blog.ensureIndex({“comments.date”: 1})

Chỉ số index của trường trong document được xếp ngang hàng với index của doccument cha

o Khai báo tên cho Index

Với mỗi index trong document đều có những chuỗi ký tự “name” lưu tên, và những chuỗi ký tự không trùng nhau Nó được server dùng để xác định chính xác index cần

xử lý Theo mặc định, chỉ số index được sử dụng tên như sau:

keyname1_dir1_keyname2_dir2_ _keynameN_dirN

Trong đó keynameX là tên của trường và dirX là chiều chỉ số index của trường tương ứng (1 hoặc -1) Sẽ rất có sử dụng, tác với chỉ số index với chuỗi tên mặc định như vậy, vì thế, chúng ta có thể thiết đặt thông số này trong đối số của hàm ensureIndex như sau:

> db.foo.ensureIndex({“a”: 1, “b”: 1, “c”: 1, , “z”: 1}, {“name”: “alphabet”})

Với tên được người sử dụng đặt, sẽ dễ dàng thực thi hơn thông qua tên của Index do chính người dùng đặt

o Giá trị duy nhất (Unique Index)

Unique đảm bảo rằng với mỗi giá trị của trường được thêm, với mỗi document trong collection thì giá trị đó là duy nhất Ví dụ, nếu chúng ta muốn đảm bảo rằng, không có giá trị trùng lặp trong trường “Username” trong các documents trong collection

“people”, ta thực hiện tạo unique index như sau:

> db.people.ensureIndex({“Username”: 1}, {“unique”: true})

Theo mặc định, khi thêm 1 document, MongoDB kiểm tra chỉ cần câu lệnh hợp

lệ cú pháp, nó sẽ được thêm vào Tuy nhiên sau khi thêm unique index, trước mỗi khi thêm 1 document, MongoDB sẽ kiểm tra xem trên những giá trị trên unique index có

bị trùng lắp hay không, nếu có thì báo lỗi cho người sử dụng, điều này hoạt động tương tự với trường “_id” collection

o Index loại bỏ trùng lắp (Dropping Duplicate) Khi tạo index cho một collection đã tồn tại trước đó, có thể có những giá trị bị trùng lắp Nếu có bất kì trường trong unique index được tạo có giá trị bị trùng lắp, câu lệnh sẽ báo lỗi, khi đó, có thể bạn muốn loại bỏ đi tất cả các document có trường giá trị bị trùng lắp, việc làm này có thể được thực hiện một cách tự động Thông số

“dropDups” trong câu lệnh “ensureIndex” có thể giúp chúng ta làm việc này, nó sẽ giữ lại document đầu tiên hợp lý, sau đó, nó sẽ loại bỏ bất kỳ các document có giá trị trường bị trùng lắp trước đó:

> db.people.ensureIndex({“Username”: 1}, {“unique”: true, “dropDups”: true})

Cách này có thể gây thất thoát dữ liệu, vì vậy cần xem xét kỹ nếu xử lý trên các

- Không kết bảng (joins) và không có giao tác đa tài liệu (multi-document transactions) đem lại hiệu suất cao và dễ scaling

2.1.3.2 Hiệu năng cao

− Không kết bảng và embedding giúp đọc và ghi nhanh

− Indexing bao gồm cả indexing keys của các tài liệu con và mảng bên trong

- Cho phép tùy chọn streaming writes

2.2 Tìm hiểu Neo4j

Neo4j là một cơ sở dữ liệu đồ thị, dữ liệu được lưu trữ trong các node Quan hệ

là các cung của đồ thị Mỗi đỉnh hoặc cạnh có thể chứa 1 hay nhiều thuộc tính Cả đỉnh

và cạnh đều có tên Ngôn ngữ dùng để truy vấn là Cypher Neo4j một dự án mã nguồn

mở dùng trong cộng đồng GPL3, được hỗ trợ bởi công ty Neo Technology từ năm

2000

Đặc điểm của Neo4j:

− Biểu diễn mô hình dữ liệu hướng đồ thị một các trực quan

− Quản lý lưu trữ trên đĩa cứng, hoàn toàn tối ưu cho việc lưu trữ các cấu trúc đồ thị với hiệu năng lớn nhất và có khả năng mở rộng tối đa

− Neo4j có thể xử lý các đồ thị với hàng tỉ các node/ các mối quan hệ/ các thuộc tính trên 1 máy tính và có thể mở rộng ra trên nhiều máy khác

− Một framework duyệt mạnh mẽ với tốc độ duyệt trên các node cực nhanh trong không gian node Độ sâu của quá trình duyệt có thể lên đến 1000 mức và dưới tốc độ 1 giây

- Full transactional như một cơ sở dữ liệu thực sự, với đầy đủ các đặc tính ACID (Atomicity, Consistency, Isolation, Durability)

2.2.1 Các khái niệm cơ bản trong Neo4J

Hình 2-5 : Node và các quan hệ liên quan

Một đồ thị đơn giản chỉ chứa 1 node, và có thể chỉ chứa một thuộc tính

Ví dụ: đồ thị có 1 node có 1 thuộc tính tên là “name”, với giá trị là “Marko”

2.2.1.2 Relationships

Trong cơ sở dữ liệu đồ thị, các mối quan hệ giữa các node (relationships) là một phần khóa của cơ sở dữ liệu Chúng cho phép tìm kiếm các dữ liệu có liên quan với nhau Cũng giống như các node, các relationship cũng có tập các thuộc tính

Hình 2-6 : Relationship và các quan hệ liên quan

Một relationship kết nối 2 node với nhau, gồm node bắt đầu và node kết thúc Mỗi relationship có loại quan hệ “relationship type”, mỗi “relationship type” này được