ĐẠI HỌC QUỐC GIA TP. HỒ CHÍ MINH
TRƯỜNG ĐẠI HỌC KHOA HỌC TỰ NHIÊN

LÊ HỒNG DANH
MSHV: 16C12005

ĐỒ ÁN MÔN HỌC
CƠ SỞ DỮ LIỆU NÂNG CAO
ĐỀ TÀI:
SURVEY OF NEWSQL DATABASE SYSTEM

TP. HỒ CHÍ MINH - 2017


ĐẠI HỌC QUỐC GIA TP. HỒ CHÍ MINH
TRƯỜNG ĐẠI HỌC KHOA HỌC TỰ NHIÊN

ĐỒ ÁN MÔN HỌC
CƠ SỞ DỮ LIỆU NÂNG CAO
ĐỀ TÀI:
SURVEY OF NEWSQL DATABASE SYSTEM

LÊ HỒNG DANH
MSHV: 16C12005

TP. HỒ CHÍ MINH - 2017


LỜI CẢM ƠN
---o0o--Tôi xin gửi lời cảm ơn chân thành và sự tri ân sâu sắc đối với các Thầy/cô của Trường
Đại học Khoa học Tự nhiên TP Hồ Chí Minh, đặc biệt là các Thầy/cô Khoa Công Nghệ

Thông tin và phòng Sau Đại học đã tạo điều kiện cho tôi được học môn “Cơ Sở Dữ Liệu
Nâng Cao” và tôi cũng xin chân thành cảm ơn Cô TS Nguyễn Trần Minh Thư đã tận tâm
truyền đạt những kiến thức quý báu về cơ sở dữ liệu nâng cao.
Trong quá trình học tập, cũng như là trong quá trình làm bài đồ án, khó tránh khỏi sai
sót, rất mong Thầy/cô bỏ qua. Đồng thời do trình độ lý luận cũng như kinh nghiệm thực
tiễn còn hạn chế nên bài đồ án không thể tránh khỏi những thiếu sót, tôi rất mong nhận
được ý kiến đóng góp Thầy/cô để tôi học thêm được nhiều kinh nghiệm và sẽ hoàn thành
tốt hơn các bài đồ án sắp tới.


MỤC LỤC
---o0o--TÓM LƯỢC ..................................................................................................................... 1
CHƯƠNG 1. GIỚI THIỆU .............................................................................................. 2
CHƯƠNG 2. LỊCH SỬ NGẮN GỌN CỦA DBMS VÀ ĐỘNG LỰC CỦA NEWSQL 3
CHƯƠNG 3. PHÂN LOẠI .............................................................................................. 6
3.1. Định nghĩa.............................................................................................................. 6
3.2. New Architectures ................................................................................................. 8
3.3. Transparent Sharding Middleware ...................................................................... 10
3.4. Database as a Service........................................................................................... 11
CHƯƠNG 4. TÍNH NĂNG CỦA NEWSQL ................................................................ 13
4.1. Khả năng truy vấn ................................................................................................ 14
4.2. Kiểm soát đồng thời ............................................................................................. 16
4.3. Bản sao ................................................................................................................. 17
4.4. Phân vùng ............................................................................................................ 19
4.5. Tính nhất quán ..................................................................................................... 22
4.6. Lưu trữ bộ nhớ chính ........................................................................................... 23
4.7. Phục hồi lỗi .......................................................................................................... 25
CHƯƠNG 5. KẾT LUẬN.............................................................................................. 29
TÀI LIỆU THAM KHẢO .............................................................................................. 31



1

TÓM LƯỢC
---o0o--Mặc dù các cơ sở dữ liệu quan hệ truyền thống vẫn được sử dụng trong một phạm
vi lớn các ứng dụng, gần đây chúng tôi đã chứng kiến sự bùng nổ về số lượng các cơ sở
dữ liệu mới được phát triển đặc biệt cho việc phục vụ dữ liệu lớn. Hiện nay các giải pháp
thay thế chính cho RDMBS là cơ sở dữ liệu NoSQL và NewSQL.
Trọng tâm chính của bài đồ án này khảo sát, so sánh và đánh giá một số cơ sở dữ
liệu NewSQL. Các cơ sở dữ liệu NoSQL được tạo ra như một phương tiện để cung cấp
tính sẳn sàng cao với giá phải trả là mất đặc điểm ACID cuả cơ sỡ dữ liệu quan hệ. Để
giải quyết vấn để này chúng tôi khảo sát và đánh giá NewSQL là hệ thống quản lý nhằm
cung cấp hiệu năng có thể mở rộng của NoSQL của các hệ thống xử lý giao dịch trực
tuyến OLTP trong khi vẫn duy trì đặc điểm ACID.


2

CHƯƠNG 1. GIỚI THIỆU
Trong thập kỷ qua, chúng ta đã chứng kiến một sự gia tăng nhanh chóng trong một
số loại khác nhau cơ sở dữ liệu. Nó liên quan đến sự phát triển của Internet, thiết bị di
động và điện toán đám mây. Tất cả các môi trường này áp đặt các yêu cầu mới cho việc
lưu trữ có hiệu quả và xử lý dữ liệu.
Để đối phó với những thách thức này, một số công ty duy trì các trung tâm dữ liệu
trong đó có các cụm với hàng ngàn máy móc thiết bị. Các cơ sở dữ liệu quan hệ cũ không
cung cấp một giải pháp tốt trong tình huống này, do đến mô hình dữ liệu được chuẩn hóa
và hỗ trợ đầy đủ ACID. Ngoài ra nó chỉ ra rằng cách tiếp cận phổ biến "một kích thước
phù hợp với tất cả" không còn giá trị cho kịch bản ứng dụng hiện tại. Ngược lại, trong
thực tế mới là thích hợp nhiều hơn để thiết kế các hệ thống dựa trên tính chất của các
ứng dụng và dữ liệu. Do đó, nhiều giải pháp cơ sở dữ liệu thay thế đã được thiết kế đặc

