1. Trang chủ
  2. » Luận Văn - Báo Cáo

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

76 269 5

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 76
Dung lượng 8,17 MB

Nội dung

Vì vậy, tôi chọn thực hiện đề tài Nghiên cứu cơ sở dữ liệu NoSQL và chuyển đổi lược đồ cơ sở dữ liệu quan hệ sang NoSQL.. Trong luận văn này, thực hiện chuyển đổi lược đồ cơ sở dữ liệu

Trang 1

ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH

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

Trang 2

Tôi xin cam đoan:

1 Những nội dung trong luận văn này là do tôi thực hiện dưới sự hướng dẫn trực tiếp của Thầy Nguyễn Đình Thuân

2 Mọi tham khảo trong luận văn đều được trích dẫn rõ ràng tên tác giả, tên công trình, thời gian công bố

Mọi sao chép không hợp lệ, vi phạm quy chế đào tạo tôi xin chịu hoàn toàn trách nhiệm

Tp Hồ Chí Minh, ngày 15 tháng 10 năm 2015

Học viên

Nguyễn Hữu Lộc

Trang 3

Em chân thành cảm ơn Thầy Nguyễn Đình Thuân – Đại học Công nghệ Thông tin – Đại Học Quốc gia Thành Phố Hồ Chí Minh đã khuyến khích, động viên, hướng dẫn và hỗ trợ em hoàn thành luận văn này

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 - Đại Học Quốc gia Thành Phố Hồ Chí Minh đã 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

Con cảm ơn Cha Mẹ và gia đình đã tạo điều kiện tốt nhất cho con học tập và hoàn thành luận văn

Hữu Lộc

Trang 4

MỤC LỤC

MỤC LỤC 1

DANH MỤC CÁC KÝ HIỆU VÀ CHỮ VIẾT TẮT 5

DANH MỤC CÁC THUẬT NGỮ 6

DANH MỤC CÁC BẢNG 7

DANH MỤC CÁC HÌNH VẼ, ĐỒ THỊ 8

MỞ ĐẦU 10

Chương 1 TỔNG QUAN 12

1.1 Tình hình chuyển đổi từ cơ sở dữ liệu quan hệ vào NoSQL 12

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

Chương 2 GIỚI THIỆU CƠ SỞ DỮ LIỆU NOSQL, MONGODB VÀ DỮ LIỆU MẪU TPC-H 14

2.1 Giới thiệu NoSQL 14

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

2.1.2 Phân loại cơ sở dữ liệu NoSQL 15

2.1.2.1 Cơ sở dữ liệu cặp khóa/giá trị 15

2.1.2.2 Cơ sở dữ liệu cột 16

2.1.2.3 Cơ sở dữ liệu tài liệu 18

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

2.2 Giới thiệu MongoDB 23

2.2.1 Các khái niệm cơ bản: 23

2.2.1.1 Khóa-giá trị 23

2.2.1.2 Trường 23

2.2.1.3 Tài liệu 23

2.2.1.4 Bộ sưu tập 25

2.2.2 Các thao tác cơ bản trong MongoDB 25

2.2.2.1 Tạo cơ sở dữ liệu: 25

Trang 5

2.2.2.2 Xóa cơ sở dữ liệu 26

2.2.2.3 Tạo bộ sưu tập 26

2.2.2.4 Xóa bộ sưu tập 26

2.2.2.5 Thao tác thêm tài liệu 27

2.2.2.6 Thao tác xóa tài liệu 27

2.2.2.7 Thao tác cập nhật tài liệu 27

2.2.2.8 Thao tác truy vấn 28

2.2.3 Đánh giá ưu điểm, nhược điểm khi chuyển sang MongoDB 29

2.2.3.1 Những ưu điểm khi chuyển đổi sang MongoDB 29

2.2.3.2 Những nhược điểm khi chuyển đổi sang MongoDB 29

2.3 Giới thiệu dữ liệu mẫu TPC-H 30

2.3.1 Giới thiệu 30

2.3.2 Lược đồ quan hệ: 33

2.3.3 Đặc tả các bảng 33

2.3.4 Tạo dữ liệu mẫu TPC-H trong SQL Server 2008 39

Chương 3 CHUYỂN ĐỔI LƯỢC ĐỒ CƠ SỞ DỮ LIỆU SQL SERVER SANG MONGODB 40

3.1 Một số nền tảng ánh xạ lược đồ 40

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

3.2.1 Xác định mục tiêu, lên kế hoạch 41

3.2.2 Thiết kế lược đồ 41

3.2.2.1 Định nghĩa mô hình dữ liệu 42

3.2.2.2 Xây dựng mô hình quan hệ 43

3.2.3 Chuyển đổi dữ liệu 46

3.2.4 Vận hành, bảo mật dữ liệu 47

Chương 4 MẢNH LƯU TRỮ TRONG MONGODB 48

4.1 Mô hình phân tán 48

4.2 Giới thiệu Mảnh lưu trữ 48

4.2.1 Mảnh lưu trữ là gì? 48

4.2.2 Mục đích của mảnh lưu trữ? 48

Trang 6

4.3 Tổng quan về mảnh lưu trữ trong MongoDB 50

4.3.1 Giới thiệu: 50

4.3.1.1 Shards (mảnh): 51

4.3.1.2 Query routers: 52

4.3.1.3 Máy chủ cấu hình: 52

4.3.2 Các yêu cầu khi dùng mảnh lưu trữ: 53

4.3.2.1 Yêu cầu về sharded cluster: 53

4.3.2.2 Yêu cầu về số lượng dữ liệu: 53

4.3.3 Kiến trúc sharded cluster thử nghiệm (Sharded cluster Test Architecture): 53

4.3.4 Khóa mảnh: 54

4.4 Triển khai mảnh lưu trữ trong MongoDB 55

4.4.1 Chuẩn bị: 55

4.4.2 Cài đặt: 56

4.4.3 Một số lưu ý: 60

Chương 5 CÀI ĐẶT 62

5.1 Chuyển đổi lược đồ SQL Server sang MongoDB 62

