Nghiên cứu về chuyển đổi lược đồ cơ sở dữ liệu quan hệ sang cơ sở dữ liệu NOSQL

TÌM HIỂU NOSQL

Lý do chọn NoSQL

Hiện nay, sự phát triển mạnh mẽ của Big Data, Big Users và Cloud Computing đã thúc đẩy sự ra đời của công nghệ NoSQL như một giải pháp tất yếu NoSQL ngày càng được coi là sự bổ sung cho hệ quản trị cơ sở dữ liệu quan hệ (RDBMs), khi mà RDBMs hiện tại gặp nhiều hạn chế như khó khăn trong việc đánh chỉ mục lượng dữ liệu lớn, phân trang và phân phối luồng dữ liệu media Ngoài ra, RDBMs cũng gặp khó khăn trong việc xử lý khối lượng dữ liệu khổng lồ và cập nhật liên tục do lượng người dùng đông đảo, dẫn đến vấn đề hiệu suất trong các bài toán lớn về hệ thống thông tin, phân tán và lưu trữ dữ liệu.

Chi phí triển khai và phát triển ứng dụng sử dụng cơ sở dữ liệu quan hệ thường cao, đặc biệt khi thực hiện truy vấn trên lượng bản ghi lớn trong thời gian dài Hơn nữa, sự phát triển nhanh chóng của các thiết bị cầm tay như smartphone đã làm lộ rõ những hạn chế của cơ sở dữ liệu quan hệ, do bộ nhớ và khả năng xử lý của các thiết bị này thường thấp.

1.1.2 Đặc điểm nổi bật của NoSQL

 Khả năng mở rộng (Scalability): gần như không có giới hạn cho dữ liệu và người dùng hệ thống

Tính sẵn sàng cao (High Availability) đảm bảo rằng hệ thống vẫn hoạt động ổn định ngay cả khi một node gặp sự cố, nhờ vào việc chấp nhận sự trùng lặp trong lưu trữ dữ liệu Điều này giúp ngăn chặn ảnh hưởng tiêu cực đến toàn bộ hệ thống khi một phần của nó bị lỗi.

 Tính nguyên tố (Atomicity): Độc lập trạng thái dữ liệu trong các thao tác

Tính nhất quán (Consistency) là yếu tố quan trọng trong quản lý dữ liệu, nơi sự chấp nhận về tính nhất quán yếu có thể dẫn đến việc cập nhật không đảm bảo rằng các truy xuất sau này phản ánh sự thay đổi Tuy nhiên, sau một thời gian lan truyền, tính nhất quán cuối cùng của dữ liệu mới sẽ được đảm bảo, đảm bảo rằng thông tin luôn chính xác và đáng tin cậy.

 Tính bền vững (Durability): Dữ liệu có thể tồn tại trong bộ nhớ máy tính, nhưng cũng đồng thời được lưu trữ tại đĩa cứng

Hệ thống triển khai linh hoạt cho phép tự động nhận diện việc thêm hoặc loại bỏ các node mà không cần cấu hình phần cứng đồng nhất và mạnh mẽ.

 Mô hình hóa linh hoạt (Modeling flexibility): cặp dữ liệu key-value, dữ liệu cấu trúc (Hierarchical data), Graphs

 Truy vấn linh hoạt (Query Flexibility): Multi-Gets, load một tập giá trị dựa vào tập khóa (Range queries)

Khả năng mở rộng theo chiều ngang (Horizontal scalable) là một ưu điểm nổi bật của hệ thống NoSQL, cho phép bổ sung thêm máy chủ để tăng cường khả năng lưu trữ mà không cần nâng cấp máy chủ hiện tại Trong khi đó, các hệ quản trị cơ sở dữ liệu quan hệ thường yêu cầu nâng cấp máy chủ khi dữ liệu trở nên quá lớn Điều này giúp NoSQL hỗ trợ lưu trữ phân tán trên nhiều máy, mang lại hiệu quả cao hơn trong việc quản lý dữ liệu lớn.

So sánh NoSQL và RDBMs

Cả NoSQL và RDBMS đều là những công nghệ xuất sắc, mỗi loại phù hợp với những lĩnh vực khác nhau Việc sử dụng linh hoạt cả hai công nghệ này sẽ tối ưu hóa lợi ích mà chúng mang lại.

1.2.1 Mặt tích cực của RDBMs

 RDBMs được hỗ trợ tốt với tính ACID đặc trưng

Tính nguyên tố (Atomicity) trong giao dịch đảm bảo rằng tất cả các thao tác phải được thực hiện hoàn toàn hoặc không có thao tác nào được thực hiện Ví dụ, trong trường hợp chuyển tiền, giao dịch có thể gặp sự cố, nhưng tính nguyên tố sẽ bảo vệ tài khoản khỏi việc bị trừ tiền nếu tài khoản nhận chưa được cộng số tiền tương ứng.

Tính nhất quán trong giao dịch đảm bảo rằng dữ liệu luôn ở trạng thái hợp lệ Khi một giao dịch được thực hiện, nó sẽ tạo ra một trạng thái mới cho dữ liệu; ngược lại, nếu có lỗi xảy ra, toàn bộ dữ liệu sẽ được khôi phục về trạng thái trước khi giao dịch được thực hiện.

 Tính tách biệt (Isolation) Một giao dịch đang thực thi và chưa được xác nhận phải bảo đảm tách biệt khỏi các giao dịch khác

Tính bền vững của dữ liệu là yếu tố quan trọng, đảm bảo rằng thông tin được xác nhận sẽ được lưu trữ một cách an toàn Ngay cả khi xảy ra hỏng hóc hoặc lỗi hệ thống, dữ liệu vẫn được giữ nguyên trong trạng thái chính xác, giúp duy trì tính toàn vẹn và độ tin cậy của thông tin.

 Xử lý dễ dàng với độ chính xác cao trong việc giải quyết những thao tác lớn

1.2.2 Mặt tích cực của NoSQL

NoSQL mang lại hiệu suất hoạt động cao, cho phép lưu trữ một lượng lớn dữ liệu để đáp ứng nhu cầu ngày càng tăng Để đạt được điều này, NoSQL cần loại bỏ một số yếu tố như ràng buộc dữ liệu của mô hình quan hệ, tính nhất quán dữ liệu và ngôn ngữ truy vấn SQL Bên cạnh đó, các cải tiến như sử dụng chỉ mục hiệu quả và khả năng phân tán dễ dàng đã góp phần nâng cao hiệu suất hoạt động của NoSQL.