biệt để đáp ứng các nhu cầu đa dạng. Thuật ngữ NewSQL lần đầu tiên được sử dụng bởi
một tác giả trong một bài báo cáo phân tích kinh doanh năm 2011 thảo luận về sự nổi
lên của các hệ thống cơ sở dữ liệu mới như những thách thức các nhà cung cấp (Oracle,
IBM, Microsoft). Một câu hỏi đặt ra là liệu NewSQL là thật sự tốt hay không? Hay chỉ
là quảng cáo tiếp thị cho những dự án mà các công ty đang nghiên cứu về nó. Trong khi
đó cơ sở dữ liệu quan hệ (RDBMS) đã tồn tại hơn 4 thập kỉ và hiện đang còn rất nhiều
công ty đang sử dụng nó. NewSQL có đem lại lợi ích hay chỉ là phần cứng nâng cao rất
nhiều lần mà bây giờ các tắc nghẽn từ những năm trước không còn vấn đề. Để làm điều
này, trước tiên chúng ta thảo luận về lịch sử của RDBMS để hiểu hệ thống NewSQL đã
xuất hiện như thế nào. Sau đó tôi cung cấp một giải thích chi tiết về thuật ngữ NewSQL
là gì và các loại hệ thống khác nhau nằm ở định nghĩa này.


3

CHƯƠNG 2. LỊCH SỬ NGẮN GỌN CỦA DBMS VÀ ĐỘNG LỰC CỦA
NEWSQL
Các DBMS đầu tiên đã xuất hiện trên mạng vào giữa nhưng năm 1960, một trong những
phiên bản đầu tiên là IMS của IBM được xây dựng để theo dõi nguồn cung cấp và các
bộ phận kiểm kê cho các dự án thăm dò không gian của Saturn V and Apollo. Nó giúp
thể hiện ý tưởng rằng code của ứng dụng tách biệt khỏi phần dữ liệu. Điều này cho phép
các nhà phát triển viết ứng dụng chỉ tập trung vào phần truy cập và thao tác dữ liệu. IMS
sau đó được khai thác vào đầu năm 1970 và các DBMS đầu tiên ra đời như System R
của IBM và INGRES của Trường Đại học California. INGRES sớm được thông qua các
trường đại học khác cho hệ thống thông tin của họ và sau đó được thương mại hóa vào
cuối năm 1970. Khoảng thời gian đó Oracle phát triển phiên bản đầu tiên của DBMS
tương tự như thiết kế của System R. Các công ty khác được thành lập vào đầu những
năm 1980 nhằm tìm cách lặp lại thành công của các DBMS thương mại đầu tiên bao
gồm Sybase và Infomix. Mặc dù IBM chưa cung cấp System R cho công chúng, sau đó
phát hành một RDBMS mới (DB2) trong năm 1983 đã sử dụng một phần cơ sở mã của

System R.
Cuối năm 1980 và đầu năm 1990 đã tạo ra một DBMS mới được thiết kế để vượt qua sự
không phù hợp giữa mô hình quan hệ hướng đối tượng và các ngôn ngữ lập trình. Tuy
nhiên, những DBMS này không nhìn thấy sự chấp nhận rộng rãi của thị trường vì thiếu
một giao diện chuẩn như SQL. Nhưng nhiều ý tưởng từ họ cuối cùng đã được kết hợp
trong các DBMS quan hệ khi các nhà cung cấp chính thêm đối tượng và XML hỗ trợ
một thập niên sau đó, và một lần nữa trong tài liệu theo định hướng NoSQL trong hơn
hai thập kỷ sau đó.
Sự kiện nổi bật khác trong năm 1990 là sự khởi đầu của hai dự án DBMS mã nguồn mở.
MySQL bắt đầu ở Thụy Điển vào năm 1995 dựa trên hệ thống mSQL dựa trên ISAM


4

trước đó. PostgreSQL bắt đầu vào năm 1994 khi hai sinh viên tốt nghiệp của Berkeley
đã gỡ bỏ mã Postgres gốc dựa trên QUEL từ những năm 1980 để hỗ trợ SQL.
Từ năm 2000 sự xuất hiện các ứng dụng internet có nhiều yêu cầu về nguồn tài nguyên
hơn các ứng dụng từ những năm trước. Họ cần quy mô lớn để hỗ trợ số lượng lớn người
dùng đồng thời và thời gian thực. Những cơ sở dữ liệu cho các ứng dụng mới này luôn
luôn tồn tại nút thắt cổ chai bởi vì nhu cầu về tài nguyên lớn hơn nhiều so với những gì
DBMS và phần cứng có thể hỗ trợ vào thời điểm đó. Nhiều người đã cố gắng mở rộng
DBMS theo chiều dọc bằng cách di chuyển cơ sở dữ liệu đến một máy mới với phần
cứng tốt hơn. Điều này chỉ cải thiện hiệu suất rất nhiều và có giảm dần lợi nhuận. Hơn
nữa, di chuyển cơ sở dữ liệu từ máy này sang máy khác là một quá trình phức tạp và
thường đòi hỏi thời gian chết đáng kể không thể chấp nhận cho các ứng dụng trên nền
Web. Vượt qua vấn đề này, một số công ty tạo ra tùy chỉnh middleware để shader singlenode DBMSs trong một nhóm các máy tính ít tốn kém hơn. Các middleware này trình
bày một cơ sở dữ liệu hợp lý duy nhất để ứng dụng được lưu trữ trên nhiều nodes vật lý.
Khi ứng dụng phát các câu truy vấn đối với cơ sỡ dữ liệu này, middleware sẽ chuyển
hướng hoặc viết lại để phân phối thực hiện trên một hoặc nhiều nodes trong cluster. Các
node thực hiện các câu truy vấn này và sẽ gửi kết quả trở lại cho middleware, sau đó kết