5.1.1 Xác định mục tiêu, lên kế hoạch 62

5.1.2 Thiết kế lược đồ 63

5.1.3 Chuyển đổi dữ liệu 64

5.1.4 Vận hành, bảo mật dữ liệu 66

5.2 Đánh giá 66

5.2.1 Môi trường thử nghiệm: 67

5.2.2 Công cụ so sánh tốc độ: 67

5.2.3 Câu truy vấn mẫu 68

5.2.4 Kết quả (tính theo đơn vị: mili-giây (ms)): 69

Chương 6 KẾT LUẬN VÀ KHUYẾN NGHỊ 70

6.1 Nội dung đã làm được 71

6.2 Hướng phát triển 71

TÀI LIỆU THAM KHẢO 72

Trang 7

PHỤ LỤC CÁC CÔNG TRÌNH NGHIÊN CỨU LIÊN QUAN NỘI DUNG LUẬN VĂN 72

Trang 8

DANH MỤC CÁC KÝ HIỆU VÀ CHỮ VIẾT TẮT

ACID Atomicity, Consistency, Isolation, and Durability BSON Binary JavaScript Object Notation

JSON JavaScript Object Notation

TPC Transaction Processing Performance Council

Trang 9

DANH MỤC CÁC THUẬT NGỮ

Column Family Cơ sở dữ liệu cột

Config Server Máy chủ cấu hình

Grap Database Cơ sở dữ liệu đồ thị

Key – Value Store Cơ sở dữ liệu cặp khóa/giá trị

Trang 10

DANH MỤC CÁC BẢNG

Bảng 2.1 Ví dụ cấu trúc tài liệu 19

Bảng 2.2 So sánh một số loại cơ sở dữ liệu NoSQL 23

Bảng 2.3 Part layout 33

Bảng 2.4 Supplier table layout 34

Bảng 2.5 Partsupp table layout 34

Bảng 2.6 Customer table layout 35

Bảng 2.7 Orders table layout 35

Bảng 2.8 Lineitem table layout 36

Bảng 2.9 Nation table layout 38

Bảng 2.10 Region table layout 38

Bảng 3.1 Ánh xạ các khái niệm giữa SQL Server và MongoDB 42

Bảng 4.1 Thông tin cấu hình mảnh lưu trữ 56

Bảng 5.1 Dữ liệu SQL 66

Bảng 5.2 Dữ liệu MongoDB 66

Bảng 5.3 Câu truy vấn mẫu 68

Bảng 5.4 Thời gian truy vấn dữ liệu của Server Server và MongoDB (có mảnh lưu trữ) 69

Bảng 6.1 Tổng hợp các đối tượng chuyển đổi 70

Trang 11

DANH MỤC CÁC HÌNH VẼ, ĐỒ THỊ

Hình 2.1 Cơ sở dữ liệu cặp khóa/giá trị 16

Hình 2.2 Cơ sở dữ liệu cột 17

Hình 2.3 Siêu cột 18

Hình 2.4 Cơ sở dữ liệu đồ thị 20

Hình 2.5 Ví dụ về các nút trong một cơ sở dữ liệu đồ thị 21

Hình 2.6 Sơ đồ thiết kế hệ thống cơ sở dữ liệu Master -Slave 22

Hình 2.7 Full Members [13] 30

Hình 2.8 Associate Members [13] 30

Hình 2.9 The TPC-H Business Environment 32

Hình 2.10 Lược đồ TPC-H 33

Hình 2.11 Lược đồ cơ sở dữ liệu TPC-H trong SQL Server 2008 39

Hình 3.1 Các bước chuyển đổi 41

Hình 3.2 Ví dụ cấu trúc nhúng văn bản 44

Hình 3.3 Ví dụ cấu trúc tham chiếu văn bản 45

Hình 4.1 Mô hình mảnh dữ liệu [7] 49

Hình 4.2 Mô hình mảnh lưu trữ trong MongoDB [7] 50

Hình 4.3 Mảnh chính [7] 51

Hình 4.4 Mô hình cài đặt thử nghiệm mảnh lưu trữ trong MongoDB [7] 54

Hình 4.5 Sự phân bố các tài liệu theo đoạn dữ liệu [7] 54

Hình 4.6 Mô hình phân tán dữ liệu mảnh lưu trữ 55

Hình 4.7 Ứng dụng tạo dữ liệu cho bộ sưu tập LINEITEM 59

Hình 4.8 Kết quả trên Mongos 59

Hình 4.9 Kết quả trên mảnh 1 60

Hình 4.10 Kết quả trên mảnh 2 60

Trang 12

Hình 5.1 Lược đồ TPC-H trong SQL Server 62

Hình 5.2 Mô hình chuyển đổi 62

Hình 5.3 Lược đồ TPC-H trong MongoDB 64

Hình 5.4 Giao diện ứng dụng chuyển dữ liệu SQL sang MongoDB 64

Hình 5.5 Giao diện công cụ so sánh tốc độ truy vấn dữ liệu trong SQL Server và MongoDB 67

Hình 5.6 Biểu đồ so sánh tốc độ truy vấn SQL Server và MongoDB 69

Trang 13

MỞ ĐẦU

Yêu cầu xử lý một lượng lớn dữ liệu là thách thức đối với Hệ quản trị cơ sở

dữ liệu quan hệ và NoSQL được xem như là một giải pháp hữu hiệu hiện nay NoSQL được tạo ra không phải để cạnh tranh với cơ sở dữ liệu quan hệ mà là để đảm nhiệm những việc mà cơ sở dữ liệu quan hệ chưa làm tốt NoSQL được xem như thế hệ cơ sở dữ liệu kế tiếp của cơ sở dữ liệu quan hệ NoSQL là một hệ cơ sở

dữ liệu không ràng buộc, phân tán, mã nguồn mở, có khả năng mở rộng theo chiều

ngang Vì vậy, tôi chọn thực hiện đề tài Nghiên cứu cơ sở dữ liệu NoSQL và chuyển