Phân trang trong cơ sở dữ liệu quan hệ gặp nhiều khó khăn do thiếu phương pháp chính thống, buộc lập trình viên phải áp dụng nhiều kỹ thuật khác nhau để lấy đúng số lượng mục cần thiết Ngược lại, NoSQL hỗ trợ phân trang hiệu quả và duy trì hiệu suất ổn định.

NoSQL là một giải pháp nguồn mở, mang lại nhiều lợi ích cho các nhà phát triển, trong đó việc sử dụng miễn phí là một điểm mạnh lớn Ngoài ra, phần mềm nguồn mở thường đáng tin cậy hơn, an toàn hơn và dễ triển khai hơn so với các lựa chọn độc quyền Ví dụ, các hệ quản trị cơ sở dữ liệu NoSQL cho thấy rõ ràng những ưu điểm này.

NoSQL: Cassandra, CouchDB, Hbase, RavenDB, MongoDB và Redis

NoSQL mang đến sự linh hoạt trong việc mở rộng phạm vi cho các nhà quản trị cơ sở dữ liệu Thay vì phải đầu tư vào các máy chủ lớn hơn để xử lý khối lượng dữ liệu tăng lên, NoSQL cho phép các công ty phân tán tải dữ liệu qua nhiều máy chủ, giúp tối ưu hóa hiệu suất và khả năng mở rộng khi nhu cầu gia tăng.

1.2.3 Các loại NOSQL phổ biến

 RavenDB: được viết trên C# bởi Hibernating Rhinos với giấy phép GNU

RavenDB là giải pháp NoSQL chạy trên nền tảng NET, được thiết kế theo kiến trúc client-server Trong hệ thống này, dữ liệu được lưu trữ trên một máy chủ, và các yêu cầu truy cập dữ liệu được gửi từ nhiều máy người dùng khác nhau tới máy chủ đó.

Hadoop là một framework mã nguồn mở được phát triển bằng Java, cho phép xây dựng các ứng dụng phân tán xử lý dữ liệu lớn một cách miễn phí Nó hỗ trợ xử lý hàng ngàn node và lưu trữ hàng petabyte dữ liệu Hadoop được phát triển dựa trên các khái niệm từ mô hình MapReduce và hệ thống file phân tán Google File System (GFS) của Google.

 Cassandra: là một hệ quản trị cơ sở dữ liệu nguồn mở, được viết bằng

Java nhằm mục tiêu trở thành "Best of BigTable", trong khi Cassandra được thiết kế để xử lý khối lượng dữ liệu khổng lồ trải rộng trên nhiều máy chủ, đảm bảo tính sẵn sàng cao và độ tin cậy Đây là giải pháp NoSQL ban đầu được phát triển bởi Facebook.

MongoDB là một cơ sở dữ liệu NoSQL mã nguồn mở, hiệu suất cao và có khả năng mở rộng tốt, được phát triển bằng ngôn ngữ C++ Nó sử dụng phương thức lưu trữ BSON (một dạng JSON đã biên dịch) và tuân theo giấy phép AGPL Khác với các cơ sở dữ liệu truyền thống lưu trữ dữ liệu trong các bảng, MongoDB lưu trữ cấu trúc dữ liệu dưới dạng văn bản JSON với mô hình động, giúp việc tích hợp dữ liệu cho các ứng dụng trở nên dễ dàng và nhanh chóng hơn Mục tiêu của MongoDB là kết hợp những ưu điểm của mô hình key-value (nhanh chóng và dễ mở rộng) với mô hình dữ liệu quan hệ.

MongoDB là lựa chọn lý tưởng cho các nhu cầu truy vấn động, cho phép định nghĩa chỉ mục mà không cần sử dụng các hàm map/reduce Đặc biệt, nếu bạn cần tốc độ nhanh cho một cơ sở dữ liệu lớn, MongoDB nổi bật với khả năng đọc và ghi dữ liệu cực kỳ nhanh chóng.

CouchDB là một cơ sở dữ liệu bền vững, được phát triển bằng ngôn ngữ Erlang với khả năng chịu lỗi cao và dễ sử dụng Nó sử dụng định dạng lưu trữ JSON và được cấp phép theo giấy phép Apache 2.0 Mỗi cơ sở dữ liệu trong CouchDB được tổ chức thành các văn bản riêng biệt, với thông tin về phiên bản được lưu trữ trong từng văn bản, giúp dễ dàng đồng bộ dữ liệu khi có sự gián đoạn kết nối giữa các thiết bị.

1.2.4 Sự khác nhau giữa RDBMs và NoSQL

Cấu trúc Cấu trúc dựa trên các bảng

Cấu trúc phân làm 4 loại chính:

Lược đồ được định nghĩa để lưu trữ dữ liệu có cấu trúc

Không có một định nghĩa trước nào cho lược đồ, mà lược đồ linh hoạt dựa theo thành phần dữ liệu

Khả năng mở rộng của cơ sở dữ liệu quan hệ thường bị hạn chế do yêu cầu nâng cấp phần cứng khi muốn mở rộng theo chiều dọc Điều này dẫn đến khó khăn trong việc mở rộng quy mô hiệu quả.

Ưu nhược điểm khi chuyển từ RDBMs sang NoSQL

Với những ưu điểm của MongoDB được xem là những nhược điểm của các RDBMs:

 Cải thiện tốc độ xử lý dữ liệu lên nhiều lần

 Tập trung vào các truy vấn có tần suất sử dụng cao giúp nâng cao hiệu suất

 Mỗi dữ liệu được lưu thể hiện được sự trực quan

 Khả năng mở rộng dữ liệu theo chiều ngang cao

 Khả năng làm việc trực tiếp với Javascript

 Dữ liệu trở nên linh hoạt nhờ cấu trúc linh hoạt JSON

Dù có những ưu điểm khác nổi trội, tuy nhiên, việc chuyển đổi từ RDBMs sang NoSQL cũng gặp những mặt hạn chế sau:

 Không đảm bảo toàn vẹn dữ liệu (các tính chất ACID của dữ liệu RDBMs)

 Không có các ràng buộc khóa, tham chiếu giữa các thực thể

 Không hỗ trợ view,transaction, procedure, trigger…

 Không hỗ trợ xử lý song song các truy vấn trên cùng một thể hiện

 Đang trong quá trình phát triển và còn mới mẻ nên tính ổn định kém hơn các RDBMS

Các trường hợp nên sử dụng mô hình NoSQL