hợp chúng tại thành một kết quả hoàn chỉnh duy nhất cho ứng dụng. Hai ứng dụng nổi
bật của cách tiếp cận middleware này là cụm dựa trên Oracle của eBay và cluster dựa
trên MySQL của Microsoft. Cách tiếp cận này sau đó đã được Facebook chấp nhận cho
cụm MySQL của họ mà vẫn được sử dụng ngày nay.
Sharding middleware hoạt động tốt cho các hoạt động đơn giản như đọc hoặc cập nhật
một bản ghi. Tuy nhiên, nó sẽ khó khăn hơn khi phải thực hiện các truy vấn cập nhật
nhiều bản ghi trong một phiên giao dịch hoặc kết nối nhiều bảng. Như vậy, những hệ
thống middleware này không hỗ trợ các hoạt động này. Ví dụ, middleware của eBay vào
năm 2002 đã yêu cầu các nhà phát triển của họ thực hiện tất cả các hoạt động liên kết


5

trong mã các ứng dụng. Cuối cùng, một số công ty đã chuyển từ sử dụng middleware và
phát triển các DBMS của họ. Có 3 động lực cho việc này: Đầu tiên là các hệ thống
RDBMS vào thời điểm đó tập trung vào tính nhất quán và hiệu suất. Nhưng phiên bản
này được đánh giá là không phù hợp với các ứng dụng dựa trên Web cần hỗ trợ số lượng
lớn và các hoạt động đồng thời. Thứ hai, người ta cho rằng có quá nhiều chi phí trong
việc sử dụng một DBMS đầy đủ MySQL như một kho dữ liệu “dumb”. Tương tự, người
cũng ta cho rằng mô hình quan hệ không phải là cách tốt nhất để đại diện cho một dữ
liệu của ứng dụng và sử dụng SQL là quá mức cần thiết cho các truy vấn tìm kiếm đơn
giản. Những vấn đề này hóa ra là nguồn gốc của sự thúc đẩy cho phong trào NoSQL vào
giữa đến cuối năm 2000. Khía cạnh quan trọng của các hệ thống NoSQL này là họ bỏ
qua đảm bảo giao dịch mạnh mẽ và mô hình quan hệ của các DBMS truyền thống để tạo
ra sự nhất quán cuối cùng và các mô hình dữ liệu thay thế (ví dụ: key/value, graphs,
documents). Bởi vì người ta tin rằng những khía cạnh này của các DBMS hiện có khả
năng mở rộng và đạt được sự sẵn sàng cao cần thiết để hỗ trợ các ứng dụng dựa trên
Web. Hai hệ thống nổi tiếng nhất theo sau tin tưởng này là BigTable của Google và
Dynamo của Amazon. Cả hai hệ thống này đều có sẵn bên ngoài công ty của họ lúc đầu
(mặc dù bây giờ là dịch vụ cloud), do đó các tổ chức khác tạo ra nguồn mở riêng của họ

nhân bản của chúng. Chúng bao gồm Facebook's Cassandra (dựa trên BigTable và
Dynamo) và Hbase của PowerSet (dựa trên BigTable). Những doanh nghiệp mới thành
lập đã tạo ra các hệ thống riêng của họ không nhất thiết phải là bản sao của hệ thống của
Google hoặc Amazon nhưng vẫn theo nguyên lý của NoSQL; nhiều nhất nổi tiếng trong
số này là MongoDB. Vào cuối những năm 2000, giờ đây đã có một bộ DBMS phân phối
có thể mở rộng và có thể mở rộng. Lợi thế của việc sử dụng một hệ thống NoSQL (hay
những người nghĩ) là các nhà phát triển có thể tập trung vào các khía cạnh của ứng dụng
có lợi cho kinh doanh hoặc tổ chức hơn là phải lo lắng về việc làm thế nào để mở rộng
hệ thống DBMS. Tuy nhiên, nhiều ứng dụng không thể sử dụng các hệ thống NoSQL
bởi vì họ không thể từ bỏ các yêu cầu giao dịch về tính nhất quán mạnh mẽ. Điều này


6

phổ biến đối với các hệ thống doanh nghiệp xử lý dữ liệu cao cấp (ví dụ: hệ thống xử lý
đơn hàng và tài chính). Một số tổ chức, đặc biệt là Google, đã phát hiện ra rằng các
DBMS của NoSQL khiến cho các nhà phát triển mất quá nhiều thời gian để viết mã để
xử lý dữ liệu không nhất quán và sử dụng các giao dịch làm cho chúng hiệu quả hơn. Vì
vậy, các lựa chọn duy nhất có sẵn cho các tổ chức này là mua một máy đơn node mạnh
hơn và để mở rộng quy mô DBMS theo chiều dọc, hoặc để phát triển middleware tùy
chỉnh riêng của họ để hỗ trợ giao dịch. Cả hai cách tiếp cận đều tốn kém và do đó không
phải là lựa chọn cho nhiều người. Đó là trong môi trường và động lực để phát triển một
hệ thống cơ sở dữ liệu NewSQL.
CHƯƠNG 3. PHÂN LOẠI
3.1. Định nghĩa
Thuật ngữ NewSQL có nhiều định nghĩa nhưng phổ biến nhất có 3 định nghĩa sau:
 Matt Asslet – 451 Group (April 4th, 2011)
NewSQL là các hệ thống cung cấp khả năng mở rộng và tính linh hoạt của NoSQL trong
khi vẫn giữ được hỗ trợ cho các truy vấn SQL và ACID hoặc để cải thiện hiệu suất cho
khối lượng công việc thích hợp.

 Michael stonebraker – blog@cacm (june 16th, 2011)
Một định nghĩa hẹp hơn cho việc triển khai hệ thống của NewSQL:
•