đổi lược đồ cơ sở dữ liệu quan hệ sang NoSQL

Trong các hệ cơ sở dữ liệu NoSQL thì MongoDB hiện đang phát triển khá mạnh MongoDB là một cơ sở dữ liệu hướng tài liệu, mã nguồn mở, cung cấp hiệu suất cao, tính sẵn sàng cao, và mở rộng quy mô tự động [3] Trong luận văn này, thực hiện chuyển đổi lược đồ cơ sở dữ liệu SQL Server sang MongoDB với dữ liệu mẫu là TPC-H TPC-H liên quan đến các hệ hỗ trợ quyết định: kiểm tra dữ liệu lớn; thực hiện các truy vấn trả lời cho các câu hỏi trong lĩnh vực kinh doanh

Bỏ qua các yếu tố trước khi chuyển đổi bao gồm các khía cạnh giá cả của các giải pháp và chi phí khả năng mở rộng, trọng tâm của luận văn này là sự chuyển đổi

sơ đồ Mục tiêu chính là thiết kế, thực hiện, kiểm tra các khả năng, những hạn chế,

và thiếu sót khi chuyển đổi lược đồ cơ sở dữ liệu quan hệ (cụ thể là SQL Server) sang lược đồ cơ sở dữ liệu NoSQL (MongoDB) có xem xét tính năng mảnh lưu trữ trong MongoDB

Luận văn được trình bày thành 6 chương:

Chương 1 Tổng quan: trình bày tình hình nghiên cứu trong và ngoài nước, xác định mục tiêu đề tài, nội dung và phương pháp nghiên cứu

Chương 2 Giới thiệu cơ sở dữ liệu NoSQL, MongoDB và dữ liệu mẫu TPC-H Chương 3 Chuyển đổi lược đồ cơ sở dữ liệu SQL Server sang MongoDB: trình bày

cơ sở lý thuyết để chuyển đổi lược đồ SQL Server sang MongoDB

Trang 14

Chương 4 Mảnh lưu trữ trong MongoDB: trình bày các khái niệm, đặc điểm, lý thuyết cài đặt của mảnh lưu trữ trong MongoDB

Chương 5 Cài đặt: xây dựng ứng dụng C# chuyển đổi và đánh giá hiệu suất khi chuyển đổi lược đồ SQL Server sang MongoDB

Chương 6 Đánh giá, kết luận

Trang 15

Chương 1 TỔNG QUAN

1.1 Tình hình chuyển đổi từ cơ sở dữ liệu quan hệ vào NoSQL

Thực tế là đã có nhiều công ty chuyển đổi dữ liệu quan hệ của họ sang NoSQL Hầu hết là chuyển đổi ở mức vật lý như là bảng, dòng, cột Ở đây, xin trích dẫn một số trường hợp trong số đó

Netflix, nhà cung cấp dịch vụ phim ảnh và chương trình truyền hình trực tuyến, chuyển đổi từ Oracle sang Amazon Web Services (AWS) SimpleDB và Simple Storage Service (S3) vì AWS hứa hẹn là sản phẩm có tính sẵn sàng tốt hơn

và khả năng mở rộng trong một khoảng thời gian tương đối ngắn [12] Trước khi chuyển đổi, họ chỉ có một trung tâm dữ liệu và đối mặt với nhiều vấn đề Thay vì xây dựng thêm nhiều trung tâm, họ quyết định chuyển dữ liệu sang AWS

eBay đã áp dụng Cassandra trong dự án Socail Signal, một dự án liên quan đến chức năng thích/sở hữu/muốn trên các trang sản phẩm của eBay Họ đã tổng hợp các kinh nghiệm thực tế và gợi ý một số mô hình hiệu quả khi di chuyển dữ liệu vào Cassandra [5]

Foursquare, mạng xã hội địa điểm, khởi đầu với dữ liệu MySQL, sau đó chuyển sang PostgreSQL Đối mặt với các thách thức tới từ việc dữ liệu phát triển nhanh chóng, họ đã xem xét nhiều chọn lựa và quyết định chọn MongoDB được lưu trên Amazon Web Services

Wireclub, một cộng đồng trực tuyến với hơn 5 triệu người dùng Mỗi ngày Wireclub phục vụ hơn một triệu lượt xem cơ sở dữ liệu chuyên sâu và hàng chục dịch vụ của hàng triệu cuộc gọi giao diện lập trình ứng dụng (API) Người dùng của

họ trao đổi hơn 1,2 triệu tin nhắn mỗi ngày Wireclub tập trung vào việc cung cấp các công cụ cho sự tương tác thời gian thực do đó đã quyết định chuyển dữ liệu từ Microsoft SQL Server (cơ sở dữ liệu quan hệ truyền thống) sang MongoDB (cơ sở

dữ liệu NoSQL hướng tài liệu) Sau khi chuyển đổi, Wireclub đưa ra các kinh nghiệm như sau: MongoDB có nhiều lợi thế về tốc độ xử lý, miễn phí, lược đồ động, Tuy nhiên, ta cũng có một số thành phần sẽ không thể di chuyển sang MongoDB [6]

Trang 16

Mặc dù đã có nhiều công trình liên quan đến nội dung của đề tài này, tuy nhiên điểm hạn chế là không có các tiêu chuẩn nào cho việc thực hiện chuyển đổi Hiện tại, việc chuyển đổi này chưa thực sự rõ ràng và chủ yếu dựa vào các phương pháp heuristic, ví dụ như dựa vào kinh nghiệm của các nhà phát triển hoặc là những phán đoán trực giác [2] Việc chuyển đổi từ cơ sở dữ liệu quan hệ sang cơ sở dữ liệu NoSQL là một quá trình rất khó để thực hiện một cách tự động

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

Mục tiêu của luận văn là:

 Tìm hiểu cơ sở dữ liệu NoSQL và minh họa bằng MongoDB

 Xem xét tính năng mảnh lưu trữ trong MongoDB

 Đặc tả, thiết kế, cài đặt một phương thức cho việc chuyển đổi lược đồ