NoSQL không phù hợp cho các hệ thống yêu cầu tính toàn vẹn dữ liệu cao như ngân hàng, chứng khoán và giao dịch thương mại điện tử, vì nó không đảm bảo tính toàn vẹn của dữ liệu.

Ngược lại, trong các trường hợp mà tốc độ xử lý được ưu tiên, như quản lý nội dung trên mạng xã hội và thông tin sản phẩm, việc tối ưu hóa hiệu suất là rất quan trọng.

… thì NoSQL sẽ là lựa chọn hàng đầu

Để đạt hiệu quả tối ưu, việc lựa chọn giữa RDBMS và NoSQL hoặc kết hợp cả hai phụ thuộc vào từng ứng dụng cụ thể.

TÌM HIỂU MONGODB

Tóm tắt lịch sử

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

 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 9 năm 2014, phiên bản 2.6.6 (12/9/2014) là phiên bản mới nhất.

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

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”}

2.2.1.1.Đị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

2.2.1.2.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:

{ field1: value1, field2: value2, field3: value3,

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

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 varmydoc={

_id: ObjectId(“5099803df3f4948bd2f98391”), name: {first: “Alan”,last: “Turing”}, birth: newDate(“Jun 23, 1912”), death: newDate(“Jun 07, 1954”), contribs: [“Turing machine”,“Turing test”,“Turingery”], views: NumberLong(1250000)

Ví dụ văn bản trên có:

Đối tượng có ID là ObjectId, bao gồm một trường văn bản con với các trường "first" và "last" cùng với giá trị tương ứng Các trường "birth" và "death" có kiểu dữ liệu là 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

2.2.1.3.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!”}

2.2.1.4.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 "_id" luôn là trường đầu tiên trong văn bản Nếu hệ thống nhận một văn bản mà trường "_id" không đứng đầu, nó sẽ tự động điều chỉnh để đưa trường "_id" lên vị trí đầu tiên.

Bộ sưu tập là tập hợp các văn bản, tương tự như các dòng dữ liệu trong bảng của cơ sở dữ liệu quan hệ.

Một bộ sưu tập được định nghĩa là Schema-Free, có nghĩa là các văn bản trong bộ sưu tập cần phải có cấu trúc tương đồng để có thể được lưu trữ cùng nhau.

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

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 ộ u tập tu nt và cour

Các văn bản sinh viên chứa thông tin về địa chỉ và điểm số Trong đó, điểm số được liên kết với các khóa học Để so sánh với lược đồ quan hệ, cần lưu điểm số vào bảng riêng và sử dụng khóa ngoại để liên kết với bảng sinh viên.

Chỉ mục trong MongoDB giúp tối ưu hóa hiệu suất truy vấn Nếu không có chỉ mục, MongoDB sẽ phải quét toàn bộ tài liệu để tìm ra các văn bản phù hợp với lệnh truy vấn, dẫn đến hiệu suất kém do xử lý một lượng dữ liệu lớn không cần thiết.

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

Chỉ số trong MongoDB tương tự như trong các hệ thống dữ liệu khác, với việc MongoDB định nghĩa các chỉ mục ở cấp độ bộ sưu tập Nó hỗ trợ các trường và trường con trong văn bản trong bộ sưu tập dữ liệu của mình.

Khi được sử dụng đúng cách, các chỉ số trong MongoDB có thể giúp giảm số lượng văn bản cần kiểm tra trong truy vấn Trong nhiều trường hợp, MongoDB sử dụng dữ liệu từ các chỉ số để xác định văn bản 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 ả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

MongoDB cho phép sử dụng các chỉ số để trả về văn bản đã được sắp xếp một cách trực tiếp, loại bỏ bước sắp xếp trung gian.

MongoDB cho phép sử dụng các chỉ số để truy vấn và sắp xếp dữ liệu theo thứ tự tăng dần hoặc giảm dần, giúp trả về kết quả đã được sắp xếp một cách hiệu quả.

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

Khi một truy vấn hợp lệ yêu cầu một chỉ số cụ thể, MongoDB sẽ trả về kết quả ngay lập tức mà không cần duyệt hay ghi văn bản vào bộ nhớ, giúp 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.

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

2.3.1.Thao tác thêm văn bản i

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:

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

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

Trong đó: x là một document hay là một mảng bao gồm nhiều document

Ví dụ: db.foo.insert({“bar”: “baz”})

Hệ thống sẽ tự thêm trường “_id” vào document (nếu như nó không được khai báo)

2.3.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);

Phương thức này cho phép xóa các document trong collection, với tham số x đại diện cho document hoặc cú pháp trả về là document Nếu tham số x là rỗng (x = {}), toàn bộ document trong collection sẽ bị xóa.

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

Một document đã được lưu trong collection, nó vẫn có thể thay đổi giá trị thông qua phương thức

[tên_CSDL].[tên_collection].update(x,y);

Phương thức gồm có 2 tham số: x là tham số để xác định document cần thay đổi y là tham số cập nhật là document đó

Nếu như 2 phương thức cùng đến trong khoảng thời gian tương tự nhau Cái nào đến trước sẽ được thực thi trước, đến sau sẽ được thực thi sau

Phương thức find() là loại truy vấn phổ biến nhất trong MongoDB Nó trả về tập hợp document trong collection Cách sử dụng như sau:

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 tham số x để trống, hệ thống sẽ trả về toàn bộ nội dung trong collection Mặc định, tham số x được thiết lập là {} (tức là rỗng).

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 truy vấn dữ liệu để tìm kiếm một giá trị cụ thể, chẳng hạn như tìm một người dùng có độ tuổi là 27, bạn có thể nhập điều kiện này vào tham số của câu truy vấn.

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 giá trị là “joe”, ta làm như sau:

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

Để truy vấn tài liệu dựa trên nhiều giá trị từ các trường khác nhau, bạn chỉ cần sắp xếp các giá trị thành các tham số của phương thức Chẳng hạn, để tìm kiếm người dùng có trường “age” là 27 và “Username” là “joe”, bạn thực hiện như sau:

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

2.3.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ố 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:

> db.people.find({“Username”: “mark”})

Khi chỉ sử dụng một trường trong câu lệnh, trường đó có thể được đánh chỉ số index để cải thiện tốc độ xử lý Ví dụ, chúng ta có thể tạo index cho trường "Username" bằng cách thực hiện các bước cụ thể sau đây.

Chỉ số của một trường trong collection chỉ được thêm một lần Nếu chúng ta cố gắng tạo lại chỉ số với cùng một tên, sẽ không có tác động nào xảy ra.