Sử dụng lock-free kiểm soát truy cập đồng thời của lược đồ

•

Sử dụng shared-nothing kiến trúc phân tán

•

Hỗ trợ truy vấn SQL

•

Hỗ trợ ACID cho các giao dịch

•

Hiệu năng cao cho mỗi node

•

Khả năng mở rộng cao


7

 Wikipedia article

NewSQL là một hệ thống quản lý cơ sở dữ liệu quan hệ hiện đại nhằm cung cấp hiệu
năng khả thi tương tự như các hệ thống NoSQL để xử lý giao dịch trực tuyến (OLTP)
trong khi vẫn đảm bảo duy trì ACID của một hệ thống cơ sở dữ liệu truyền thống.
Từ những định nghĩa trên ta có thể rút ra một nhận xét chung, các hệ thống này muốn
đạt được khả năng mở rộng của NoSQL nhưng vẫn giữ được mô hình quan hệ và hỗ trợ
giao dịch các DBMS kế thừa từ những năm 1970-1980. Điều này cho phép các ứng dụng
thực hiện một số lượng lớn các giao dịch đồng thời để nhập thông tin mới và sửa đổi
trạng thái của cơ sở dữ liệu bằng cách sử dụng SQL. Nếu một ứng dụng sử dụng cơ sở
dữ liệu NewSQL thì các lập trình viên phát triển ứng dụng không cần phải viết các bản
cập nhật tính nhất quán như họ đã làm với NoSQL. Các ứng dụng được nhắm mục tiêu
bởi các DBMS của NewSQL được mô tả như là thực hiện các giao dịch đọc-ghi rằng là
short-lived, chạm vào một tập con nhỏ của dữ liệu bằng cách sử dụng các tra cứu chỉ
mục và lặp đi lặp lại (tức là, thực hiện các truy vấn tương tự với các đầu vào khác nhau).
Tất cả các DBMS mà tôi phân loại là NewSQL trong phần tiếp theo thực sự chia sẻ các
thuộc tính này.
Với định nghĩa trên, bây giờ ta kiểm tra bối cảnh của các cơ sở dữ liệu NewSQL ngày
nay. Để đơn giản hóa phân tích này, tôi sẽ dựa trên các khía cạnh nổi bật của chúng. Ba
loại mà tôi coi rằng là đại diện tốt nhất cho các hệ thống NewSQL. Một là các hệ thống
mới được xây dựng từ nền tảng sử dụng một kiến trúc mới (New Architectures). Hai là
middleware thực hiện lại cơ sở hạ tầng sharding tương tự đã được google phát triển trong
những năm 2000 (Transparent Sharding Middleware) và dịch vụ cơ sở dữ liệu (Database
as a serive) từ các nhà cung cấp điện toán đám mây cũng dựa trên nền tảng kiến trúc
mới. Các ví dụ phổ biến nhất trong số này là thay thế công cụ lưu trữ InnoDB mặc định
của MySQL (ví dụ: TokuDB, ScaleDB, Akiban, deepSQL). Lợi ích của việc sử dụng
công cụ mới là tổ chức có thể đạt được hiệu suất tốt hơn mà không thể thay đổi bất kỳ


8

điều gì trong ứng dụng của họ mà vẫn tận dụng được môi trường của DBMS (ví dụ:

tools, APIs). Chúng tôi thừa nhận rằng những lợi ích từ việc chuyển đổi từ công cụ
InnoDB định hướng lưu trữ dạng hàng sang lưu trữ dạng cột cho khối lượng công việc
OLAP là đáng kể hơn (ví dụ: Infobright, InfiniDB).
3.2. New Architectures
Trong phần này chứa các hệ thống DBMS thú vị nhất vì chúng là các DBMS được xây
dựng từ đầu. Tức là thay vì mở rộng của một hệ thống hiện có (ví dụ như Hekaton của
Microsoft cho SQL Server), chúng được thiết kế từ một mã mới mà không có bất kỳ hệ
thống kế thừa nào. Tất cả các DBMS trong phần này dựa trên kiến trúc phân tán hoạt
động trên các tài nguyên chia sẽ sharding-nothing và chứa các thành phần hổ trợ kiểm
soát đồng thời nhiều nodes, khả năng chịu lỗi, điều khiển luồng và xử lý truy vấn phân
tán. Ưu điểm của việc sử dụng một DBMS mới được xây dựng để thực hiện phân phối
là tất cả các bộ phận của hệ thống có thể được tối ưu hóa cho môi trường đa node. Điều
này bao gồm những thứ như trình tối ưu hóa truy vấn và giao thức truyền thông giữa các
node. Ví dụ: hầu hết các DBMS của NewSQL đều có thể gửi dữ liệu truy vấn nội bộ trực
tiếp giữa các node chứ không phải định tuyến chúng tới vị trí trung tâm như với một hệ
thống trung gian. Các DBMS trong loại này đều quản lý bộ nhớ chính của nó có thể trên
đĩa hoặc trong bộ nhớ. Điều này có nghĩa là DBMS chịu trách nhiệm phân phối cơ sở dữ
liệu trên các tài nguyên của nó bằng một công cụ tùy chỉnh thay vì dựa vào hệ thống tệp
phân phối để lưu trữ (ví dụ: HDFS) hoặc tổ chức lưu trữ (ví dụ: Apache Ignite). Đây là
một khía cạnh quan trọng của chúng vì nó cho phép DBMS "gửi truy vấn tới dữ liệu"
chứ không phải là "đưa dữ liệu vào truy vấn", dẫn đến lưu lượng truy cập mạng ít hơn
đáng kể kể từ khi truyền truy vấn thường ít lưu lượng truy cập mạng hơn là có để truyền
dữ liệu. Quản lý lưu trữ riêng của họ cũng cho phép một DBMS sử dụng các chương
trình sao chép tinh vi hơn những gì có thể với lược đồ nhân rộng dựa trên khối được sử
dụng trong HDFS. Nói chung, nó cho phép những DBMS này đạt được hiệu năng tốt
hơn so với các hệ thống khác được xếp lớp trên các công nghệ hiện có khác; ví dụ này