cơ sở dữ liệu quan hệ sang cơ sở dữ liệu NoSQL

 Xây dựng ứng dụng chuyển đổi, đánh giá các ưu điểm và hạn chế khi chuyển đổi

Nội dung chính là thiết kế và thực hiện chuyển đổi lược đồ cơ sở dữ liệu SQL Server sang lược đồ cơ sở dữ liệu MongoDB Kiểm tra các khả năng, những hạn chế, và thiếu sót khi di chuyển, xác định xem các yếu tố nào trong lược đồ cơ

sở dữ liệu SQL Server có thể được chuyển đổi trực tiếp, yếu tố nào không thể chuyển đổi và sự khác biệt tương ứng giữa hai loại cơ sở dữ liệu là gì?

Trước khi chuyển đổi, ta tìm hiểu qua về cơ sở dữ liệu NoSQL, MongoDB

và dữ liệu mẫu TPC-H Dựa trên kinh nghiệm của các công ty đã thực hiện chuyển đổi; tài liệu hỗ trợ của MongoDB cùng nhiều tài liệu khác, xây dựng một phương thức chuyển đổi Tiếp theo, tiến hành chuyển đổi lược đồ SQL Server sang MongoDB Dựa vào kết quả đạt được, luận văn sẽ phân tích, so sánh, rút ra các bài học kinh nghiệm; đề xuất các hướng nghiên cứu tiếp theo nhằm đạt hiệu quả cao nhất của đề tài

Trang 17

Chương 2 GIỚI THIỆU CƠ SỞ DỮ LIỆU NOSQL, MONGODB VÀ

DỮ LIỆU MẪU TPC-H

2.1 Giới thiệu NoSQL

NoSQL là một xu hướng cơ sở dữ liệu mà không dùng mô hình dữ liệu quan hệ để quản lý dữ liệu trong lĩnh vực phần mềm NoSQL có nghĩa là Non-Relational (NoRel) - không ràng buộc Tuy nhiên, thuật ngữ đó ít phổ biến hơn và ngày nay người ta thường dịch NoSQL thành Not Only SQL - Không chỉ SQL [1] NoSQL ra đời năm 1998 bởi Carlo Strozzi khi ông lập mới một hệ cơ sở dữ liệu quan hệ mã nguồn mở nhanh và nhẹ, không liên quan đến SQL Vào năm 2009, Eric Evans, nhân viên của Rackspace giới thiệu lại thuật ngữ NoSQL trong một hội thảo về cơ sở dữ liệu nguồn mở phân tán [9]

NoSQL được xem như hệ cơ sở dữ liệu kế tiếp của cơ sở dữ liệu quan hệ, là hệ

cơ sở dữ liệu không ràng buộc, phân tán, mã nguồn mở, có khả năng mở rộng theo

chiều ngang; có thể lưu trữ, xử lý từ một lượng rất nhỏ cho tới hàng petabytes dữ

liệu trong hệ thống có độ chịu tải cao với những đòi hỏi về tài nguyên phần cứng thấp

Khi làm việc với NoSQL ta sẽ gặp một số khái niệm sau:

 Trường (field): tương đương với khái niệm cột (column) trong SQL

 Tài liệu (document): thay thế khái niệm dòng (row) trong SQL Đây cũng chính là khái niệm làm nên sự khác biệt giữa NoSQL và SQL, 1 tài liệu chứa số trường không cố định trong khi 1 dòng thì số cột (column) là định sẵn trước

 Bộ sưu tập (collection): tương đương với khái niệm bảng (table) trong SQL Một bộ sưu tập là tập hợp các tài liệu Điều đặc biệt là một bộ sưu tập có thể chứa các tài liệu hoàn toàn khác nhau

 Key-value: cặp khóa - giá trị được dùng để lưu trữ dữ liệu trong NoSQL

 Cursor: tạm dịch là con trỏ Chúng ta sẽ sử dụng con trỏ để lấy dữ liệu từ

cơ sở dữ liệu

Trang 18

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

 Khả năng mở rộng : 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: Vì chấp nhận sự trùng lặp trong lưu trữ dữ liệu nên nếu một nút bị chết sẽ không ảnh hưởng tới toàn bộ hệ thống

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

 Tính nhất quán: Chấp nhận tính nhất quán yếu, cập nhật mới không đảm bảo các truy xuất sau đó thấy được sự thay đổi Sau một khoảng thời gian lan truyền thì tính nhất quán cuối cùng của dữ liệu mới được đảm bảo

 Tính bền vững: 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

 Triển khai linh hoạt: Hệ thống sẽ tư động nhận biết việc bổ sung thêm hay loại bỏ các nút Hệ thống không đòi hỏi cấu hình phần cứng mạnh, đồng nhất

 Mô hình hóa linh hoạt: cặp dữ liệu khóa-giá trị, dữ liệu cấu trúc phân cấp,

đồ thị

 Truy vấn linh hoạt: tải một tập giá trị dựa vào tập khóa

 Khả năng mở rộng theo chiều ngang: Bình thường, với các hệ quản trị cơ

sở dữ liệu quan hệ, khi mà dữ liệu quá lớn phương pháp tăng khả năng lưu trữ là sẽ phải mở rộng (nâng cấp máy chủ), còn đối với NoSQL thì chỉ cần bổ sung thêm máy chủ khác vì hệ thống hỗ trợ lưu trữ phân tán trên nhiều máy

2.1.2 Phân loại cơ sở dữ liệu NoSQL

Cơ sở dữ liệu NoSQL được phân loại theo cách mà nó lưu trữ dữ liệu và gồm có

4 loại chính:

2.1.2.1 Cơ sở dữ liệu cặp khóa/giá trị

Cơ sở dữ liệu NoSQL đơn giản nhất chính là cơ sở dữ liệu cặp khóa/giá trị (key/value stores) Nó đơn giản nhất là vì những giao diện lập trình ứng dụng của

nó đơn giản, những triển khai thực tế của NoSQL thường rất phức tạp

Trang 19

Hình 2.1 Cơ sở dữ liệu cặp khóa/giá trị