Chỉ số Index có thể làm cho câu lệnh của một trường chạy nhanh hơn, nhưng không phải tất cả các câu lệnh đều được cải thiện tốc độ, ngay cả khi có chỉ số Index Ví dụ, câu lệnh dưới đây không nhanh hơn mặc dù đã có chỉ số Index được tạo ra trước đó.

> 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

Để tối ưu hóa truy vấn, cần tạo chỉ số index cho cả trường "date" và "Username" vì hiện tại "Username" nằm trong phương thức "sort" cùng với "date", dẫn đến việc server phải duyệt toàn bộ các document trong collection để tìm kiếm điều kiện khớp Việc này sẽ diễn ra chậm chạp nếu số lượng document lớn do trường "date" không có index Do đó, việc tạo chỉ số index bao gồm tất cả các trường trong câu lệnh là cần thiết để cải thiện hiệu suất truy vấn.

Các đối số của phương thức tạo chỉ mục ensureIndex() tương tự như đối số của phương thức sort() Giá trị của mỗi trường có thể là 1 hoặc -1, với 1 biểu thị thứ tự tăng dần và -1 biểu thị thứ tự giảm dần.

Khi có nhiều hơn một trường để đánh chỉ mục, việc xác định thứ tự ưu tiên sắp xếp là rất quan trọng Ví dụ, trong một collection nhất định, cần cân nhắc cách tổ chức các trường này để tối ưu hóa hiệu quả tìm kiếm và truy xuất dữ liệu.

The dataset includes users with various ages and usernames, showcasing a diverse age range Notably, "smith" has two entries at ages 48 and 30, while "john" appears multiple times at ages 36, 18, and 7 "Joe" is represented at ages 36 and 27, and "simon" at ages 3 and 59 Additionally, "jacob" is listed at age 17, and "sally" is noted at age 52 This collection highlights the age diversity among users, with usernames reflecting a mix of common names.

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ự chữ cái tăng dần, trong khi nếu có các tên trùng lặp, trường "age" sẽ được sắp xếp theo thứ tự giảm dần Cách sắp xếp này phụ thuộc vào các 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, chỉ số index với N trường giúp tăng tốc độ thực thi các lệnh truy vấn có tiền tố tương ứng Ví dụ, một chỉ số index như {“a”: 1, “b”: 1, “c”: 1, , “z”: 1} cũng có thể hỗ trợ các chỉ số tiền tố như {“a”: 1}, {“a”: 1, “b”: 1}, và {“a”: 1, “b”: 1, “c”: 1} Tuy nhiên, các chỉ số không theo đúng thứ tự như {“b”: 1} hay {“a”: 1, “c”: 1} sẽ không phát huy tác dụng, vì chúng không phải là tiền tố của index đã được tạo Chỉ những index là tiền tố của index gốc mới có khả năng cải thiện hiệu suất truy vấn.

Việc sử dụng index trong cơ sở dữ liệu có nhược điểm là phát sinh chi phí cho các thao tác insert, update và remove Điều này xảy ra vì sau khi thực hiện các câu lệnh trên, cơ sở dữ liệu còn phải cập nhật lại index, dẫn đến tăng thêm thời gian và tài nguyên cần thiết.

2.3.5.1.Chỉ số index cho các document con

CHUYỂN ĐỔI LƯỢC ĐỒ RDBMs SANG NoSQL

Tổng quan mô hình quan hệ cho dữ liệu

Điều cơ bản nhất trong việc chuyển đổi dữ liệu quan hệ trang lược đồ NoSQL là mô hình hóa lược đồ cho dữ liệu

Lược đồ dữ liệu của RBDMs và NoSQL có sự khác biệt rõ rệt, nhưng cũng tồn tại một số điểm chung đáng lưu ý Bảng dữ liệu dưới đây sẽ cung cấp các tham chiếu thuật ngữ giữa các thành phần của hai kiểu dữ liệu này.

Join Embedded Document hoặc Reference

Bảng 3-1: Bảng ánh xạ các thành phần giữa RDBM và NoSQL

Mô hình hóa khi chuyển từ RDBMs sang MongoDB yêu cầu chúng ta phải áp dụng các điều kiện thực thể để điều chỉnh cấu trúc lược đồ cho phù hợp.

Có 2 cách phương pháp để tổ chức mô hình lược đồ từ RDBMs sang MongoDB:

Tận dụng cấu trúc lược đồ dữ liệu quan hệ và tổ chức dữ liệu của MongoDB theo hướng 2 chiều (2-dimensional) với các hàng và cột trong hệ quản trị cơ sở dữ liệu quan hệ (RDBMs) giúp tối ưu hóa hiệu suất và khả năng mở rộng.

 Tổ chức dữ liệu theo hướng nhúng văn bản đơn hoặc trên mảng (embedded sub-documents and arrays)

3.1.1.Sự linh hoạt của dữ liệu JSON/BSON

Hiện nay, hầu hết dữ liệu phức tạp cần được mô hình hóa và biểu diễn hiệu quả hơn thông qua việc lưu trữ dưới định dạng JSON (JavaScript Object Notation), mang lại lợi ích vượt trội so với lưu trữ theo dạng bảng.

MongoDB lưu trữ tài liệu JSON dưới dạng nhị phân gọi là BSON (Binary JSON), giúp mã hóa tất cả các kiểu dữ liệu mà JSON hỗ trợ.

JSON tổ chức dữ liệu theo cấu trúc đối tượng với nhiều cấp bậc, giúp người khai thác dữ liệu dễ dàng ánh xạ và quản lý thông tin trong ứng dụng.

Tổ chức dữ liệu theo dạng bảng trong RDBMs không mang lại lợi ích cho lập trình viên, vì việc tích hợp các đối tượng ORMs (Object Relational Mappers) có thể làm tăng độ phức tạp và giảm tính linh hoạt trong triển khai lược đồ và câu lệnh khai thác dữ liệu theo yêu cầu của ứng dụng.

Công việc đầu tiên trong thiết kế ứng dụng nên tập trung vào việc xây dựng các hướng xử lý dữ liệu phù hợp với yêu cầu của ứng dụng, ưu tiên khai thác tính linh hoạt của MongoDB Việc chuyển đổi dữ liệu từ mô hình lược đồ quan hệ sang MongoDB có thể đơn giản hơn nếu dựa vào cấu trúc của tài liệu trong MongoDB Tuy nhiên, điều này có thể không tối ưu, vì sẽ tạo ra nhiều cấu trúc tài liệu con khi chuyển đổi từ RDBMs sang MongoDB Ví dụ, trong RDBMs, một dữ liệu có thể liên kết với hai bảng khác nhau, nhưng khi chuyển sang MongoDB, sẽ tạo ra hai đối tượng con tương tự trong hai trường khác nhau của cùng một đối tượng cha Để giải quyết vấn đề này, có thể áp dụng cách tham chiếu tương tự như trong RDBMs trong môi trường NoSQL.