9


bao gồm các hệ thống "SQL on Hadoop" như Trafodion và Splice Machine cung cấp các
giao dịch trên đầu trang của Hbase. Do đó, tôi tin rằng các hệ thống như vậy không nên
được coi là NewSQL. Nhưng có những nhược điểm để sử dụng một DBMS dựa trên một
kiến trúc mới. Quan trọng nhất là nhiều tổ chức đang thận trọng áp dụng các công nghệ
quá mới và không được kiểm tra với một cơ sở lắp đặt lớn. Điều này có nghĩa là số người
có kinh nghiệm trong hệ thống nhỏ hơn nhiều so với tổ chức sẽ có thể mất quyền truy
cập vào các công cụ báo cáo và quản lý hiện hành. Một số DBMS, như Clustrix và
MemSQL, tránh vấn đề này bằng cách duy trì khả năng tương thích với giao thức
MySQL.
Ví dụ một vài hệ thống cơ sở dữ liệu NewSQL trong loại này:
•

VoltDB - một RDBMS mới được thiết kế cho hiệu suất cao (mỗi node) cũng như
khả năng mở rộng. VoltDB là một hệ thống mã nguồn mở (giấy phép AGPL v3.0)
được viết bằng Java và C + +.

•

NuoDB - một cơ sở dữ liệu phân tán tương thích SQL. Nó được định nghĩa như
là "client / cơ sở dữ liệu quan hệ đám mây". NuoDB là một hệ thống "nguồn
đóng". Nó là có sẵn trong thị trường dịch vụ Web Amazon (AWS) như một dịch
vụ, như một thiết bị và như là một phần mềm độc lập.

•

ClustrixDB là một cơ sở dữ liệu SQL được xây dựng cho các ứng dụng quy mô
lớn và phát triển nhanh, đây là cơ sở dữ liệu NewSQL mở rộng cho đám mây.
ClustrixDB duy nhất cho phép phân tích thời gian thực trên dữ liệu hoạt động trực
tiếp của bạn với các xử lý song song.


•

MemSQL là một nền phân tích thời gian thực giúp các công ty truy vấn dữ liệu
lớn một cách nhanh chóng và thích ứng với các điều kiện kinh doanh thay đổi.

•

CockroachDB, Google Spanner, H-Store, HyPer,…


10

3.3. Transparent Sharding Middleware
Hiện nay có các sản phẩm cung cấp cùng loại sharding middleware mà eBay, Google
hay Facebook và các công ty khác phát triển trong năm 2000. Chúng cho phép một tổ
chức chia tách một cơ sở dữ liệu thành nhiều mảnh được lưu trữ trong một nhóm các
DBMS. Sharding khác với công nghệ liên kết cơ sở dữ liệu của những năm 1990. Vì mỗi
node chạy cùng một DBMS, chỉ có một phần của cơ sở dữ liệu tổng thể và không được
truy cập và cập nhật một cách độc lập bởi các ứng dụng riêng biệt. Thành phần
middleware tập trung các truy vấn, điều phối các giao dịch, cũng như quản lý việc sắp
xếp dữ liệu, sao chép và phân vùng trên các node. Có một lớp thêm vào được cài đặt trên
mỗi node DBMS liên lạc với middleware. Thành phần này có trách nhiệm thực hiện các
truy vấn thay mặt cho middleware tại các node cục bộ của nó và trả về kết quả. Ưu điểm
chính của việc sử dụng một middleware sharing chúng thường là một sự thay thế cho
một ứng dụng đang sử dụng một DBMS. Các nhà phát triển không cần phải thực hiện
bất kỳ thay đổi nào đối với ứng dụng của họ để sử dụng cơ sở dữ liệu single-node DBMS.
Mặc dù middleware làm cho một tổ chức dễ dàng mở rộng cơ sở dữ liệu của họ trên
nhiều node, các hệ thống như vậy vẫn phải sử dụng một DBMS truyền thống trên mỗi
node (ví dụ như MySQL, Postgres, Oracle).
Ví dụ một vài hệ thống trong loại này:

•

ScaleArc – là hệ thống nằm giữa các ứng dụng và cơ sở dữ liệu, đơn giản hóa quá
trình kích hoạt các hoạt động bởi vì nó định hướng lưu lượng truy cập vào các
cụm cơ sở dữ liệu phân tán thay cho các ứng dụng, không thay đổi code, đảm bảo
tính sẳn sàng cho các ứng dụng.

•

ScaleBase có thể là một phần quan trọng đối với các dữ liệu có hiệu suất cao, đàn
hồi và ứng dụng nhiều quá trình trong public cloud. ScaleBase có nhiều cải tiến
về cơ sở dữ liệu MySQL đã được chứng minh và trưởng thành cao và cung cấp


11

các lợi ích cho dữ liệu lớn và nhanh. Tính năng mở rộng theo chiều ngang rất cần
thiết (scale-out) được kết hợp ngầm trong ScaleBase với kỹ thuật sharding.
•

AgilData Scalable Cluster cho MySQL là một giải pháp sharding dựa trên agent
tạo cho ứng dụng thấy nhiều cơ sở dữ liệu như một cơ sở dữ liệu. Đây là sản phẩm
phần mềm đầu tiên của ngành công nghiệp cho phép áp dụng cơ sở dữ liệu
sharding vào các ứng dụng và cơ sở dữ liệu hiện có ít hoặc không có sự sửa đổi
đối với mã ứng dụng hiện có.

•

MariaDB MaxScale là một proxy cơ sở dữ liệu mở rộng tính khả dụng, khả năng
mở rộng và bảo mật cao của MariaDB Server đồng thời đơn giản hóa việc phát