Với cơ sở dữ liệu cặp khóa/giá trị thì việc truy xuất, xóa, cập nhật giá trị thực (value) đều thông qua khóa tương ứng Giá trị được lưu dưới dạng BLOB (Binary large object) Xây dựng một cơ sở dữ liệu cặp khóa/giá trị rất đơn giản và mở rộng chúng cũng rất dễ dàng Cơ sở dữ liệu cặp khóa/giá trị có hiệu suất rất tốt bởi vì mô hình truy cập dữ liệu được tối ưu hóa tối đa Cơ sở dữ liệu cặp khóa/giá trị là cơ sở cho tất cả những loại cơ sở dữ liệu NOSQL khác

Cơ sở dữ liệu cặp khóa/giá trị rất hữu ích khi chúng ta cần truy cập dữ liệu theo khóa Ví dụ như chúng ta cần lưu trữ thông tin phiên giao dịch hoặc thông tin giỏ hàng của người dùng thì cơ sở dữ liệu cặp khóa/giá trị là một sự lựa chọn hợp

lý bởi vì nhờ vào id của người dùng chúng ta có thể nhanh chóng lấy được các thông tin liên quan trong phiên giao dịch hoặc giỏ hàng của người dùng đó Giỏ mua hàng của Amazon chạy trên cơ sở dữ liệu cặp khóa/giá trị (Amazon Dynamo)

Vì thế có thể thấy rằng cơ sở dữ liệu cặp khóa/giá trị có khả năng mở rộng cao Amazon Dynamo Paper là một ví dụ tốt nhất về kiểu dữ liệu cặp khóa/giá trị Rhino DHT có khả năng mở rộng, chuyển đổi dự phòng, không cấu hình, là dạng cơ sở dữ liệu cặp khóa/giá trị trên nền tảng Net

Trang 20

Cơ sở dữ liệu cột được biết đến nhiều nhất thông qua sự triển khai BigTable của Google Nhìn bên ngoài vào nó giống với cơ sở dữ liệu quan hệ nhưng thực sự thì có sự khác biệt rất lớn từ bên trong Một trong những khác biệt đó chính là việc lưu trữ dữ liệu theo cột (trong cơ sở dữ liệu cột) so với việc lưu trữ dữ liệu theo dòng (trong cơ sở dữ liệu quan hệ) Sự khác biệt lớn nhất chính là bản chất của nó Chúng ta không thể áp dụng cùng một giải pháp mà chúng ta sử dụng trong cơ sở

dữ liệu quan hệ vào trong cơ sở dữ liệu cột Đó là bởi vì cơ sở dữ liệu cột phi quan

hệ Các khái niệm sau đây rất quan trọng để hiểu được cơ sở dữ liệu cột làm việc như thế nào:

- Quan hệ cột (column family)

- Siêu cột (super column)

- Cột (column)

Quan hệ cột: Một quan hệ cột là cách thức dữ liệu được lưu trữ trên đĩa cứng Tất cả dữ liệu trong một cột sẽ được lưu trên cùng một file Một quan hệ cột có thể chứa siêu cột hoặc cột

Hình 2.2 Cơ sở dữ liệu cột

Trang 21

Siêu cột: Một siêu cột có thể được dùng như một kiểu từ điển (dictionary)

Nó là một cột có thể chứa những cột khác (mà không phải là siêu cột)

Hình 2.3 Siêu cột

Cột: Một cột là một bộ gồm tên, giá trị và dấu thời gian (thông thường chỉ quan tâm tới khóa-giá trị)

2.1.2.3 Cơ sở dữ liệu tài liệu

Khái niệm trung tâm của cơ sở dữ liệu tài liệu (document database) là khái niệm “tài liệu” Về cơ bản thì cơ sở dữ liệu tài liệu là một cơ sở dữ liệu cặp khóa/giá trịvới giá trị nằm trong một định dạng được biết đến (known format) Mỗi loại cơ sở

dữ liệu tài liệu được triển khai khác nhau ở phần cài đặt chi tiết nhưng tất cả các tài liệu đều được đóng gói và mã hóa dữ liệu trong một số định dạng tiêu chuẩn hoặc

mã hóa Một số kiểu mã hóa được sử dụng bao gồm XML, YAML, JSON, và BSON, cũng như kiểu nhị phân như PDF và các tài liệu Microsoft Office (MS Word, Excel …) Trên thực tế, tất cả cơ sở dữ liệu tài liệu đều sử dụng JSON(hoặc BSON) hoặc XML

Các tài liệu bên trong một cơ sở dữ liệu tài liệu thì tương tự nhau, nó gần giống với khái niệm “mẫu tin” hay “dòng” trong cơ sở dữ liệu quan hệ truyền thống nhưng nó ít cứng nhắc hơn Các tài liệu không bắt buộc phải tuân theo một lược đồ tiêu chuẩn, cũng không cần phải có tất cả các thuộc tính, khóa tương tự nhau Xem

ví dụ dưới đây:

Trang 22

Bảng 2.1 Ví dụ cấu trúc tài liệu

{Name:"Michael",Age:10}, {Name:"Jennifer", Age:8}, {Name:"Samantha", Age:5}, {Name:"Elena", Age:2}

] }

Cả hai tài liệu trên có một số thông tin tương tự và một số thông tin khác nhau Không giống như một cơ sở dữ liệu quan hệ truyền thống, nơi mỗi dòng có cùng một tập hợp trường dữ liệu và các trường dữ liệu này nếu không sử dụng thì có thể được lưu trữ rỗng, còn trong cơ sở dữ liệu tài liệu thì không có trường dữ liệu rỗng trong tài liệu Hệ thống này cho phép thông tin mới được thêm vào mà không cần phải khai báo rõ ràng