Ta có ví dụ dưới đây:

Trong ví dụ này, bảng “CAR” trong RDBMs sử dụng trường “Pers_ID” để thực hiện JOIN với bảng “PERSON” Khi chuyển đổi sang lược đồ của MongoDB, phương pháp nhúng các document con vào trong một mảng sẽ mang lại hiệu quả, giúp tổ chức các dữ kiện liên quan vào một cấu trúc mảng Khác với cách phân bố rời rạc của dữ liệu hàng và cột trong RDBMs, MongoDB cho phép lưu trữ dữ liệu trong một document có cấu trúc nhất định.

Dưới đây là tổ chức dữ liệu của MongoDB sau khi được chuyển đổi

{ first_name: “Paul”, surname: “Miller”, city: “London”, location: [45.123,47.232], cars: [

{ model: “Rolls Royce”, year: 1965, value: 330000, ….},

Việc tổ chức dữ liệu một cách trực quan và tự nhiên giúp nhà lập trình dễ dàng khai thác thông tin hơn Để làm rõ sự khác biệt giữa lược đồ quan hệ và lược đồ MongoDB, chúng ta sẽ so sánh ví dụ về cách tổ chức dữ liệu trên hai nền tảng dữ liệu này.

Trong ví dụ này, RDBMs tổ chức dữ liệu qua 5 bảng rời rạc để xây dựng hệ thống dữ liệu, trong khi MongoDB kết hợp dữ liệu thành một document duy nhất và sử dụng tham chiếu.

Users trong trường “Author” trong document “Article” và “Comment”

3.1.2.Những ƣu điểm khác của mô hình nhúng văn bản

Mô hình nhúng văn bản không chỉ mang lại lợi thế trong việc biểu diễn dữ liệu một cách tự nhiên ở nhiều cấp độ khác nhau, mà còn giúp cải thiện hiệu suất và tính linh động cao trong các ứng dụng xử lý ngôn ngữ tự nhiên.

Việc kết hợp dữ liệu trong một document giúp thay thế cho quá trình JOIN nhiều bảng trong khai thác dữ liệu Document trong MongoDB tập hợp tất cả thông tin cần thiết, cho phép truy xuất dữ liệu chỉ trong một lần đọc từ bộ nhớ Ngược lại, cơ chế JOIN của RDBMS yêu cầu đọc dữ liệu từ nhiều bảng và kết nối chúng qua các khóa ngoại, dẫn đến việc thực hiện nhiều lần đọc khác nhau.

MongoDB lưu trữ tài liệu độc lập và hỗ trợ phân tán thành các node nhỏ hơn, giúp dễ dàng mở rộng theo chiều ngang để đáp ứng các yêu cầu của ứng dụng Điều này giúp các nhà phát triển và DBA không còn lo lắng về các lỗi khi thực thi các phương thức JOIN, một vấn đề thường gặp khi làm việc với RDBMs.

3.2.Biểu diễn quan hệ trong MongoDB [1]

Các loại mô hình trong quan hệ của MongoDB đó là nhúng (Embed) và tham chiếu (Reference)

Quyết định giữa việc sử dụng mô hình bằng nhúng văn bản hay tạo liên kết giữa các tài liệu rời rạc cần được xem xét cẩn thận, dựa trên yêu cầu cụ thể của từng ứng dụng.

Cách biểu diễn lược đồ trong MongoDB

3.3.1.Biểu diễn thực thể, mối kết hợp trên lƣợc đồ

3.3.1.1.Cấu trúc thực thể cơ bản trên lược đồ

Lược đồ thực thể cơ bản trong MongoDB tương tự như lược đồ thực thể trong RDBMS, thường được gọi là bảng Trong MongoDB, lược đồ thực thể được gọi là bộ sưu tập, và có cấu trúc chung như sau:

L ợc đồ 3-1: Cấu trúc l ợc đồ cơ ản thực thể MongoDB

_id sẽ luôn là thuộc tính đứng đầu tiên của thực thể collection

là thuộc tính của thực thể

Khi được lưu trong 2.2.1.Văn bản (Document), MongoDB sẽ tổ chức dữ liệu này theo cấu trúc JSON

3.3.1.2.Cấu trúc lược đồ nhúng văn bản (đơn)

Với các văn bản con được nhúng vào một văn bản cha, lược đồ được thể hiện như sau:

L ợc đồ 3-2: Cấu trúc l ợc đồ văn ản nhúng trong MongoDB

Văn bản con (Sub-Document) được nhúng vào ngang cấp với các trường

, cấu trúc của document con được nhúng vào sẽ là có trường trong

Các thuộc tính của văn bản con chỉ có thể được truy xuất thông qua văn bản con tương ứng, và phương pháp này chỉ áp dụng cho các quan hệ số lượng 1:1.

3.3.1.3.Cấu trúc lược đồ nhúng mảng văn bản

Với văn bản con là tập các trường giá trị, kiểu nhúng mảng được thể hiện trên lược đồ như sau:

L ợc đồ 3-3: Cấu trúc l ợc đồ nhúng mảng văn ản trong MongoDB

Cấu trúc nhúng mảng văn bản vào văn bản cha tương tự như cấu trúc nhúng văn bản, nhưng khác ở chỗ văn bản con được nhúng vào sẽ là một mảng, với mỗi phần tử trong mảng có cấu trúc riêng biệt.

3.3.1.4.Cấu trúc lược đồ nhúng mảng tham chiếu

Trong một số trường hợp, ta phải dùng đến kiểu dữ liệu nhúng mảng các tham chiếu, lược đồ có cấu trúc như sau:

L ợc đồ 3-4: Cấu trúc l ợc đồ nhúng mảng tham chiếu

Cặp dấu ngoặc vuông “[]” được thể hiện cho kiểu dữ liệu mảng của văn bản con

Văn bản nhúng tham chiếu sẽ là một mảng các giá trị id được dùng để tham chiếu đến dữ liệu trong bộ sưu tập khác

Lưu ý: Ở tất cả các trường hợp sử dụng các phương pháp nhúng, ta đều cần phải lược bỏ đi thuộc tính tham chiếu ở thực thể con

3.3.1.5.Cấu trúc lược đồ tham chiếu thực thể cha

Cách này là cách tham chiếu truyền thống trong lược đồ quan hệ RDBMs, cách này cũng có thể được áp dụng trong MongoDB

L ợc đồ 3-5: Cấu trúc l ợc đồ tham chiếu thực thể cha

Cách này sẽ khiến dữ liệu trở nên rời rạc nhau, một tiêu chí mà MongoDB không hướng đến

3.3.2.Cách sử dụng các biểu diễn mối kết hợp 1: n [2]

Trong MongoDB, có hai loại mô hình quan hệ chính là nhúng văn bản và tham chiếu văn bản Khi kết hợp hai phương pháp này, chúng ta có thể tạo ra nhiều cách tiếp cận khác nhau, mỗi cách sẽ phù hợp với các tình huống sử dụng cụ thể.

Khi áp dụng phương pháp nhúng văn bản đơn cho quan hệ số lượng 1:1, chúng ta gặp phải sự phức tạp hơn với quan hệ số lượng 1:n Điều này là do quyết định sẽ phụ thuộc vào số lượng "n" trong mối quan hệ này.

Một ví dụ về quan hệ 1:n là khi nói đến địa chỉ của một người Việc này cho phép chúng ta thể hiện dữ liệu một cách hiệu quả, bằng cách biểu diễn các địa chỉ dưới dạng mảng và nhúng chúng vào văn bản của “person” như một văn bản con mang tên “addresses”.

_id : ObjectID('AAAA'), name: 'Kate Monster', ssn: '123-456-7890', addresses : [

{ street: '123 Sesame St', city: 'Anytown', cc: 'USA' }, { street: '123 Avenue Q', city: 'New York', cc: 'USA' } ]

Dữ liệu này được biểu diển trên lược đồ như sau:

Lược đồ 3-6 mô tả mô hình phương pháp nhúng mảng văn bản, với ưu điểm nổi bật là giảm thiểu số lượng câu truy vấn cần thực hiện để lấy các giá trị văn bản nhúng.

Phương pháp này có nhược điểm lớn là không cho phép truy cập vào từng văn bản một cách độc lập, mà chỉ có thể truy cập thông qua văn bản cha duy nhất.

Tài liệu nhúng sẽ bao gồm một mảng chứa cấu trúc của một đối tượng JSON, với số lượng phần tử trong mảng thường khá nhỏ.

Trong ví dụ về quan hệ 1:n, n trung bình có thể đại diện cho các thành phần linh kiện trong một sản phẩm, với mỗi sản phẩm có thể bao gồm hàng trăm linh kiện khác nhau, nhưng không vượt quá hàng ngàn Đây là một trường hợp lý tưởng để áp dụng cách biểu diễn này Chúng ta sẽ nhúng một mảng giá trị tương tự như khi n nhỏ, trong đó mỗi phần tử của mảng sẽ chứa giá trị của trường _id của một văn bản tham chiếu, ví dụ như một văn bản mô tả linh kiện của sản phẩm.

_id : ObjectID('AAAA'), partno : '123-aff-456', name : '#4 grommet', qty: 94, cost: 0.94, price: 3.99 }

Trong văn bản của sản phẩm, ta sẽ liệt kê ra các linh kiện của nó thông qua _id của linh kiện, ví dụ như sau:

> db.products.findOne() { _id : ObjectID('…'), name : 'left-handed smoke shifter', manufacturer : 'Acme Corp', catalog_number: 1234, parts : [ // array of references to Part documents ObjectID('AAAA'), // reference to the #4 grommet above

ObjectID('F17C'), // reference to a different Part ObjectID('D2AA'),

Dữ liệu được biểu diễn trên lược đồ như sau:

Lược đồ 3-7 mô tả mô hình phương pháp nhúng mảng tham chiếu, với ưu điểm nổi bật là tính độc lập của các phần dữ liệu Điều này cho phép việc tìm kiếm, truy vấn và cập nhật dữ liệu diễn ra dễ dàng và độc lập, không cần phụ thuộc vào tài liệu cha.

Một nhược điểm của phương pháp này là MongoDB cần thực hiện hai truy vấn để lấy chi tiết các thành phần, điều này có thể ảnh hưởng đến hiệu suất Tuy nhiên, mô hình này có khả năng mở rộng tốt, vì nếu quan hệ 1:n được chuyển thành quan hệ n:n, nó vẫn có thể đáp ứng yêu cầu mà không cần thay đổi gì.

3.3.2.3.n lớn Đây là phương pháp mà RDBMs thường dùng để lưu trữ dữ liệu với quan hệ 1-n, tuy nhiên phương pháp này ít khi được sử dụng trong MongoDB, ví nó chỉ được dùng khi 2 phương pháp trên không đáp ứng được Ví dụ, trong trường hợp host lưu lại các thông báo “log” từ các máy khác nhau Dữ liệu này thông thường sẽ rất lớn, và khi thực hiện nhúng vào

Văn bản có thể vượt quá dung lượng tối đa 16MB, ngay cả khi sử dụng các tham chiếu nhúng Để khắc phục vấn đề này, việc tham chiếu đến thực thể cha sẽ là giải pháp cuối cùng.

Nếu ta có một văn bản để lưu thông tin của các host, cùng với giá trị trường khóa _id

Sau đó, với mỗi trường giá trị thông báo “log”, ta sẽ lưu một trường có giá trị _id của host để có thể thực hiện tham chiếu tới

_id : ObjectID('AAAB'), name : 'goofy.example.com', ipaddr : '127.66.66.66' }

_id : ObjectID('…'), time : ISODate("2014-03-28T09: 42: 41.382Z"), message : 'cpu is on fire!', host: ObjectID('AAAB')/ Reference to the Host document }

Dữ liệu được biểu diễn trên lược đồ như sau:

L ợc đồ 3-8: Ví ụ mô hình ph ơng pháp tham chiếu thực thể cha

Cơ chế xử lý dữ liệu trong MongoDB và bài toán tối ưu lược đồ [3]

MongoDB sử dụng cơ chế ánh xạ dữ liệu vào bộ nhớ ảo để lưu trữ, với bộ nhớ này được cấp phát bởi hệ điều hành khi khởi động MongoDB Dung lượng bộ nhớ phụ thuộc vào cấu hình của máy chủ.

Mỗi dữ liệu được ánh xạ sẽ trở thành một phần của bộ nhớ ảo, và khi có yêu cầu lưu trữ, từng byte dữ liệu sẽ được ánh xạ đến bộ nhớ lưu trữ (ổ đĩa).

Hình 3-3: Mô phỏng cơ chế l u ữ liệu trên MongoDB

MongoDB sử dụng cơ chế ánh xạ dữ liệu để giao phó việc quản lý dữ liệu trong bộ nhớ ảo cho hệ điều hành, thay vì tự mình quản lý Dữ liệu được ánh xạ sẽ được lưu trữ trong bộ nhớ ảo cho đến khi bộ nhớ này đạt dung lượng tối đa.

Khi bộ nhớ ảo đã đầy và ứng dụng cần dữ liệu không có trong RAM, hệ điều hành sẽ lấy dữ liệu từ ổ đĩa và tạo vùng nhớ trống để lưu dữ liệu mới Dữ liệu trong bộ nhớ ảo sẽ được thay thế bằng thuật toán LRU (Least Recently Used), giúp loại bỏ dữ liệu ít sử dụng nhất để thêm dữ liệu mới.

Dữ liệu ứng dụng được khai thác từ yêu cầu xác định, và khi cơ chế xử lý dữ liệu có thể thực thi hoàn toàn trên bộ nhớ RAM, tốc độ xử lý sẽ đạt mức cao nhất vì không cần ánh xạ đến ổ đĩa Tuy nhiên, thực tế cho thấy bộ nhớ ảo trên RAM không đủ để lưu trữ tất cả dữ liệu khai thác, chỉ có thể lưu một phần dữ liệu truy cập gần nhất Khi bộ nhớ đầy, những dữ liệu không còn được lưu trữ trên bộ nhớ ảo sẽ buộc phải ánh xạ đến ổ đĩa để tiếp tục xử lý.

Để tối ưu hóa hiệu suất của MongoDB, dữ liệu cần được lưu trữ sao cho tối đa hóa việc sử dụng RAM, đồng thời tránh lưu trữ những dữ liệu không cần thiết nhằm tiết kiệm bộ nhớ ảo.

Cơ chế thay thế dữ liệu trong bộ nhớ ảo:

Phương pháp LRU (Least Recently Used) lưu trữ dữ liệu được sử dụng gần đây nhất Khi bộ nhớ đầy, nó sẽ loại bỏ dữ liệu ít được sử dụng nhất để nhường chỗ cho dữ liệu mới.

Dữ liệu 1 Dữ liệu 2 Ổ đĩa

Giả sử ví dụ ta có thứ tự xử lý dữ liệu các văn bản sau từ ứng dụng: 0 2 8 0 2 3

Với số trang nhớ là 3

Bảng 3-2: Mô tả ph ơng pháp thay thể bộ nhớ LRU

– : Cơ chế nạp dữ liệu thông qua ổ đĩa

+ : Cơ chế nạp dữ liệu từ bộ nhớ có sẵn trong RAM

Trong ví dụ trên, phương pháp này cho thấy rằng trong quá trình xử lý, có 3 lần dữ liệu cần nạp từ ổ đĩa trong tổng số 7 lần, trong khi đó 4 lần dữ liệu được nạp trực tiếp từ RAM.

Cơ chế này cho phép lưu trữ dữ liệu được sử dụng gần đây trong bộ nhớ RAM, từ đó giảm thiểu chi phí truy cập dữ liệu từ ổ đĩa.

Để tối ưu hóa việc lưu trữ dữ liệu trên bộ nhớ RAM, cần thực hiện phân mảnh và lựa chọn các phép kết hợp hợp lý, nhằm đảm bảo rằng dữ liệu trên RAM được khai thác một cách triệt để.

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

Quy trình chuyển đổi lược đồ từ RDBMs sang MongoDB gồm 5 thao tác chính sau:

Hình 3-4: Mô hình các ớc chuyển đổi[1] Để thực hiện chuyển đổi từ dữ liệu RDBMs sang dữ liệu MongoDB, ta có các bước chính như sau:

Phân tích chuyển đổi lược đồ

Chuyển đổi dữ liệu Đưa vào quy trình

3.5.1.Xác định mục tiêu Ở bước đầu tiên, ta đã có lược đồ quan hệ RDBMs, từ lược đồ này, ta xác định mục tiêu, làm tôn chỉ cho việc chuyển đổi, tránh việc chuyển đổi không đáp ứng mục tiêu ban đầu đề ra, xác định tổng quan về mục đích chính ứng dụng

3.5.2.Thu thập thông tin Ở bước này, dựa vào lược đồ RDBMs có sẵn, ta thực hiện các công việc sau:

 Xác định các thực thể dữ liệu

 Xác định các Index của dữ liệu thực thể (nếu có)

 Phân loại các nhóm thực thể chính dựa theo tính chất của thực thể và mục đích ứng dụng

 Xác định cụ thể các quan hệ số lượng của các thực thể (nếu lược đồ chưa có)

Để xác định yêu cầu chức năng của ứng dụng, chúng ta cần thực hiện các bước sau: đầu tiên, liệt kê các chức năng chính của ứng dụng; tiếp theo, xác định độ ưu tiên cho từng chức năng; cuối cùng, tổng hợp các dữ liệu cần thiết cho mỗi chức năng, bao gồm dữ liệu đầu vào và đầu ra.

Với mỗi chức năng ta thể hiện như sau:

Chức năng[i]: tên chức năng Độ ưu tiên: [ ] (%) Thực thể Trường Dữ liệu đầu vào Dữ liệu đầu ra

Bảng 3-3: Xác định các ữ liệu cần thiết cho chức năng

Độ ưu tiên chức năng là hệ số có thể xác định qua nhiều cách khác nhau, bao gồm việc khách hàng xác định dựa trên tiêu chí các tính năng chính và phụ của ứng dụng Ngoài ra, nó cũng có thể được xác định bằng tỷ lệ sử dụng các chức năng trên ứng dụng.

3.5.3.Phân tích chuyển đổi lƣợc đồ

Từ những điều đã xác định được ở bước trước đó, ta tiến hành xây dựng mô hình lược đồ NoSQL

3.5.3.1 Xác định nhúng văn bản thực thể

Dựa trên các thông số tần suất tương tác giữa các thực thể dữ liệu, chúng ta có thể xác định giải pháp biểu diễn dữ liệu phù hợp.

Đối với mỗi nhóm thực thể chính, chúng ta xác định các thực thể con có mối quan hệ 1:1 hoặc 1:n Đây là những thực thể mà chúng ta sẽ tiến hành nhúng dữ liệu.

 1:n (n nhỏ): thực hiện nhúng mảng văn bản

 1:n (n lớn): thực hiện nhúng mảng tham chiếu

Với mỗi nhóm thực thể chính, ta biểu diễn theo bảng sau:

Thực thể Chức năng [i] … Tần suất sử dụng ưu tiên ( )

Bảng 3-4: Phân tích thực hiện nhúng thực thể

Đối với mỗi giá trị của cột chức năng [i], nếu không có dữ liệu từ bảng trong đầu ra hoặc đầu vào của chức năng, ta sẽ ghi 0; ngược lại, nếu có dữ liệu, ta ghi 1.

Bước 3: Ứng với mỗi bảng phụ [k], ta xác định tần suất giữa thực thể chính – thực thể phụ [k]

Gọi số [ ] thể hiện dữ liệu của thực thể chính (c) và thực thể phụ [k] trên chức năng [i] Nếu một trong hai không có dữ liệu trong chức năng [i], trả về 0 Nếu cả hai bảng đều có dữ liệu trong chức năng [i], trả về 1.

Gọi [ ]( ) là tần suất sử dụng ưu tiên của dữ liệu cùng có trong thực thể chính (c) – thực thể phụ [k] trên chức năng [i]:

Ta xác định tỉ lệ sử dụng T(%) của tần suất sử dụng chung [ ]( ) đối với từng thực thể chính (c) và thực thể phụ [k]:

Chi phí xử lý dữ liệu trung bình bằng phương pháp nhúng được ký hiệu là x, trong khi chi phí xử lý dữ liệu trung bình bằng phương pháp tham chiếu được ký hiệu là y Cả hai giá trị x và y có thể được xác định thông qua các phương pháp ước lượng hoặc đo đạt cụ thể.

Hình 3-5: Xác định tần suất thực hiện nhúng a a

Tần suất sử dụng chung (%)

Trong MongoDB, tỉ lệ tần suất a được sử dụng để xác định phương pháp thực hiện nhúng hoặc tham chiếu Khi tần suất sử dụng chung thấp (từ 0% đến a), phương pháp tham chiếu là lựa chọn hợp lý Ngược lại, khi tần suất sử dụng chung cao (từ a đến 100%), phương pháp nhúng sẽ được ưu tiên Để tối ưu hóa chi phí xử lý dữ liệu giữa hai phương pháp này, cần áp dụng công thức cân bằng phù hợp.

( ) (Nói cách khác, cũng là tỉ lệ chi phí xử lý của phương pháp nhúng.)

Tiêu chuẩn để xác định nhúng cho văn một thực thể phụ [k] với thực thể chính (c) ta thực hiện như sau:

 Quan hệ giữa thực thể chính (c) và thực thể [k] là 1: 1 hoặc 1: n

 Số lượng trường của một document nhỏ

 Số lượng document của thực thể [k] khi nhúng vào thực thể (c) nhỏ

(Đảm bảo kích thước document không vướt quá 16MB)

3.5.3.2.Xác định phân mảnh dữ liệu Để phân mảnh được hiệu quả, thực thể đó cần phải đảm bảo các điều kiện sau đây:

 Số lượng trường của thực thể lớn

 Tần suất được sử dụng của các trường là chênh lệch nhau

 Dữ liệu khi được phân mảnh vẫn đảm bảo được tính trực quan của dữ liệu

Dựa vào tần suất sử dụng các trường thuộc tính trong các trường dữ liệu, chúng ta tiến hành phân mảnh các thực thể để tối ưu hóa quá trình xử lý thông tin.

Với các thực thể, ta biểu diễn như sau:

Trường / Thuộc tính Chức năng [i] … Tần suất sử dụng ưu tiên

Bảng 3-5: Phân tích phân mảnh thực thể

Giả sử, ta có: n: tổng số chức năng u: tổng số thuộc tính trong mỗi bảng[k] m: tổng số bảng

: Hệ số ưu tiên chức năng (%)

Đối với mỗi thuộc tính của từng bảng, chúng ta đánh giá giá trị của từng cột chức năng là 0 nếu thuộc tính đó không có trong dữ liệu đầu ra/đầu vào của chức năng, và ngược lại, nếu thuộc tính tồn tại, chúng ta đánh giá là 1.

Sau đó, “Tần suất sử dụng ưu tiên ” cho mỗi thuộc tính trong bảng [k] được xác định bằng cách:

So sánh,với mỗi thuộc tính của bảng[k], ta so sánh giá trị ̅ và [ ] tương ứng

Nếu [ ] ̅: Ta chọn trường tương ứng để phân mảnh

Sau khi xem xét tất cả các phần tử thuộc tính của bảng[k], nếu số lượng phần tử được tách lớn hơn 50% của u, chúng ta sẽ không thực hiện phân mảnh bảng[k] Ngược lại, chúng ta sẽ tiến hành phân mảnh các phần tử đã chọn thành hai nhóm: nhóm thuộc tính được chọn và nhóm thuộc tính không được chọn Nhóm thuộc tính được chọn sẽ là thực thể chính, trong khi nhóm thuộc tính không được chọn sẽ là thực thể phụ, với thực thể phụ tham chiếu đến thực thể chính qua _id của bảng theo quan hệ 1:1.

Việc xác định phân mảnh cho thực thể phụ thuộc vào số lượng thuộc tính u lớn và tính chất của dữ liệu, nhằm tránh tình trạng dữ liệu tách ra trở nên khó hiểu và thiếu ý nghĩa.

3.5.3.3.Xác định lược đồ sau cùng

Kết hợp 2 kết quả phân tích được:

 Dựa vào các tính chất tự nhiên của dữ liệu, tinh chỉnh cho phù hợp (nếu có)

 Tiếp theo, ta tiến hành biểu diễn trên lược đồ

Dựa vào lược đồ ta đã xây dựng được ở bước trước đó:

 Tiến hành mô phỏng một số dữ liệu mẫu và thêm vào MongoDB

 Kiểm tra hoạt động của dữ liệu mẫu

 Tiến hành xây dựng công cụ chuyển đổi dữ liệu ETL (Extract, transform, load)

Dữ liệu liệu sau khi được chuyển đổi bằng công cụ ETL, sẽ được tiến hành tiếp các bước cuối cùng:

 Quản lý và kiểm định chất lượng

 Thực hiện các thao các bản phục hồi dữ liệu để tránh sự cố xảy ra ngoài ý muốn

 Tiến hành phân tán dữ liệu (nếu cần) (High Availability - Horizontal Scaling)

 Xây dựng các phương pháp bảo mật phù hợp.

CÀI ĐẶT