triển ứng dụng bằng cách tách nó ra khỏi hạ tầng cơ sở dữ liệu. MariaDB
MaxScale được thiết kế với kiến trúc mở rộng để hỗ trợ các trình cắm thêm, mở
rộng chức năng của nó ngoài cân bằng tải trong suốt để trở thành ví dụ như một
bức tường lửa cơ sở dữ liệu. MariaDB MaxScale có thể được cấu hình để chuyển
tiếp các yêu cầu về cơ sở dữ liệu và sửa đổi các phản hồi về cơ sở dữ liệu dựa trên
các yêu cầu về kinh doanh và kỹ thuật - ví dụ như để che dấu các dữ liệu nhạy
cảm hoặc các lần đọc quy mô.

3.4. Database as a Service
Các nhà cung cấp điện toán đám mây cung cấp các sản phẩm Database-as-a-service
(DBaaS) của NewSQL. Với các dịch vụ này, các tổ chức không phải duy trì DBMS trên
phần cứng riêng của họ hoặc trên máy ảo cloud-hosted(VM). Thay vào đó, nhà cung cấp
DBaaS chịu trách nhiệm duy trì cấu hình vật lý của cơ sở dữ liệu, bao gồm điều chỉnh
hệ thống (ví dụ kích thước vùng đệm), sao chép và sao lưu. Khách hàng được cung cấp
một URL kết nối tới DBMS, cùng với dashboard hoặc API để điều khiển hệ thống. Khách
hàng của DbaaS trả tiền theo cách sử dụng tài nguyên mà ứng dụng của họ yêu cầu.
Trong phần này tôi xét các sản phẩm DBaaS dựa trên kiến trúc mới như NewSQL. Ví
dụ đáng chú ý nhất là Aurora của Amazon cho MySQL RDS. Tính năng phân biệt của
nó trên InnoDB là nó sử dụng một trình quản lý lưu trữ có cấu trúc để cải tiến song song


12

quá trình I/O. Amazon Aurora là một cơ sở dữ liệu quan hệ tương đương MySQL và
PostgreSQL được xây dựng cho đám mây, kết hợp hiệu suất và tính sẵn sàng của các cơ
sở dữ liệu thương mại cao cấp với tính đơn giản và hiệu quả về chi phí của các cơ sở dữ
liệu mã nguồn mở. Ngoài ra còn có các công ty không duy trì trung tâm dữ liệu riêng mà
chỉ bán phần mềm DBaaS chạy trên nền tảng public cloud. ClearDB cung cấp DBaaS
tùy chỉnh có riêng họ có thể được triển khai trên tất cả nền tảng đám mây lớn. Loại này
còn có tên gọi là SQL engines[2]. Nó là động cơ lưu trữ được tối ưu hóa cao cho SQL.

Các hệ thống này cung cấp giao diện lập trình tương tự như SQL, nhưng có quy mô tốt
hơn các công cụ được xây dựng sẵn như InnoDB.

Hình 1. ClearDB


13

CHƯƠNG 4. TÍNH NĂNG CỦA NEWSQL

Hình 2. Workload Characterization
Hình 2 bao gồm hai trục: ngang cho biết một ứng dụng tập trung vào đọc hay tập trung
vào ghi; dọc cho biết ứng dụng có thực hiện các thao tác đơn giản (đọc hoặc ghi một vài
mục) hoặc các thao tác phức tạp (đọc hoặc ghi hàng nghìn mục) ; ví dụ: OLTP truyền
thống tập trung vào các hoạt động đơn giản, trong khi kho dữ liệu (data warehouse) tập
trung vào các hoạt động phức tạp. Các ứng dụng mạng xã hội liên quan đến các hoạt
động chủ yếu là đơn giản mà còn là một sự cân bằng trong việc đọc và viết. Do đó, con
số này nên được xem như là một sự liên tục trong cả hai hướng, với bất kỳ ứng dụng
nhất định nào đó ở giữa. Các công cụ thương mại chính và triển khai mã nguồn mở của


14

mô hình quan hệ được định vị là các hệ thống "một kích cỡ phù hợp với tất cả"; nghĩa là
việc triển khai của chúng được cho là phù hợp với tất cả các vị trí trong hình.
Tiếp theo, chúng ta sẽ thảo luận về các tính năng của hệ thống cơ sở dữ liệu NewSQL
để hiểu những gì là mới lạ trong các hệ thống này.
4.1. Khả năng truy vấn
Hầu hết các cơ sở dữ liệu NewSQL đều hổ trợ ngôn ngữ SQL như là một trong những
tính năng chính của nó. Tuy nhiên NuoDB được xem là tương thích với SQL, trong khi

VoltDB có nhiều hạn chế. Ví dụ: nó không thể sử dụng mệnh đề “having”, các bảng
không thể kết nối với chính nó và bảng tham gia phải được phân vùng trên cùng một giá
trị. Trong bối cảnh khả năng truy vấn, bên cạnh hỗ trợ SQL điều quan trọng là phải phân
tích hỗ trợ Rest API và MapReduce.
API REST là một API tuân thủ các các nguyên tắc của REST. REST là một kiểu kiến
trúc sử dụng các cuộc gọi HTTP đơn giản để liên lạc giữa các máy với nhau. Sử dụng
REST nghĩa là các cuộc gọi API sẽ dựa trên tin nhắn và dựa vào tiêu chuẩn HTTP.
MapReduce là một mô hình lập trình song song cho bộ xử lý bộ dữ liệu lớn được giới
thiệu bởi Google, thường được sử dụng để phân phối máy tính trên các cụm máy tính.
Trong mô hình MapReduce, người dùng xác định tính toán bằng hai giai đoạn là Map và
Reduce:
 Giai đoạn Map: Trong giai đoạn map, MapReduce lấy dữ liệu đầu vào và cấp dữ