Các tài liệu được đánh dấu trong cơ sở dữ liệu tài liệu thông qua một khóa duy nhất đại diện cho tài liệu đó Thông thường, khóa này là một chuỗi đơn giản Trong một số trường hợp, chuỗi này có thể là một đường dẫn Chúng ta có thể sử dụng khóa này để lấy tài liệu từ cơ sở dữ liệu Thông thường, cơ sở dữ liệu vẫn lưu lại một chỉ số (index) trong khóa của tài liệu để tài liệu có thể được tìm kiếm nhanh chóng Ngoài ra, cơ sở dữ liệu sẽ cung cấp một giao diện lập trình ứng dụng hoặc ngôn ngữ truy vấn cho phép bạn lấy các tài liệu dựa trên nội dung Ví dụ, chúng ta muốn truy vấn lấy những tài liệu mà những tài liệu đó có tập trường dữ liệu nhất định với những giá trị nhất định

Trang 23

Các cơ sở dữ liệu tài liệu phổ biến là: BaseX, ArangoDB, Clusterpoint, Couchbase Server, CouchDB, eXist, FleetDB, Jackrabbit, Lotus Notes, MarkLogic, MongoDB, MUMPSDatabase, OrientDB, Apache Cassandra, Redis, Rocket U2, RavenDB [10]… Lưu ý: hầu hết XML database đều là triển khai của cơ sở dữ liệu tài liệu Một số XML database trong danh sách các cơ sở dữ liệu tài liệu phổ biến là: BaseX, eXist, MarkLogic, Sedna

Trang 24

Hình 2.5 Ví dụ về các nút trong một cơ sở dữ liệu đồ thị

Trong ví dụ trên ta có 4 tài liệu và 3 mối quan hệ Mối quan hệ trong cơ sở dữ liệu đồ thị thì có ý nghĩa nhiều hơn con trỏ đơn thuần Một mối quan hệ có thể một chiều hoặc hai chiều nhưng quan trọng hơn là mối quan hệ được phân loại Một người có thể liên kết với người khác theo nhiều cách, có thể là khách hàng, có thể là người trong gia đình…Mối quan hệ tự bản thân nó có thể mang thông tin Trong ví

dụ trên ta chỉ đơn giản lưu lại lại loại quan hệ và mức độ gần gũi (bạn bè, người trong gia đình, người yêu…)

Với cơ sở dữ liệu đồ thị, chúng ta có thể thực hiện các hoạt động đồ thị Một thao tác cơ bản nhất là traversal (điểm giao nhau) Ví dụ như nếu ta muốn biết những người bạn của ta trong thị trấn để cùng đi ăn uống thì đơn giản Nhưng còn bạn bè gián tiếp thì sao, làm sao ta biết được họ Sử dụng cơ sở dữ liệu đồ thị chúng

ta có thể định nghĩa truy vấn sau:

Trang 25

"Friend", "Romantic", "Ex"},

Where = node => node.Location == ayende.Location,

Một vấn đề đối với việc mở rộng cơ sở dữ liệu đồ thị là rất khó để tìm thấy một đồ thị con độc lập, có nghĩa là rất khó để ta phân tán cơ sở dữ liệu đồ thị thành nhiều mảnh Có rất nhiều nỗ lực nghiên cứu cho việc này nhưng chưa có bất kỳ giải pháp nào đáng tin cậy được đưa ra

Một số sản phẩm tiêu biểu của cơ sở dữ liệu đồ thị là: Neo4J, Sones, AllegroGraph, Core Data, DEX, FlockDB, InfoGrid, OpenLink Virtuoso,

Hình 2.6 Sơ đồ thiết kế hệ thống cơ sở dữ liệu Master -Slave

Một cơ sở dữ liệu nhỏ (master database) đảm bảo vào ra liên tục, khi đạt tới ngưỡng thời gian hoặc dung lượng, cơ sở dữ liệu nhỏ sẽ được gộp vào cơ sở dữ liệu lớn có thiết kế tối ưu cho phép đọc (read operation, slave database) Mô hình đó cho

Trang 26

phép tăng cường hiệu suất I/O - một trong những nguyên nhân chính khiến hiệu suất trở nên kém

Bảng 2.2 So sánh một số loại cơ sở dữ liệu NoSQL

Cơ sở dữ liệu Khả năng

truy vấn

Quản lý đồng thời

Phân vùng Nhân bản

Java API

Ngôn ngữ truy vấn

Khóa Khóa

tích cực

Dãy

cơ sở

Bảng băm

Redis Có Không Không Có Không Có Không Không

Membase Có Không Không Có Không Có Không Không

CSDL

hướng

tài liệu

MongoDB Có Không Không Không Có Không Không Không

CouchDB Có Không Không Không Không Có Có Có

CSDL

hướng

cột

Cassandra Có Có Không Không Không Có Không Không

Hbase Có Có Có Không Có Không Không Không

CSDL

đồ thị

Neo4j Có Có Có Không Không Không Có Có GraphDB Có Không Không Không Không Không Không Không

2.2 Giới thiệu MongoDB

MongoDB là một cơ sở dữ liệu hướng tài liệu, mã nguồn mở, cung cấp hiệu suất cao, tính sẵn sàng cao, và mở rộng quy mô tự động Nó lưu trữ dữ liệu dưới dạng BSON, là kiểu mã hóa nhị phân của dạng JSON

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

Trang 27

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

Văn bản MongoDB có cấu trúc bao gồm các trường và các giá trị 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

var mydoc = {

_id: ObjectId(“5099803df3f4948bd2f98391”),

name: {first: “Alan”, last: “Turing”},

birth: new Date(“Jun 23, 1912”),

death: new Date(“Jun 07, 1954”),

contribs: [ “Turing machine”, “Turing test”, “Turingery” ],

Trang 28

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

2.2.1.4 Bộ sưu tập

 Bộ sưu tập là một nhóm các tài liệu

 Nếu tài liệu tương đương với dòng trong cơ sở dữ liệu quan hệ, thì bộ sưu tập tương đương với khái niệm bảng

 Bộ sưu tập có đặc điểm là lược đồ tự do, nghĩa là các tài liệu có dạng khác nhau hoàn toàn có thể cùng được lưu trữ trong 1 bộ sưu tập

Ví dụ: các tài liệu sau có thể cùng được lưu trong một bộ sưu tập

{"NoSQL" : "Hello, world!"}

{"one" : 1}

Lưu ý: Mỗi tài liệu có một khóa đặc biệt (_id), nó là duy nhất trong bộ sưu tập

Trường _id là một con số thập lục phân 12 byte Ta có thể khai báo trường _id khi thêm mới một tài liệu Nếu không thì MongoDB tự động cấp một _id duy nhất cho mỗi tài liệu 12 byte của trường _id bao gồm: 4 byte đầu tiên cho thời gian hiện tại,

3 byte tiếp theo là mã máy, 2 byte kế tiếp cho mã xử lý của server và 3 byte cuối cùng là giá trị tăng dần

2.2.2 Các thao tác cơ bản trong MongoDB

2.2.2.1 Tạo cơ sở dữ liệu:

Trang 29

Cơ sở dữ liệu mới tạo sẽ không xuất hiện trong danh sách các cơ sở dữ liệu Muốn nó xuất hiện trong danh sách, ta phải thêm vào ít nhất một tài liệu

>db.movie.insert({"name":"tutorials point"})

>show dbs local 0.78125GB mydb 0.23012GB test 0.23012GB

2.2.2.2 Xóa cơ sở dữ liệu

>{ "dropped" : "mydb", "ok" : 1 }

Lưu ý: lệnh này xóa dữ liệu đang được chọn Nếu không có, nó sẽ xóa dữ liệu mặc định là test

Trang 30

2.2.2.5 Thao tác thêm tài liệu

2.2.2.6 Thao tác xóa tài liệu

Để xóa các tài liệu trong 1 bộ sưu tập ta sử dụng cú pháp sau:

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

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

là tài liệu, thì phương thức sẽ xóa các tài liệu đó trong bộ sưu tập

Nếu x = {}: (Rỗng), thì bộ sưu tập sẽ xóa hết tất cả các tài liệu 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

2.2.2.7 Thao tác cập nhật tài liệu

Một tài liệu đã được lưu trong bộ sưu tập, nó vẫn có thể thay đổi giá trị thông qua phương thức

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

Phương thức gồm có 2 tham số:

x là tham số để xác định tài liệu cần thay đổi

Trang 31

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

2.2.2.8 Thao tác truy vấn

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 tài liệu trong bộ sưu tập Cách sử dụng như sau:

> db [tên_collection].find(x) x: là chuỗi các biểu thức xác định phương thức trả về tài liệu

Những tài liệu đượ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 bộ sưu tập, mặc định của tham số x sẽ là {} (nghĩa là rỗng), ví dụ như:

> db [tên_collection].find({}) Hoặc

> db [tên_collection].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 bộ sưu tập

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

> db.Users.find({“Username”: “joe”}) Nếu muốn truy vấn tài liệu 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})

Trang 32

2.2.3 Đánh giá ưu điểm, nhược điểm khi chuyển sang MongoDB

2.2.3.1 Những ưu điểm khi chuyển đổi sang MongoDB

 Tốc độ: Một điểm quan trọng của MongoDB đó là tốc độ đọc rất ấn tượng,

do bỏ qua khâu kiểm tra các ràng buộc toàn vẹn nên MongoDB đọc nhanh hơn nhiều lần so với cơ sở dữ liệu quan hệ

 Chi phí thấp hơn: Chi phí bỏ ra cho việc xử lý dữ liệu sẽ giảm đáng kể, các yêu cầu được đáp ứng nhanh chóng, làm tăng trải nghiệm của người sử dụng

 Lược đồ đơn giản hơn: Khi sử dụng MongoDB, mô hình dữ liệu thường được kiểm soát bởi các lập trình viên mà không cần tới những quản trị viên

cơ sở dữ liệu, lược đồ cũng được tối ưu, thân thiện với ứng dụng

2.2.3.2 Những nhược điểm khi chuyển đổi sang MongoDB

 Do cơ chế của MongoDB không hỗ trợ xử lý song song các truy vấn cùng một lúc, tất cả các truy vấn được đưa vào hàng đợi, và server xử lý từng truy vấn một Để khắc phục điều này, ta tạo nhiều thể hiện của MongoDB trên một máy và tạo ra nhiều cơ sở dữ liệu cho các khóa tranh chấp Vì vậy việc quản lý các thể hiện và cơ sở dữ liệu cũng phức tạp

 Ưu điểm cũng chính là nhược điểm của MongoDB khi không kiểm tra các ràng buộc toàn vẹn, chính điều này đôi khi làm cho cơ sở dữ liệu không nhất quán và xảy ra xung đột nếu lập trình viên không xử lý và bao quát hết các trường hợp

 Do không có một mô hình chuẩn nào được định nghĩa trên cơ sở dữ liệu MongoDB nên khó kiểm soát

 Do còn mới mẻ và đang trong quá trình phát triển nên tính ổn định chưa bằng các hệ quản trị cơ sở dữ liệu quan hệ

Trang 33

2.3 Giới thiệu dữ liệu mẫu TPC-H

Transaction Processing Performance Council (TPC) Membership (as of June 2013)

TPC-H liên quan đến các hệ hỗ trợ quyết định:

• Kiểm tra dữ liệu lớn;

• Thực hiện các truy vấn với sự phức tạp cao;

• Cung cấp câu trả lời cho các câu hỏi kinh doanh quan trọng

TPC Benchmark ™ H là cơ sở dữ liệu được thiết kế để thực hiện các chức năng hệ thống trong các ứng dụng phân tích kinh doanh phức tạp Các truy vấn này nằm trong một ngữ cảnh thực tế, mô tả hoạt động của một nhà cung cấp sỉ, giúp người đọc có cái nhìn trực giác đến các thành phần của chuẩn

Trang 34

TPC-H không đại diện cho hoạt động của bất kỳ phân khúc kinh doanh cụ thể nào, mà là bất kỳ ngành công nghiệp nào mà phải quản lý bán hàng, hoặc phân phối sản phẩm trên toàn thế giới (ví dụ: cho thuê xe, phân phối thực phẩm, các bộ phận, các nhà cung cấp,…) TPC-H không cố gắng để trở thành một mô hình hướng dẫn bí quyết xây dựng một ứng dụng phân tích thông tin thực tế