liệu cho mapper.
 Giai đoạn Reduce: Trong giai đoạn reduce, reduce sẽ xữ lý tất cả các dữ liệu đầu
ra từ mapper và đạt đến kết quả cuối cùng. Nói một cách đơn giản, mapper có
nghĩa là lọc và biến đổi đầu vào thành cái gì đó mà reduce có thể tổng hợp.


15

Hình 3. MapReduec excecution overview
Điều quan trọng cần chú ý là thư viện MapReduce nằm bên dưới sẽ tự động tính toán và
xử lý các vấn đề phức tạp như phân phối dữ liệu, cân bằng tải và khả năng chịu lỗi. Bảng
1. Tóm tắt khả năng truy vấn của VoltDB và NuoDB.
NewSQL

Rest

Query


Database

API

Language

VoltDB

Có

SQL

Other API

MapReduce
Support

CLI và API bằng các ngôn

Không

ngữ khác nhau. Hỗ trợ JDBC
NuoDB

Không

SQL

CLI và trình điều khiển cho
hầu hết các API truy cập dữ

liệu thông thường (JDBC,
ODBC, ADO.NET). Cung cấp
hỗ trợ C ++

Không


16

Bảng 1: Khả năng truy vấn

4.2. Kiểm soát đồng thời
Kiểm soát truy cập đồng thời là một chủ đề quan tâm đặc biệt đến các cơ sở dữ liệu
NewSQL, vì chúng thường cần phải chứa một số lượng lớn người dùng có quyền truy
cập song song với nguồn dữ liệu. Các hệ thống cơ sở dữ liệu quan hệ (RDBMS) sử dụng
chiến lược pessimistic đồng thời với truy cập độc quyền trên một tập dữ liệu. Các giao
thức điều khiển đồng thời (pessimistic locking) cho rằng hai hoặc nhiều người dùng đồng
thời cố gắng cập nhật cùng một bộ (đối tượng hoặc record) cùng một lúc. Để ngăn chặn
tình huống này một khóa được đặt vào đối tượng truy cập, do đó truy cập đọc quyền đảm
bảo cho hoạt động duy nhất của người dùng, các người dùng khác truy cập vào cùng một
dữ liệu sẽ phải chờ cho đến khi kết thúc công việc. Những chiến lược này có thể phù hợp
nếu chi phí khóa thấp. Tuy nhiên, trong các cụm cơ sở dữ liệu được phân phối trên các
khoảng cách địa lý rộng lớn, các giao thức kiểm soát đồng thời pessimistic có thể dẫn
đến sự suy giảm hiệu suất, đặc biệt các ứng dụng phải hỗ trợ mức yêu cầu đọc cao. Mặt
khác các giao thức điều khiển đồng thời pessimistic (or pessomistic locking) có thể xung
đột. Do đó, mỗi giao dịch phải kiểm tra xem các giao dịch khác có bất kỳ sửa đổi mâu
thuẩn trên cùng một đối tượng dữ liệu. Nếu xác định các xung đột giao dịch sẽ được thu
hồi. Chiến lược này có thể hoạt động tốt nếu cập nhật ít, và do đó cơ hội cho mâu thuẫn
tương đối thấp. Trong trường hợp này, việc quay trở lại sẽ ít tốn hơn để khóa dữ liệu độc
quyền như trong các giao thức pessimistic locking. Một số cơ sở dữ liệu, bao gồm

NuoDB, thực hiện đồng thời nhiều phiên bản kiểm soát - MVCC [Bernstein và Goodman
1983]. Trong giao thức này, nhiều phiên bản của cùng một đối tượng dữ liệu được lưu
trữ, nhưng chỉ một đối tượng được đánh dấu là hiện tại, tất cả các phần còn lại được đánh
dấu là cũ. Sử dụng MVCC, việc đọc có thể thấy dữ liệu như khi bắt đầu đọc, trong khi


17

một quá trình đồng thời có thể thực hiện thao tác ghi trên cùng một đối tượng dữ liệu
trong thời gian chờ đợi. Vì vậy, truy cập đồng thời không được quản lý bằng khóa nhưng
bằng cách tổ chức của nhiều phiên bản được sắp xếp theo thứ tự thời gian không thể thay
đổi. Điều quan trọng cần lưu ý là MVCC tạo ra nhiều yêu cầu về không gian như nhiều
các phiên bản được lưu giữ song song. Vì vậy, thông thường để làm việc với MVCC cần
thiết để sử dụng một bộ sưu tập nháp mà không còn cần các phiên bản cần thiết và một
số thuật toán giải quyết xung đột để đối phó với sự không nhất quán. Thực tế này làm
tăng sự phức tạp của hệ thống quản lý cơ sở dữ liệu. Một số cơ sở dữ liệu NewSQL cũng
áp dụng các cách tiếp cận sáng tạo này để điều khiển đồng thời. Ví dụ, VoltDB giả định
rằng toàn bộ cơ sở dữ liệu có thể phù hợp với bộ nhớ, có nghĩa là có đủ bộ nhớ và các
giao dịch là short-lived. Dựa trên các giả định này, các giao dịch được thực hiện tuần tự
trong một môi trường không khóa, một luồng. Bảng 2 tóm tắt các cơ chế kiểm soát đồng
thời được sử dụng trong cơ sở dữ liệu VoltDB và NuoDB.
Database

Cơ chế kiểm soát truy xuất đồng thời

VoltDB

Mô hình đơn luồng, không kiểm soát đồng thời

NuoDB


MVCC