Các truy vấn mà đã được chọn trưng bày các đặc điểm sau:

• Có một mức độ phức tạp lớn;

• Sử dụng một loạt các truy cập;

• Có tính chất ad-hoc;

• Kiểm tra một tỷ lệ lớn các dữ liệu có sẵn;

• Chứa các tham số truy vấn mà thay đổi trong quá trình truy vấn

Các truy vấn được lựa chọn cung cấp câu trả lời cho các lớp phân tích kinh doanh:

• Giá cả và chương trình khuyến mãi;

• Cung cấp và quản lý nhu cầu;

• Lợi nhuận và quản lý doanh thu;

• Nghiên cứu sự hài lòng của khách hàng;

• Nghiên cứu thị phần;

• Quản lý vận chuyển

Trang 35

Hình 2.9 The TPC-H Business Environment

Business Analysis

DSS Database TPC-H Decision Makers

DSS Queries

Trang 36

2.3.2 Lược đồ quan hệ:

Hình 2.10 Lược đồ TPC-H

2.3.3 Đặc tả các bảng

Bảng 2.3 Part layout Column Name Datatype Requirements Comment

P_NAME variable text, size 55

P_MFGR fixed text, size 25

P_BRAND fixed text, size 10

RETURNFLAG LINESTATUS SHIPDATE COMMITDATE RECEIPTDATE SHIPINSTRUCT SHIPMODE COMMENT

CUSTKEY ORDERSTATUS TOTALPRICE ORDERDATE ORDER- PRIORITY

PRIORITY CLERK

SHIP-COMMENT

CUSTKEY NAME ADDRESS

PHONE ACCTBAL MKTSEGMENT COMMENT

NATIONKEY NAME REGIONKEY

NATION (N_)

25

COMMENT

REGIONKEY NAME COMMENT

REGION (R_)

5

Trang 37

P_TYPE variable text, size 25

P_CONTAINER fixed text, size 10

P_RETAILPRICE decimal

P_COMMENT variable text, size 23

Primary Key: P_PARTKEY

Bảng 2.4 Supplier table layout Column Name Datatype

Requirements

Comment

S_NAME fixed text, size 25

S_ADDRESS variable text, size 40

N_NATIONKEY S_PHONE fixed text, size 15

S_COMMENT variable text, size 101

Primary Key: S_SUPPKEY

Bảng 2.5 Partsupp table layout Column Name Datatype

Requirements

Comment

Trang 38

PS_SUPPKEY Identifier Foreign Key to S_SUPPKEY PS_AVAILQTY integer

PS_SUPPLYCOST Decimal

PS_COMMENT variable text, size

199

Primary Key: PS_PARTKEY, PS_SUPPKEY

Bảng 2.6 Customer table layout Column Name Datatype

Requirements

Comment

C_NAME variable text, size 25

C_ADDRESS variable text, size 40

N_NATIONKEY C_PHONE fixed text, size 15

C_MKTSEGMENT fixed text, size 10

C_COMMENT variable text, size 117

Primary Key: C_CUSTKEY

Bảng 2.7 Orders table layout Column Name Datatype Requirements Comment

populated

Ngày đăng: 23/12/2018, 06:17

Nguồn tham khảo

Tài liệu tham khảo Loại Chi tiết
2. Abraham Gomez, Rafik Ouanouki, Alain April and Alain Abran (2015), “Building an Experiment Baseline in Migration Process from SQL Databases to Column Oriented No-SQL Databases”, Information Technology & Software Engineering, Vol 4 (2), 1000137 Sách, tạp chí
Tiêu đề: Building an Experiment Baseline in Migration Process from SQL Databases to Column Oriented No-SQL Databases”", Information Technology & Software Engineering
Tác giả: Abraham Gomez, Rafik Ouanouki, Alain April and Alain Abran
Năm: 2015
6. Migrating from Microsoft SQL Server to MongoDB - Lessons Learned (July- 2015), https://www.wireclub.com/development/TqnkQwQ8CxUYTVT90/read7. MongoDB Inc (2015), “Sharding and MongoDB”, MongoDB Documentation Project release 3.0.4, pp. 4-6 Sách, tạp chí
Tiêu đề: Sharding and MongoDB”, "MongoDB Documentation Project
Tác giả: Migrating from Microsoft SQL Server to MongoDB - Lessons Learned (July- 2015), https://www.wireclub.com/development/TqnkQwQ8CxUYTVT90/read7. MongoDB Inc
Năm: 2015
11. Rilinda Lamllari (2013), Extending a Methodology for Migration of the Database Layer to the Cloud, Considering Relational Database Schema Migration to NoSQL. Master Thesis No. 3460, Institute of Architecture of Application Systems, University of Stuttgart, pp 38 Sách, tạp chí
Tiêu đề: Extending a Methodology for Migration of the Database Layer to the Cloud, Considering Relational Database Schema Migration to NoSQL
Tác giả: Rilinda Lamllari
Năm: 2013
12. S. S. Anand (2010), Netflixs Transition to High-Availability Storage System, Netflix, Inc Sách, tạp chí
Tiêu đề: Netflixs Transition to High-Availability Storage System
Tác giả: S. S. Anand
Năm: 2010
13. TPC (2014), TPC Benchmark TM H Standard Specification, Revision 2.17.1 Sách, tạp chí
Tiêu đề: TPC Benchmark"TM" H Standard Specification
Tác giả: TPC
Năm: 2014
3. Introduction to MongoDB (August-2015), http://docs.mongodb.org/manual/core/introduction 4. Introduction to mongify (July – 2015), http://mongify.com Link
5. J. Patel. Cassandra Data Modeling Best Practices, Part 1 (July-2015), http://www.ebaytechblog.com/2012/07/16/cassandra-data-modeling-best-practices-part-1/ Link

TỪ KHÓA LIÊN QUAN

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN

w