Bảng 2. Kiểm soát đồng thời
4.3. Bản sao
Sao chép dữ liệu là một chiến lược quan trọng để tăng khả năng mở rộng, cải thiện hiệu
suất, cân bằng tải, bên cạnh đó mang lại độ tin cậy tốt hơn và khả năng chịu lỗi. Có 2
loại sao chép: master-slave và master-master replication. Bảng sao master-slave là một
lược đồ mà một node duy nhất được định nghĩa là master và đây là node duy nhất chấp
nhận và xử lý yêu cầu ghi. Do đó, những thay đổi được truyền từ node master đến các
node slave. Trong lược đồ master-master, nhiều node có thể xử lý các yêu cầu ghi, sau
đó được truyền đến các node còn lại. Vì vậy, về cơ bản các master-slave việc truyền bá


18

chỉ hoạt động theo một hướng từ master đến slave, còn trong multi-master có thể xảy ra
theo nhiều hướng khác nhau. Hình 4 và Hình 5 cho thấy sự khác nhau giữa hai kiểu sao
chép master-slave và master-master.

Hình 4. Master-slave, tất cả ghi được thực hiện trong master và được truyền đến slave

Hình 5. Master-Master, hoạt động ghi có thể thực hiện trong master hoặc các node
khác


19

Hình 6. VoltDB bản sao
Các mô hình nhân rộng trong cơ sở dữ liệu NewSQL có thể được coi là masterless hoặc

multi-master, bởi vì bất kỳ node nào có thể nhận các bản cập nhật. Trong NuoDB, các
hàng (tuple) được đại diện bên trong như các đối tượng "trong bộ nhớ" mà không đồng
bộ liên lạc để nhân rộng các thay đổi trạng thái của chúng. VoltDB có một người quản
lý giao dịch / phiên làm việc đó chịu trách nhiệm tiếp nhận bản cập nhật và chuyển nó
tới tất cả các bản sao được thực hiện song song, tương đồng. Bảng 3 mô tả kỹ thuật
nhân bản khác nhau được sử dụng trong NuoDB và VoltDB
Database

Cơ chế sao chép

VoltDB

thực hiện cập nhật trên tất cả các bản sao cùng một lúc

NuoDB

nhân rộng các đối tượng phân tán

Bảng 3. Bản sao
4.4. Phân vùng
Khi chúng ta đối phó với dữ liệu lớn, trong khi số lượng lớn dữ liệu và tốc độ đọc và ghi
rất cao vượt quá khả năng duy nhất của một máy chủ, cơ sở dữ liệu phải được phân chia
thành các cụm. Các hệ thống quản lý cơ sở dữ liệu quan hệ truyền thống (RDBMS)


20

thường không hỗ trợ khả năng mở rộng theo chiều ngang vì mô hình dữ liệu bình thường
và các thuộc tính ACID. Do đó nhân đôi số lượng máy chủ trong một cluster RDBMS
không tăng gấp đôi hiệu suất. Vấn đề này là một trong những lý do tại sao những người

dùng web đa phần sử dụng Google, Amazon và Facebook bắt đầu phát triển các hệ thống
lưu trữ dữ liệu của riêng mình, được thiết kế theo chiều ngang và do đó đáp ứng các yêu
cầu rất cao về hiệu suất các ứng dụng Web.
Có rất nhiều kỹ thuật phân vùng dữ liệu được sử dụng bởi các hệ thống cơ sở dữ liệu
khác nhau. Hầu hết các cơ sở dữ liệu NewSQL thực hiện một số loại ngang phân vùng
hoặc sharding, bao gồm việc lưu trữ bộ bộ đôi (hàng) vào các phân đoạn hoặc mảnh
khác nhau. Hai chiến lược chính liên quan đến phân vùng theo chiều ngang là:
Phân vùng theo dải: chiếc lược này phân phối bộ dữ liệu tới các phân vùng nằm trên
các máy chủ khác nhau dựa trên các phạm vi của khóa phân vùng. Ban đầu máy chủ
định tuyến chia tách toàn bộ tập dữ liệu theo dải khóa của chúng. Sau đó, mỗi node đều
có trách nhiệm giải trình để lưu trữ và đọc/ghi của một phạm vi cụ thể.
Hợp nhất hashing: chiến lược này cung cấp sự sẵn có cao hơn và cấu trúc cụm đơn
giản hơn so với phân vùng dải. Bố cục hợp nhất hoạt động như sau: bộ dữ liệu được
biểu diễn dưới dạng một vòng tròn, được chia thành một số dải bằng nhau đến một số
node sẳn có, và mỗi nút được ánh xạ tới một điểm tương ứng trên vòng.


21

Hình 7. Consistent Hashing example, with three nodes.
VoltDB sử dụng một cách tiếp hashing phù hợp, trong đó mỗi bảng được phân chia
bằng cách sử dụng một khóa duy nhất và bộ được phân phối giữa các node. Các thủ tục
lưu sẵn có thể được thực hiện trên một phân vùng hoặc trên tất cả chúng, do người dùng
chỉ định. Mặt khác, NuoDB sử dụng một cách tiếp cận hoàn toàn khác nhau cho phân
vùng dữ liệu. NuoDB sử dụng một số quản lý lưu trữ (SM) và quản lý giao dịch (TM).
Các SM là các node chịu trách nhiệm lưu trữ dữ liệu, trong khi các TM là các node xử
lý các truy vấn. Mỗi SM có một bản sao hoàn chỉnh của toàn bộ dữ liệu, trong đó có
nghĩa là không có phân vùng xảy ra trong SM. Tuy nhiên, khóa-giá trị cơ bản lưu trữ
được sử dụng bởi các SM có thể phân vùng dữ liệu của chính nó, mặc dù điều này là
không kiểm soát được cũng không thể xem được bởi người dùng. Bảng 4. mô tả kỹ

thuật phân vùng khác nhau được sử dụng trong NuoDB và VoltDB.

Database

Cơ chế phân chia

VoltDB

Consistent hashing. Người dùng xác định liệu các thủ tục được lưu trữ
nên chạy trên một máy chủ duy nhất hoặc trên tất cả các máy chủ