luận văn: cơ sở dữ liệu trên bộ nhớ (in memory DB) và ứng dụng trong hệ thống phần mềm cần xử lý cơ sở dữ liệu hiệu năng cao

luận văn: cơ sở dữ liệu trên bộ nhớ (in memory DB) và ứng dụng trong hệ thống phần mềm cần xử lý cơ sở dữ liệu hiệu năng cao luận văn: cơ sở dữ liệu trên bộ nhớ (in memory DB) và ứng dụng trong hệ thống phần mềm cần xử lý cơ sở dữ liệu hiệu năng cao luận văn: cơ sở dữ liệu trên bộ nhớ (in memory DB) và ứng dụng trong hệ thống phần mềm cần xử lý cơ sở dữ liệu hiệu năng cao

ĐẠI HỌC QUỐC GIA HÀ NỘI

VIỆN CÔNG NGHỆ THÔNG TIN

HOÀNG TRÍ NHÂN

CƠ SỞ DỮ LIỆU TRÊN BỘ NHỚ (IN-MEMORY DB)

VÀ ỨNG DỤNG TRONG HỆ THỐNG PHẦN MỀM CẦN XỬ LÝ CƠ SỞ DỮ LIỆU HIỆU NĂNG CAO

LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN

Hà Nội, 2013

ĐẠI HỌC QUỐC GIA HÀ NỘI

VIỆN CÔNG NGHỆ THÔNG TIN

HOÀNG TRÍ NHÂN

CƠ SỞ DỮ LIỆU TRÊN BỘ NHỚ (IN-MEMORY DB)

VÀ ỨNG DỤNG TRONG HỆ THỐNG PHẦN MỀM CẦN XỬ LÝ CƠ SỞ DỮ LIỆU HIỆU NĂNG CAO

Ngành: Công nghệ thông tin

Chuyên ngành: Quản lý hệ thống thông tin

Mã số: Chuyên ngành đào tạo thí điểm

LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN

HƯỚNG DẪN KHOA HỌC: TS ĐINH VĂN DŨNG

Hà Nội, 2013

LỜI CAM ĐOAN

Tôi xin cam đoan đây là công trình nghiên cứu của riêng tôi Các số liệu đã nêu trong luận văn có nguồn gốc rõ ràng, kết quả của luận văn là trung thực và chưa được

ai công bố trong bất kỳ công trình nào khác

Tác giả Luận văn

Hoàng Trí Nhân

LỜI CẢM ƠN

Để hoàn thành luận văn này, bên cạnh sự nỗ lực của bản thân, tôi đã nhận được rất nhiều sự giúp đỡ, động viên và hướng dẫn của các thầy cô giáo, bạn bè, đồng nghiệp và gia đình trong suốt khoá học cũng như thời gian nghiên cứu đề tài luận văn

Tôi xin bày tỏ lòng biết ơn chân thành tới Tiến sĩ Đinh Văn Dũng – Viện CNTT – ĐHQG HN, người đã tận tình hướng dẫn và giúp đỡ tôi trong quá trình nghiên cứu

Đây là một đề tài liên quan đến lĩnh vực Cơ sở dữ liệu trên bộ nhớ, lĩnh vực còn khá mới mẻ ở Việt Nam Vì vậy, luận văn không thể tránh khỏi thiếu sót và hạn chế nhất định Tôi rất mong nhận được ý kiến đóng góp của mọi cá nhân, tổ chức quan tâm đến đề tài, để đề tài được hoàn thiện hơn nữa

Xin chân thành cảm ơn!

Hà Nội, tháng 12 năm 2013

MỤC LỤC

LỜI CAM ĐOAN 1

LỜI CẢM ƠN 2

MỤC LỤC 3

DANH MỤC CÁC TỪ VIẾT TẮT 4

DANH MỤC BẢNG, BIỂU 5

DANH MỤC HÌNH VẼ 6

MỞ ĐẦU 7

Chương 1: CƠ SỞ LÝ LUẬN VỀ CƠ SỞ DỮ LIỆU TRÊN BỘ NHỚ 10

I.1 Tình hình nghiên cứu IMDB 10

I.2 Nhu cầu thực tế và khả năng áp dụng 14

I.3 Kết luận chương 1 15

Chương 2: CƠ SỞ KHOA HỌC VỀ CƠ SỞ DỮ LIỆU TRÊN BỘ NHỚ 16

II.1 Khái niệm IMDB 16

II.2 Các vấn đề kỹ thuật của IMDB 16

II.3 So sánh với các công nghệ cạnh tranh 25

II.4 Ưu nhược điểm của IMDB 29

II.5 Kết luận chương 2 30

Chương 3: CÁC SẢN PHẨM CƠ SỞ DỮ LIỆU TRÊN BỘ NHỚ 31

III.1 Các sản phẩm thương mại 31

III.2 Các sản phẩm mã nguồn mở 41

III.3 So sánh các sản phẩm 43

III.4 Kết luận chương 3 45

Chương 4: THỬ NGHIỆM CƠ SỞ DỮ LIỆU TRÊN BỘ NHỚ 46

IV.1 Tổng quát lớp bài toán áp dụng 46

IV.2 Mô hình áp dụng 47

IV.3 Thử nghiệm và kết quả 50

IV.4 Kết luận chương 4 58

KẾT LUẬN VÀ HƯỚNG NGHIÊN CỨU TIẾP THEO 59

1 Kết luận 59

2 Hướng nghiên cứu tiếp theo 59

TÀI LIỆU THAM KHẢO 60 PHỤ LỤC P-1

1 Phụ lục 1 – Cài đặt cấu hình Oracle TimesTen P-1

2 Phụ lục 2 – Một số lệnh quản trị TimesTen cơ bản P-13

3 Phụ lục 3 – Kết nối tới TimesTen bằng Java P-14

DANH MỤC CÁC TỪ VIẾT TẮT

IMDB In-memory database Cơ sở dữ liệu trên bộ nhớ

DB Database Cơ sở dữ liệu

DBMS Database Management System Hệ quản trị cơ sở dữ liệu CNTT Công nghệ thông tin Công nghệ thông tin CSDL Cơ sở dữ liệu Cơ sở dữ liệu

DANH MỤC BẢNG, BIỂU

Bảng II.1 – Bảng so sánh CSDL dựa trên ổ cứng và IMDB 16

Bảng III.1 – Bảng so sánh đặc điểm chức năng các phần mềm IMDB 43

Bảng III.2 – Bảng so sánh hiệu năng các phần mềm IMDB 45

Bảng IV.1 – Bảng thống kê thời gian xử lý một bản ghi cước 55

Bảng IV.2 – Lựa chọn TimesTen 55

Bảng IV.3 – Lựa chọn tính năng TimesTen 56

Bảng IV.4 – So sánh response time giữa TimesTen và Oracle của CC 57

Bảng IV.5 – So sánh response time giữa TimesTen và Oracle của Rating 58

DANH MỤC HÌNH VẼ

Hình II.1 – Kiến trúc disk-based RDB 18

Hình II.2 – Kiến trúc IMDB 20

Hình II.3 – So sánh mô hình xử lý SQL của disk-based DB và IMDB 21

Hình II.4 – Mô hình chung tính năng Replication 25

Hình II.5 – Luồng dữ liệu luân chuyển trong DBMS truyền thống 26

Hình II.6 – Hadoop và Hbase 28

Hình III.1 – Ví dụ cache grid 32

Hình III.2 – Ví dụ cache group 33

Hình III.3 – Kiến trúc TimesTen IMDB 34

Hình III.4 – Kiến trúc IBM solidDB 36

Hình III.5 – Kiến trúc mức cao của SQLServer 2014 40

Hình III.6 – Hiệu năng Oracle TimesTen 44

Hình III.7 – Hiệu năng IBM solidDB 45

Hình IV.1 – Mô hình hệ thống phần mềm thông thường 47

Hình IV.2 – Mô hình hệ thống phần mềm sử dụng IMDB 49

Hình IV.3 – Kết hợp CSDL truyền thống và IMDB Cache 49

Hình IV.4 – Mô hình CC trước và sau khi áp dụng TimesTen 57

Hình IV.5 – Mô hình Rating trước và sau khi áp dụng TimesTen 58

MỞ ĐẦU

1 Sự cấp thiết của đề tài

Sự phát triển với tốc độ rất nhanh của công nghệ thông tin bao gồm cả phần cứng, phần mềm và hạ tầng mạng (Internet, LAN, WAN…) đã làm thay đổi bộ mặt và hình thức kinh doanh trên quy mô toàn thế giới Giờ đây hầu hết các quy trình kinh doanh đều được tự động hóa, công nghệ thông tin hóa một cách tối đa Các hệ thống công nghệ thông tin đang là xương sống của những tập đoàn, tổ chức kinh doanh từ nhỏ đến lớn, và khi việc kinh doanh phát triển hơn (nhiều khách hàng hơn, nhiều lĩnh vực hơn, tinh vi hơn) nhưng cũng nhiều cạnh tranh hơn, những công ty tổ chức này yêu cầu xây dựng những hệ thống phần mềm ngày càng lớn và phức tạp, nhưng vẫn phải đáp ứng những yêu cầu về hiệu năng Để đáp ứng yêu cầu này, ngành công nghệ thông tin cũng đã có những bước phát triển nhanh chóng: phần cứng rẻ hơn, nhanh hơn, băng thông mạng lớn hơn, các công cụ lập trình tiện dụng hơn, hiệu quả hơn,… Nhưng thật không may có một thành phần quan trọng của các hệ thống công nghệ thông tin là Cơ sở dữ liệu truyền thống lại không có được những phát triển ấn tượng như vậy Khi xây dựng những hệ thống lớn với số lượng dữ liệu cũng như số giao dịch lớn, Cơ sở dữ liệu truyền thống (dựa trên ổ đĩa cứng) trở thành điểm nghẽn ảnh hưởng không nhỏ đến hiệu năng của toàn bộ hệ thống Thực trạng này đặt ra những yêu cầu cần tìm ra những phương pháp, hướng đi mới cho hệ thống Cơ sở dữ liệu Tại Việt Nam, yêu cầu này càng trở nên cấp thiết hơn bao giờ hết khi hệ thống công nghệ thông tin ngày càng đóng vai trò quan trọng trong quy trình hoạt động kinh doanh và thành công của doanh nghiệp, số lượng các doanh nghiệp tổ chức ra đời ngày càng nhiều trong môi trường kinh doanh cạnh tranh hơn, và chủ trương của Nhà nước về phát triển khoa học công nghệ phục vụ sự phát triển chung của đất nước

Để giải quyết vấn đề này, hiện cũng đã có các nghiên cứu thử nghiệm nhằm làm tăng tốc độ truy vấn dữ liệu Từ cơ sở tốc độ truy vấn của ổ cứng chậm hơn chip nhớ flash, chip nhớ chậm hơn bộ nhớ chính (RAM), một hướng đi là đổi phương tiện lưu trữ dữ liệu của CSDL từ ổ cứng sang SSD (chíp nhớ flash) hoặc RAM disk (giả lập ổ cứng thành RAM), tốc độ truy vấn đã được cải thiện Một hướng đi khác là In-memory database (IMDB), lưu toàn bộ dữ liệu trong bộ nhớ chính Kết quả so sánh giữa cơ sở

dữ liệu trên ổ cứng, trên SSD, trên bộ nhớ chính đã cho thấy sử dụng cơ sở dữ liệu trên

bộ nhớ là một hướng đi đúng đắn Cơ sở dữ liệu trên bộ nhớ (In-memory database) là

cơ sở dữ liệu quan hệ dựa trên bộ nhớ, bỏ qua các thao tác truy cập ổ đĩa cứng bằng cách lưu trữ và xử lý dữ liệu ngay trên bộ nhớ chính Nó còn được gọi với các tên khác như Main memory database (cơ sở dữ liệu bộ nhớ chính) hoặc real-time database (cơ

sở dữ liệu thời gian thực) Khác biệt cơ bản giữa Cơ sở dữ liệu trên bộ nhớ với cơ sở

dữ liệu truyền thống là nó sử dụng bộ nhớ chính (RAM) để lưu trữ dữ liệu Khi đó tốc

độ truy cập không chỉ được cải thiện vì tốc độ đọc/ghi của RAM nhanh hơn mà còn vì kiến trúc của hệ thống CSDL đơn giản hơn rất nhiều, cũng như không cần các cơ chế

buffer, không cần liên tục copy dữ liệu cache từ ổ cứng lên RAM, đồng thời các thuật toán tối ưu câu truy vấn, tổ chức dữ liệu, chỉ mục cũng được tối ưu hơn

Hiện nay, các nhà cung cấp giải pháp lưu trữ dữ liệu hàng đầu thế giới cũng đang hướng về giải pháp Cơ sở dữ liệu trên bộ nhớ để cải thiện tốc độ truy cập dữ liệu Điển hình phải kể đến Oracle với sản phẩm Oracle TimesTen, IBM với sản phẩm IBM solidDB Ngoài ra, các công ty nhỏ và cộng đồng mã nguồn mở cũng tham gia mạnh

mẽ vào việc nghiên cứu phát triển và sử dụng cơ sở dữ liệu trên bộ nhớ Tại Việt Nam, chưa có nhiều nghiên cứu, bài viết chính thống về Cơ sở dữ liệu trên bộ nhớ, chủ yếu

là các thông tin trên một số diễn đàn công nghệ thông tin, các nghiên cứu toàn diện và chuyên sâu lại càng hiếm Từ đó đặt ra yêu cầu cấp thiết và thực tế là cần có một nghiên cứu chuyên sâu và toàn diện về Cơ sở dữ liệu trên bộ nhớ: kiến trúc, đặc điểm chức năng, ưu nhược điểm, cũng như cách sử dụng chúng sao cho hiệu quả

2 Mục tiêu nghiên cứu

- Tìm hiểu hiện trạng, tình hình nghiên cứu Cơ sở dữ liệu trên bộ nhớ

- Nghiên cứu kiến thức cơ sở của Cơ sở dữ liệu trên bộ nhớ: khái niệm, kiến trúc, đặc điểm tính năng

- Nghiên cứu ưu nhược điểm của Cơ sở dữ liệu trên bộ nhớ, các sản phẩm Cơ

sở dữ liệu trên bộ nhớ, so sánh với các công nghệ, sản phẩm cạnh tranh

- Tổng quát hóa các bài toán nghiệp vụ, kiến trúc có thể áp dụng Cơ sở dữ liệu trên bộ nhớ; Cài đặt thử nghiệm

- Đưa ra những đề xuất, ý tưởng ứng dụng, cải tiến với Cơ sở dữ liệu trên bộ nhớ

3 Đối tượng, phạm vi và phương pháp nghiên cứu

- Đối tượng nghiên cứu: Cơ sở dữ liệu trên bộ nhớ

 Các sản phẩm Cơ sở dữ liệu trên bộ nhớ

 Mô hình áp dụng và kết quả thực nghiệm

- Phương pháp nghiên cứu:

 Nghiên cứu lý thuyết: tìm hiểu lý thuyết về Cơ sở dữ liệu trên bộ nhớ trên các paper, diễn đàn nổi tiếng, các website chính thức của các công ty có sản phẩm hoặc giải pháp liên quan Cơ sở dữ liệu trên

bộ nhớ

 Thử nghiệm: tổng quát hóa loại bài toán có thể áp dụng Cơ sở dữ liệu trên bộ nhớ, chọn lựa một sản phẩm Cơ sở dữ liệu trên bộ nhớ

và hệ thống để áp dụng, rút ra kết quả

4 Ý nghĩa khoa học và thực tiễn

5 Bố cục của luận văn

- Chương 1: Cơ sở lý luận về Cơ sở dữ liệu trên bộ nhớ

- Chương 2: Cơ sở khoa học về Cơ sở dữ liệu trên bộ nhớ

- Chương 3: Các sản phẩm Cơ sở dữ liệu trên bộ nhớ

- Chương 4: Thử nghiệm Cơ sở dữ liệu trên bộ nhớ

- Kết luận và Hướng nghiên cứu tiếp theo

Chương 1: CƠ SỞ LÝ LUẬN VỀ CƠ SỞ DỮ LIỆU TRÊN BỘ NHỚ I.1 Tình hình nghiên cứu IMDB

Sự phát triển với tốc độ rất nhanh của CNTT bao gồm cả phần cứng, phần mềm

và hạ tầng mạng (Internet, LAN, WAN…) đã làm thay đổi bộ mặt và hình thức kinh doanh trên quy mô toàn thế giới Giờ đây hầu như các quy trình kinh doanh đều được

tự động hóa, tin học hóa một cách tối đa Các hệ thống CNTT đang là xương sống của những tập đoàn, tổ chức kinh doanh lớn, và khi việc kinh doanh phát triển (nhiều khách hàng hơn, nhiều lĩnh vực hơn, tinh vi hơn) những tổ chức này yêu cầu xây dựng những hệ thống CNTT ngày càng lớn và phức tạp Để đáp ứng nhu cầu này ngành CNTT cũng đã có những bước phát triển nhanh chóng: phần cứng rẻ hơn, nhanh hơn, băng thông mạng lớn hơn, các công cụ lập trình tiện dụng hơn, hiệu quả hơn,… Nhưng thật không may có một thành phần quan trọng của các hệ thống CNTT là Cơ sở dữ liệu truyền thống lại không có được những phát triển ấn tượng như vậy Khi xây dựng những hệ thống lớn với số lượng giao dịch lớn Cơ sở dữ liệu trên ổ cứng trở thành các điểm nghẽn ảnh hưởng đến hiệu năng của toàn bộ hệ thống

Để giải quyết vấn đề này các nhà cung cấp giải pháp lưu trữ dữ liệu hàng đầu thế giới đều đang hướng về giải pháp Cơ sở dữ liệu trên bộ nhớ (In memory Database - IMDB) để cải thiện tốc độ truy cập dữ liệu Khác biệt cơ bản là IMDB sử dụng bộ nhớ chính (RAM) để lưu trữ dữ liệu Khi đó tốc độ truy cập không chỉ được cải thiện vì tốc

độ đọc/ghi của RAM nhanh hơn mà còn vì kiến trúc của hệ thống CSDL đơn giản hơn rất nhiều, cũng như không cần các cơ chế bộ nhớ đệm, không cần liên tục sao chép dữ liệu cache từ ổ cứng lên RAM

Nghiên cứu phát triển IMDB cũng như áp dụng IMDB vào các hệ thống phần mềm là xu hướng mới nhưng đang phát triển mạnh mẽ tại các công ty phần mềm, tại nhiều quốc gia, với nhiều lĩnh vực như tài chính, viễn thông, ngân hàng,…

I.1.1 Tình hình nghiên cứu phát triển

Nghiên cứu phát triển hệ thống IMDB thành các sản phẩm đóng gói đang là xu hướng của một số công ty phần mềm lớn cũng như cộng đồng mã nguồn mở Dưới đây liệt kê một số sản phẩm điển hình:

- Oracle TimesTen (sản phẩm thương mại) [4]: là một bộ sản phẩm của Oracle gồm CSDL TimesTen IMDB, và IMDB Cache để đồng bộ dữ liệu 2 chiều giữa CSDL Oracle truyền thống và TimesTen IMDB TimesTen IMDB là một cơ sở dữ liệu tối ưu hóa dựa trên bộ nhớ, giúp các ứng dụng ở các lĩnh vực khác nhau đạt được hiệu năng cao với thời gian đáp ứng (response time) rất nhỏ và thông lượng (throughput) rất lớn Được triển khai

ở tầng ứng dụng, TimesTen nằm hoàn toàn trong bộ nhớ chính, nhưng vẫn

có các cơ chế lưu trữ dữ liệu ra ổ đĩa cứng nhằm đảm bảo an toàn dữ liệu Ứng dụng truy cập dữ liệu trong CSDL TimesTen thông qua giao tiếp SQL chuẩn TimesTen cũng có cơ chế đảm bảo tính sẵn sàng cao bằng tính năng Replication

- IBM SolidDB (sản phẩm thương mại) [10], [11]: là một bộ sản phẩm của IBM, gồm solidDB IMDB và solidDB Universal Cache IBM solidDB IMDB là một cơ sở dữ liệu quan hệ trên bộ nhớ với đầy đủ tính năng, cung cấp tốc độ và tính sẵn sàng cao, giúp thỏa mãn yêu cầu về hiệu năng và độ tin cậy cho các ứng dụng thời gian thực Ứng dụng kết nối để truy cập dữ liệu trong solidDB IMDB thông qua giao tiếp SQL chuẩn solidDB cũng có

cơ chế hot-standby để đảm bảo tính sẵn sàng cao SolidDB universal cache giúp đồng bộ dữ liệu từ một CSDL truyền thống tới solidDB IMDB

- McObject eXtremeDB (sản phẩm thương mại) [13]: là một bộ sản phẩm của McObject, gồm eXtremeDB IMDB là một cơ sở dữ liệu trên bộ nhớ dùng cho các ứng dụng thời gian thực và cho các ứng dụng nhúng như set-top box, thiết bị viễn thông, thiết bị điện tử,… Ngoài ra, bộ sản phẩm còn gồm các sản phẩm khác như eXtremeDB fusion, Cluster, HA, Transaction Logging

- H2 IMDB (sản phẩm nguồn mở) [14]: một CSDL trên bộ nhớ gọn nhẹ, hỗ trợ JDBC API, cho phép chạy ở chế độ embeded hoặc server, hỗ trợ SQL chuẩn

- HyperSQL (sản phẩm nguồn mở) [15]: là một CSDL được viết bằng java

Nó cung cấp một database engine nhỏ gọn, nhanh, đa luồng, hỗ trợ cơ chế kết nối embeded và server Nó cũng có các công cụ dòng lệnh SQL mạnh

mẽ, và các công cụ có giao diện

Tại Việt Nam, việc nghiên cứu phát triển một sản phẩm CSDL trên bộ nhớ chưa được công ty, doanh nghiệp nào thực hiện Việc sử dụng một hệ thống IMDB cũng còn rất ít Các giải pháp tăng cường hiệu năng hệ thống vẫn chỉ dừng lại ở mức tối ưu hóa CSDL hiện tại (chỉ mục, quy hoạch bảng biểu,…), hoặc cao hơn là cache dữ liệu cần thiết lên bộ nhớ, bằng cách sử dụng hashmap chẳng hạn

- Công ty tài chính China Finance Online có hai website với khoảng 11 triệu người dùng Các website này cung cấp các thông tin về chứng khoán, cổ phiếu, tài chính,…mới nhất, độ trễ dưới ba giây Nó đòi hỏi phải đáp ứng lượng lớn truy cập với thời gian đáp ứng nhanh China finance online đã sử dụng Oracle TimesTen và hoàn toàn đáp ứng được những yêu cầu trên

- Iskratel là một công ty hoạt động trong lĩnh vực viễn thông, chuyên nghiên cứu và cung cấp các giải pháp liên quan đến mạng lưới Công ty có một sản

phẩm SI3000 cho phép gọi điện, sử dụng data, cũng như các dịch vụ tích hợp rất hữu ích cho người dùng và doanh nhân Nhưng hiệu năng CSDL như tra cứu thông tin khách hàng, cấu hình,… không như mong đợi Iskratel

đã thay thế CSDL truyền thống bằng IBM solidDB, giúp tăng số lượng cuộc gọi cũng như giảm thời gian xử lý xuống ba lần

Tiến sĩ Elliot King [12], một nhà nghiên cứu của Loyola University, đã có whitepaper đưa ra số liệu thống kê liên quan đến việc sử dụng IMDB Tháng 04/2011, Elliot King cùng nhóm cộng sự đã thực hiện mời các chuyên gia CNTT uy tín, cùng các nhóm phù hợp trên LinkedIn.com tham gia khảo sát Những người được mời làm việc ở nhiều lĩnh vực, vai trò khác nhau Kết quả, có 237 người tham gia khảo sát, trong số đó 30% đang sử dụng IMDB, 70% còn lại thì có đến hơn một nửa quen thuộc với công nghệ IMDB Chi tiết một số kết quả khảo sát như sau:

- Loại ứng dụng sử dụng IMDB:

- Lượng dữ liệu trong IMDB:

- Có ý định bắt đầu/mở rộng việc sử dụng IMDB trong tương lai:

Dưới 10 GB

11 – 25 GB

26 – 100 GB Trên 100 GB Không biết

Phân tích kinh doanh

- Nguyên nhân thúc đẩy sự mở rộng việc sử dụng IMDB:

- Các lợi ích quan trọng nhất của IMDB:

- Các hạn chế lớn nhất của IMDB:

không biết

có không

Nhiều ứng dụng hơn

Cần độ trễ thấp

Nhiều người dùng hơn

Tăng kích thước data

Tăng dung lượng data

- Tiêu chí khi lựa chọn sản phẩm IMDB:

Nghiên cứu của Tiến sĩ Elliot King đã cho thấy sự quan tâm ngày càng lớn trong việc sử dụng IMDB với các ứng dụng trong nhiều lĩnh vực, nhằm đạt được các yêu cầu về hiệu năng, giải quyết thách thức về sự tăng trưởng dữ liệu, cũng như đạt được các mục tiêu dài hạn của công ty

I.2 Nhu cầu thực tế và khả năng áp dụng

I.2.1 Nhu cầu

Đi cùng với sự phát triển kinh doanh, khách hàng của mỗi công ty, doanh nghiệp sẽ là những thách thức về hiệu năng, số lượng truy cập dữ liệu, cũng như những đòi hỏi ngày càng cao của khách hàng Nếu không đủ nhanh và đáp ứng yêu cầu thị trường, yêu cầu khách hàng, công ty khó có thể cạnh tranh với các công ty khác Các

hệ thống liên quan trực tiếp cần cải thiện hiệu năng gồm các ứng dụng viễn thông, tài chính ngân hàng, hàng không, quân sự, game, các hệ thống chăm sóc khách hàng

Trong lĩnh vực Viễn thông nói riêng, Viettel đang là một trong ba nhà cung cấp dịch vụ viễn thông lớn nhất Việt Nam Các sản phẩm phần mềm hỗ trợ kinh doanh chủ yếu do Trung tâm Phần mềm Viettel tự xây dựng Hiện tại, Trung tâm đã và đang phát triển những hệ thống rất lớn như Tính cước và chăm sóc khách hàng (Billing & Customer Care System – BCCS), kho tàng tài sản, v-office,… đến khi đưa vào sử dụng, vận hành mới phát hiện ra nhiều điểm nghẽn liên quan đến CSDL và đang phải khắc phục rất vất vả Việc treo nghẽn của hệ thống BCCS ảnh hưởng nghiêm trọng đến việc sản xuất kinh doanh và mức độ hài lòng của khách hàng

Các điểm treo nghẽn của hệ thống BCCS hầu như đều liên quan đến việc truy cập CSDL Các ví dụ điển hình là:

- Vào các thời điểm cuối tháng các chi nhánh, phòng ban, đơn vị đồng thời vào lấy báo cáo kết quả sản xuất kinh doanh trong tháng Số lượng truy vấn đến CSDL tăng đột biến nên việc lấy báo cáo này rất chậm, thậm chí không lấy được Ngoài ra điều nguy hiểm hơn là khi CSDL bị quá tải thì các nghiệp vụ khác cũng không thể thực hiện được Việc sản xuất kinh doanh bị đình trệ, ảnh hưởng vô cùng lớn

Có hỗ trợ Cam kết lộ trình Platform hỗ trợ Giá cả

Tương thích đối tác Khác

- Để cải tiến nghiệp vụ chăm sóc khách hàng, đội dự án BCCS đã bổ sung tính năng khi khách hàng gọi điện đến Trung tâm chăm sóc khách hàng thì trên màn hình của giao dịch viên sẽ hiện lên luôn thông tin về khách hàng này Tuy nhiên việc này cũng làm tăng đột biến tải của CSDL và ảnh hưởng nghiêm trọng đến các chức năng khác của BCCS

- Hiện nay khi xử lý các yêu cầu gửi lên, nhiều phân hệ của BCCS đang dùng các hàng đợi để chứa các yêu cầu và xử lý dần dần Các hàng đợi hiện nay đều được chứa trong CSDL Khi xử lý liên tục phải truy vấn vào CSDL, việc này làm tăng thời gian đáp ứng (response time) của hệ thống và làm giảm tính real-time của việc xử lý

Số lượng những vấn đề tương tự như trên rất phổ biến, làm giảm hiệu năng, chất lượng và độ ổn định của hệ thống, làm tăng chi phí giám sát vận hành và gây thiệt hại lớn cho sản xuất kinh doanh Việc áp dụng các giải pháp như IMDB sẽ là cứu cánh cho phần mềm nói riêng và sự phát triển của công ty nói chung, không chỉ để khắc phục các nhược điểm hiện tại, mà còn chuẩn bị cho sự phát triển trong tương lai

- Giá thành của bộ nhớ chính ngày càng giảm, gần với giá ổ đĩa cứng

- Nhu cầu của các ứng dụng là có thật và ngày càng trở nên cấp thiết, khi số lượng truy cập ngày càng lớn với đòi hỏi thời gian đáp ứng tức thời:

 Viễn thông: đăng nhập, xác thực, tính cước, mediation, call centers

 Tài chính: online banking, fraud detection, stock exchanges,…

 Các ứng dụng khác: chăm sóc khách hàng, gaming, đặt vé máy bay,…

I.3 Kết luận chương 1

Từ những thông tin trên cho thấy việc nghiên cứu phát triển cũng như tìm hiểu

sử dụng IMDB đang nở rộ trên thế giới với sự tham gia của các công ty phần mềm lớn cũng như của cộng đồng mã nguồn mở, trên nhiều lĩnh vực Tài chính, Viễn thông, ngân hàng, thương mại điện tử, quân sự, trò chơi,…

Hiện trạng các hệ thống phần mềm, ứng dụng trong các lĩnh vực đang đặt ra nhu cầu cấp thiết phải áp dụng các giải pháp nhằm tăng hiệu năng, đáp ứng nhiều hơn

số lượng truy cập với thời gian nhỏ hơn Sử dụng IMDB là một giải pháp tốt, có thể dễ dàng áp dụng cho nhiều loại ứng dụng, mới xây dựng hoặc đã có, trên nhiều lĩnh vực khác nhau

Chương 2: CƠ SỞ KHOA HỌC VỀ IN-MEMORY DATABASE

II.1 Khái niệm IMDB

Sự phát triển nhanh chóng của kỹ thuật chế tạo ổ cứng và RAM cho phép lưu trữ ngày càng nhiều dữ liệu, lên đến terabyte hoặc petabyte Tuy nhiên, độ trễ đọc/ghi

dữ liệu cũng như băng thông lại không có được tốc độ phát triển như vậy Hiện nay, thời gian quét RAM cỡ terabyte tính bằng phút và quét ổ cứng cỡ terabyte phải tính bằng giờ Chúng ta nên giữ toàn bộ dữ liệu trên bộ nhớ và thiết kế lại cấu trúc dữ liệu

và thuật toán, cũng như sử dụng đa tiến trình để tận dụng hết tài nguyên bộ nhớ chính IMDB ra đời nhằm đáp ứng cho các hệ thống cần thời gian truy vấn dữ liệu từ CSDL rất nhỏ và số lượng truy cập đồng thời cao

In-memory database (Cơ sở dữ liệu trên bộ nhớ) là cơ sở dữ liệu quan hệ dựa trên bộ nhớ, bỏ qua các thao tác truy cập ổ đĩa cứng bằng cách lưu trữ và xử lý dữ liệu ngay trên bộ nhớ chính Nó còn có các tên khác như Main memory database (cơ

sở dữ liệu bộ nhớ chính) hoặc real-time database (cơ sở dữ liệu thời gian thực)

II.2 Các vấn đề kỹ thuật của IMDB

II.2.1 So sánh IMDB với disk-based DB

IMDB không chỉ đơn thuần khác CSDL truyền thống ở việc dữ liệu được đặt trên bộ nhớ chính thay vì trên ổ đĩa cứng, mà các yếu tố khác cũng được thay đổi để tối ưu hơn Các yếu tố đó bao gồm: Tối ưu truy vấn, quản lý bộ nhớ đệm (buffer pool),

và cấu trúc chỉ mục (index) Trong khi CSDL dựa trên ổ cứng thực hiện các công việc

đó với quan niệm dữ liệu được đặt trên ổ cứng (dù dữ liệu có được cache trên bộ nhớ), IMDB biết chắc dữ liệu được đặt trên bộ nhớ nên nó làm đơn giản hóa các thuật toán

và cấu trúc

Dưới đây là so sánh cụ thể giữa IMDB và CSDL dựa trên ổ cứng (gồm cả trường hợp dữ liệu có được cache toàn bộ lên bộ nhớ):

Bảng II.1 – Bảng so sánh CSDL dựa trên ổ cứng và IMDB

Lưu trữ dữ

liệu

- Dữ liệu được lưu trữ trên ổ cứng

- Dữ liệu có thể được cache vào

bộ nhớ để truy cập nhanh hơn

- Dữ liệu được lưu trũ trên bộ nhớ chính để truy vấn và xử lý

- Dữ liệu có thể được ghi xuống ổ cứng để sao lưu và phục hồi Tối ưu hóa

truy vấn

- Thuật toán tối ưu hóa truy vấn thực hiện với quan niệm dữ liệu đặt trên ổ đĩa Do đó, tại thời điểm tối ưu truy vấn, dù dữ liệu được đặt một phần hay toàn bộ trong bộ nhớ, thời gian thực hiện gần như không khác nhau

- IMDB biết chắc dữ liệu lưu trữ trên bộ nhớ, nên thuật toán tối ưu truy vấn đơn giản hơn và chính xác hơn

(buffer pool) yêu cầu truy vấn dữ liệu, CSDL

sẽ tìm kiếm trong buffer pool trước Nếu không có, sẽ tìm trong các file ở ổ cứng

- Thậm chí, nếu dữ liệu được tìm thấy trong buffer, nó cũng phải sao chép trước khi trả lại kết quả,

vì còn phải phục vụ các xử lý tiếp theo

trước khi trả lại cho ứng dụng Do

đó, thuật toán đơn giản hơn, thời gian đáp ứng truy vẫn nhanh hơn

Cấu trúc chỉ

mục (index)

- Sử dụng B+ tree cho index B+tree gồm nhiều node, mỗi node ứng với một data page, và chỉ số của page tiếp theo Mỗi node gồm nhiều entry, mỗi entry chứa cặp data key-value và con trỏ tới entry tiếp theo

 Cấu trúc này là lý tưởng để giảm disk I/O, nhưng nó không còn nhiều hữu dụng khi dữ liệu đặt trong bộ nhớ Khi dữ liệu đặt trong bộ nhớ, mục tiêu là giảm CPU cycle, không phải I/O Nếu dùng cấu trúc này, CPU cycle tăng vì phải mở rộng và so sánh giá trị index trong B+ tree

- Sử dụng T-tree cho index Vì tất

cả data row được đặt trong bộ nhớ, T-tree không cần cặp key-value, chỉ đơn thuần gồm các con trỏ tới các dòng dữ liệu thực Thời gian tìm kiêm dữ liệu như thuật toán tìm kiếm nhị phân

II.2.2 Kiến trúc hệ thống IMDB

II.2.2.1 Kiến trúc disk-based RDB

Hình II.1 – Kiến trúc disk-based RDB

- Driver interfaces: Người dùng hoặc chương trình ứng dụng có thể tác động đến dữ liệu, thông qua DDL (ngôn ngữ định nghĩa dữ liệu), DML (ngôn ngữ

xử lý dữ liệu), DCL (ngôn ngữ điều khiển dữ liệu) Chương trình ứng dụng viết bằng ngôn ngữ lập trình nào, sử dụng CSDL nào phải có driver tương ứng Những driver này được xây dựng dựa trên SQL Chúng cung cấp các phương thức để chuẩn bị câu truy vấn, thực thi câu truy vấn và lấy kết quả trả về

- SQL Engine: biên dịch và thực thi các truy vấn, gồm:

 Compiler: xây dựng cấu trúc dữ liệu từ câu SQL và kiểm tra cú pháp, ngữ nghĩa

 Optimizer: chuyển câu SQL gốc thành các nhóm operation sao cho thực thi hiệu quả nhất

 Execution engine: thực thi câu SQL sau tối ưu, liên kết với Relational engine để lấy và lưu trữ kết quả

Nguồn: wikipedia

- Transaction engine:

 Concurency manager: quản lý truy cập đồng thời tới dữ liệu

 Log manager: đảm bảo tính toàn vẹn và bền vững của transaction Undo log để rollback CSDL về trạng thái gần nhất Redo log đảm bảo lưu trữ tất cả những transaction đã commit, phục vụ phục hồi khi cần thiết

 Recovery manager: phục hồi CSDL từ ảnh ổ cứng và redo log file

- Relational engine: các đối tượng quan hệ như bảng, chỉ mục, và ràng buộc

dữ liệu được quản lý bởi thành phần này

- Storage engine: lưu trữ và lấy các bản ghi dữ liệu Nó cũng cung cấp cơ chế lưu trữ thông tin metadata và thông tin điều khiển

II.2.2.2 Kiến trúc IMDB

Về tổng thể, IMDB cũng có kiến trúc tương tự disk-based DB, như gồm các thành phần: SQL engine, transaction engine, relational engine, và storage engine, nhưng các thành phần con bên trong mỗi thành phần này lại hoạt động khác hẳn

Dưới đây trình bày cụ thể từng thành phần trong kiến trúc của IMDB:

- Memory segment: được chia làm 3 phần chính:

 Control segment: chứa bảng lock, bảng tiến trình, bảng transaction, undo log và redo logs

 Catalog segment: chứa metadata về bảng, chỉ mục,…

 User segment: chứa bản ghi dữ liệu của tất cả các bảng, các chỉ mục

- SQL engine: với disk-based DB, tối tưu hóa theo cost-based thường được sử dụng vì liên quan đến disk I/O IMDB chỉ sử dụng tối ưu hóa theo rule-based

- Relational engine: thuật toán lưu trữ, tìm kiếm trong IMDB đơn giản hơn vì

nó chỉ làm việc với bộ nhớ, không liên quan đến ổ cứng IMDB sử dụng tree cho chỉ mục thay vì B-tree trong disk-based DB

T Transaction engine: các transaction trong IMDB không có việc đợi disk I/O, điều này có thể dẫn đến deadlock, làm ảnh hưởng đến thông lượng Do đó, việc quản lý giao dịch đồng thời phải được chú trọng hơn trong IMDB

- Storage engine: trong disk-basedDB việc định vị dữ liệu dựa trên các block, trong IMDB việc định vị linh hoạt hơn bằng các mô hình kết nối khác nhau, như kết nối trực tiếp hoặc kết nối client/server Việc này được quản lý bởi IPC của hệ điều hành

Hình II.2 – Kiến trúc IMDB

II.2.3 Tại sao IMDB lại nhanh?

Hình dưới so sánh việc truy vấn dữ liệu giữa CSDL truyền thống (dựa trên ổ cứng) và IMDB

Khi ứng dụng gửi một câu truy vấn dữ liệu tới CSDL, SQL Engine của OracleDB biên dịch, tối ưu hóa, sau đó thực thi câu lệnh Nó sẽ tìm kiếm dữ liệu mong muốn trong buffer pool trước (trên bộ nhớ chính), nếu không thấy sẽ phải tìm kiếm trong ổ cứng từ các data file Sau đó, nó sao chép dữ liệu phù hợp sang một buffer riêng, trước khi trả lại cho ứng dụng

Với IMDB, nó cũng có một bộ Query optimizer để tối ưu hóa câu lệnh trước khi thực thi Tuy nhiên, khác với disk-based DB, IMDB biết chắc chắn dữ liệu nằm trên bộ nhớ chính, nên nó chỉ tìm kiếm trên bộ nhớ với những thuật toán đã được tối

ưu riêng cho bộ nhớ Sau đó, nó trả lại kết quả cho ứng dụng

Nguồn: wikipedia

Với kiến trúc như vậy, cùng với tốc độ truy cập bộ nhớ nhanh hơn nhiều so với

ổ cứng, và các thuật toán tối ưu riêng cho bộ nhớ, IMDB cải thiện đáng kể tốc độ truy vấn dữ liệu

Hình II.3 – So sánh mô hình xử lý SQL của disk-based DB và IMDB

II.2.4 Kết nối từ ứng dụng đến IMDB

 Kết nối trực tiếp

Hầu hết các sản phẩm IMDB đều hỗ trợ thêm kiểu kết nối trực tiếp/nhúng (direct/embeded), ngoài cách kết nối client/server thông thường Trong một kết nối trực tiếp, chúng thường dùng một vùng nhớ chia sẻ của phần cứng Các ứng dụng sử dụng direct driver để truy cập vào ảnh của CSDL đã được load trong vùng nhớ này Vì không yêu cầu một IPC (inter-process communication), một kết nối trực tiếp cung cấp khả năng xử lý rất nhanh Đó cũng là cách lý tưởng để sử dụng IMDB

 Kết nối client/server

IMDB đóng vai trò như server, chương trình ứng dụng là client Server sẽ tạo một tiến trình con riêng biệt cho mỗi kết nối từ client tới CSDL Ứng dụng trên máy client có thể là ODBC, JDBC hay OCI calls Những ứng dụng này sẽ truy cập tới một local ODBC client driver, từ đó driver này sẽ giao tiếp với một tiến trình con trên IMDB server Sau đó, tiến trình con này sẽ tạo ra một native ODBC request tới ODBC direct driver để truy cập IMDB

Nếu client và server nằm trên các nút mạng khác nhau, chúng giao tiếp bằng giao thức TCP/IP Nếu chúng nằm trên cùng một máy, chúng có thể giao tiếp hiệu quả hơn bằng cách sử dụng vùng nhớ chia sẻ (kết nối trực tiếu) Các hệ thống CSDL truyền thống thường được cấu trúc theo kiểu client/server, thậm chí khi client và server

Nguồn: Oracle

IMDB

nằm trên cùng một máy vật lý Kiểu kết nối này tăng thêm nhiều thời gian cho các giao tác với CSDL

II.2.5 Truy cập đồng thời (concurrent operations)

Một CSDL có thể được truy cập theo kiểu chia sẻ Khi nhiều có truy vấn đến CSDL, phải có một cách để điều khiển các thay đổi đồng thời đến dữ liệu Tương tự CSDL truyền thống, IMDB sử dụng Transaction isolation (cô lập giao tác) và các lock (khóa) để điểu khiển các truy cập đồng thời tới dữ liệu

a/ Transaction isolation

Các ứng dụng có thể sử dụng thuộc tính kết nối isolation để thiết lập mức isolation cho kết nối ấy Các kết nối các khác nhau có thể sử dụng các mức isolation khác nhau Mức cô lập và khả năng đồng thời là đối ngược nhau Mức cô lập thấp cho phép nhiều truy cập đồng thời, nhưng rủi ro về không nhất quán dữ liệu cao Ngược lại, mức cô lập cao cung cấp mức nhất quán dữ liệu cao hơn, nhưng cho phép ít các truy cập đồng thời

Có 2 mức cô lập giao tác:

 Read committed isolation

Với mức cô lập này, người đọc sử dụng một bản copy của dữ liệu, nên không cần phải dùng lock Người ghi chỉ khóa những người ghi và người đọc sử dụng mức serializable isolation, mà không khóa những người đọc sử dụng Read-commited isolation Việc update dữ liệu sẽ tạo ra một bản copy của những dòng được update, điều này cho phép nonserializable readers có thể đọc những dòng này bình thường

 Serializable isolation

Với mức cô lập này, khóa được yêu cầu cho một giao tác và được giữ cho đến khi giao tác được commit hoặc rollback cho cả việc đọc và ghi dữ liệu Mức cô lập này cho phép đọc repeatable Khóa database-level được dùng với mức cô lập này

Mức này khóa toàn bộ CSDL khi có một truy vấn tới nó Tất cả database-level

là tường minh Một truy vấn yêu cầu DB-level lock không thể khởi động cho đến khi không còn một truy vấn nào khác tới CSDL Mức Khóa này phù hợp với những hoạt động khởi gán ban đầu như migrate một lượng dữ liệu lớn

 Table-level locking

Mức này khóa một table khi có một truy vấn tới nó Nó phù hợp với trường hợp

có một câu lệnh truy cập hầu hết các dòng trong một bảng Khóa bảng làm giảm thông lượng dữ liệu vào, do vậy nó chỉ nên dùng khi có một phần quan trong của một bảng cần phải khóa Ví dụ, khi một bảng cần update hầu hết các dòng

 Row-level locking

Mức này chỉ khóa những dòng được truy vấn Nó cung cấp mức đa truy vấn cao nhất vì cho phép các giao tác đồng thời tới các dòng trong một bảng Mức này phù hợp với trường hợp có nhiều giao tác đồng thời tới các dòng khác nhau của cùng một bảng

II.2.6 Tối ưu hóa truy vấn

Tương tự CSDL truyền thống, IMDB cũng có một bộ tối ưu hóa truy vấn để bảo đảm các truy cập dữ liệu hiệu quả bằng cách tự động chọn ra cách tốt nhất để trả lời các truy vấn Bộ tối ưu hóa truy vấn giúp giảm thời gian thực thi truy vấn xuống thấp nhất có thể

Các tham số khi xem xét tối ưu hóa truy vấn:

 Các thông tin của bảng và cột

Khi có một truy vấn tới, bộ tối ưu truy vấn sẽ kiểm tra các thông tin về dữ liệu được tham chiếu bởi truy vấn, như số dòng của bảng, giá trị unique nhỏ nhất và lớn nhất của cột xuất hiện trong điều kiện của truy vấn (sau where), khóa chính, index

 Thông tin metadata (như toàn vẹn tham chiếu, khóa chính,…)

 Chỉ mục (Index)

Bộ tối ưu truy vấn sử dụng index để tăng tốc độ thực thi của truy vấn Nó sử dụng các index có sẵn (do người tạo bảng tạo ra) hoặc tự tạo ra các index tạm thời để chuẩn bị kế hoạch thực thi cho các câu lệnh truy vấn SELECT, INSERT, UPDATE, DELETE Một index là một map giữa khóa và vị trí của nó trong bảng

 Phương pháp quét bảng (scan method)

 Full table scan: Kiểm tra từng dòng một của bảng Đây là cách scan kém hiệu quả nhất nên chỉ được sử dụng khi không thể chọn phương pháp scan nào khác

 Rowid lookup: IMDB sử dụng một định danh duy nhất gọi là rowid cho mỗi dòng của bảng Phương pháp này khả thi trong trường hợp ứng dụng sử dụng rowid làm giá trị tham chiếu Rowid lookup nhanh hơn index lookup

 Range index lookup: Phương pháp này sử dụng range index để truy cập bảng, các trường hợp sử dụng phù hợp đã trình bày trong phần Range index

 Hash index lookup: Sử dụng hash index để tìm các dòng dựa trên khóa chính Các trường hợp sử dụng phù hợp đã trình bày trong phần hash index

 Bitmap index lookup: Sử dụng bitmap index để tìm kiếm Các trường hợp sử dụng phù hợp đã trình bày trong phần bitmap index

 Thuật toán join

Cũng như các hệ quản trị CSDL khác, IMDB cũng có các thuật toán và tiêu chuẩn để lựa chọn phương pháp join giữa các bảng nhằm giảm tối đa thời gian truy vấn, như table statistic, index,…

II.2.7 Tự động loại bỏ dữ liệu không cần thiết

Để tiết kiệm bộ nhớ, một số sản phẩm IMDB cung cấp cơ chế Loại bỏ dữ liệu không cần thiết (data aging) Thường có hai kiểu data aging: loại bỏ dữ liệu cũ dựa trên thời gian hoặc loại bỏ dữ liệu ít được sử dụng nhất Ví dụ, loại bỏ bảng giá ngày hôm trước, hoặc loại bỏ dữ liệu quá hai ngày,…

+ Time-based data aging: thiết lập cơ chế này dựa trên một cột với kiểu dữ liệu thời gian (date, datetime, timestamp) Giá trị cột này sẽ được so sánh với thời gian hiện tại (sysdate), nếu quá khoảng thời gian cấu hình, tức là dữ liệu này đã cũ và bị loại bỏ khỏi IMDB

+ Usage-based data aging: dựa trên thuật toán LRU (Least Recently Used), dữ liệu ít được sử dụng nhất (truy vấn, sửa đổi) sẽ bị loại bỏ khỏi CSDL

II.2.8 Tính sẵn sàng và toàn vẹn dữ liệu

Vì toàn bộ dữ liệu được đặt trên bộ nhớ chính, nên có thể xuất hiện tình huống mất mát dữ liệu khi server tắt Do đó, các sản phẩm IMDB thường bổ sung các cơ chế

hỗ trợ nhằm đảm bảo tính sẵn sàng (availability), bền vững (durability) và toàn vẹn (integrity) dữ liệu thông qua các cơ chế:

 Transaction logging

Transaction log được sử dụng cho các mục đích:

- Redo transaction nếu xuất hiện lỗi hệ thống

- Undo transaction được rollback

- Tạo bản sao (replicate) những thay đổi của CSDL

Việc sử dụng cơ chế ghi log có thể dẫn đến chậm các thao tác DML (insert, update, delete) Một vài phương pháp khắc phục được đưa ra:

- Sau khi commit, không ghi log trực tiếp vào ổ đĩa cứng, mà ghi vào một khoảng không gian trên bộ nhớ, sau đó, định kỳ thông tin này mới được ghi vào ổ đĩa cứng

- Khi có nhiều các giao dịch đồng thời, kỹ thuật “pre-commit” được sử dụng: một giao dịch sau khi commit trên IMDB, trước khi thông tin này được ghi log trên ổ cứng, tất cả các tài nguyên mà giao dịch này nắm giữ được giải phóng, để cho các giao dịch khác sử dụng Điều này giúp tăng tổng số giao dịch thực hiện được trong một khoảng thời gian

- Một kỹ thuật khác được sử dụng là “group commit”: với kỹ thuật này, một giao dịch riêng lẻ sau khi commit, không cần phải ngay thông tin để ghi log

ổ đĩa cứng, mà một nhóm các giao dịch (ví dụ khi đầy page) sẽ được ghi log

ổ cứng (với một lần ghi)

 Checkpointing

Checkpoint lưu trữ một snapshot của CSDL Nếu xuất hiện lỗi hệ thống, IMDB

có thể sử dụng checkpoint file và transaction log file để phục hồi về trạng thái bình thường ở gần đây nhất

Chỉ có những dữ liệu đã thay đổi sau lần checkpoint cuối cùng mới được ghi thêm vào checkpoint file Checkpoint operation sẽ kiểm tra CSDL để tìm ra những thay đổi, sau đó update vào checkpoint file và xóa bỏ các transaction log file không cần thiết

 Replication

Để tăng tốc độ phục hồi khi xảy ra lỗi hệ thống, nhiều IMDB sử dụng cơ chế replication Thêm vào đó, replication còn được sử dụng để phân tán workload để đạt hiệu quả cao nhất

Replication là quá trình sao chép dữ liệu từ master DB tới subscriber DB Replication ở mỗi CSDL được điều khiển bởi replication agent, các agent giao tiếp với nhau thông qua TCP/IP stream socket Replication agent trên master DB đọc thông tin

từ transaction log lên master DB Sau đó, nó đẩy những thay đổi tới replication agent trên subscriber DB Replication agent trên subscriber sẽ cập nhật những thay đổi này tới CSDL của nó Nếu subscriber agent không sẵn sàng khi những thay đổi được đẩy

từ master agent, master agent sẽ ghi lại những thay đổi chưa được cập nhật này vào transaction log của nó, và sẽ đẩy xuống subscriber agent khi nó sẵn sàng

Application

Master transaction log file

Master replication agent

Subsriber replication agent

Subscriber transaction log file Subscriber DB

available -> forward Master DB

Hình II.4 – Mô hình chung tính năng Replication

II.3 So sánh IMDB với các công nghệ cạnh tranh

II.3.1 CSDL trên SSD & RAM-disk

Dựa trên đặc tính vật lý, tốc độ của truy cập tăng dần từ ổ đĩa cứng đến SSD đến RAM, nên đã có những giải pháp tăng hiệu năng CSDL truyền thống theo hướng vật lý Đó là sử dụng SSD hay RAM để giả lập ổ đĩa cứng, và cho CSDL chạy trên các

ổ đĩa giả lập này, nhằm tận dụng tốc độ truy cập nhanh của SSD hay RAM, mà không phải thay đổi thiết kế sẵn có của các sản phẩm disk-based DB

Việc thay đổi này đã có những kết quả tích cực Theo đánh giá của McObject, một công ty chuyên về các giải pháp quản lý dữ liệu, việc đọc với CSDL trên SSD & RAM-disk nhanh gấp khoảng 4 lần so với disk-base DB, và việc cập nhật dữ liệu nhanh gấp khoảng 3 lần Tốc độ này đã cải thiện đáng kể về hiệu năng, nhưng vẫn

chưa hoàn toàn tối ưu Điểm còn thiếu chính là kiến trúc và cơ chế hoạt động của based DB, như mô tả bên dưới:

disk-Hình II.5 – Luồng dữ liệu luân chuyển trong DBMS truyền thống

Quy trình khi ứng dụng truy vấn, cập nhật dữ liệu trên DBMS truyền thống:

- Ứng dụng truy cập CSDL thông qua API cung cấp

- CSDL yêu cầu lấy dữ liệu tương ứng từ hệ thống lưu trữ file

- Hệ thống quản lý file có một bản sao dữ liệu trong cache của nó, và chuyển một bản cho CSDL

- CSDL giữ một bản sao trong cache của nó, và gửi một bản sao cho ứng dụng

- Ứng dụng sửa đổi và gửi lại giá trị mới cho CSDL

- CSDL lưu thay đổi vào cache, hệ thống file lưu thay đổi vào cache

- Dữ liệu được ghi vào thiết bị lưu trữ vật lý

Quy trình trên cho thấy dù có thay đổi ổ đĩa cứng bằng SSD hay giả lập bằng RAM, trong khi các thuật toán và quy trình thực hiện không thay đổi, thì tốc độ chỉ được cải thiện ở phần đọc/ghi với thiết bị lưu trữ Rõ ràng quy trình này có nhiều bước thừa và không còn phù hợp, tối ưu

IMDB làm tốt hơn công việc này Như đã giải thích trong phần II.1.2, ngoài việc lưu trữ dữ liệu trên RAM, IMDB còn tối ưu bằng cách thay đổi thuật toán tối ưu hóa truy vấn, loại bỏ những thành phần không cần thiết như buffer pool, và dùng thuật toán mới cho cấu trúc chỉ mục với mục tiêu tối ưu CPU cycle và RAM thay vì tối ưu việc giao tiếp I/O

II.3.2 Partitioning

Một hướng đi khác để cải thiện hiệu năng của CSDL chính là kỹ thuật partitioning Dưới đây là một số dạng:

- Master/Slave: một master DB server dành cho việc thay đổi dữ liệu, các

slave server dành cho việc đọc Dữ liệu khi thay đổi trên master sẽ được đẩy xuống cho các slave

Nguồn: McObject

- Master/Master: nhiều DB server Việc truy vấn, thay đổi dữ liệu xảy ra với

một server nào đó, những thay đổi này sau đó truyền cho các server còn lại

- Clustering: tổ chức các DB server thành một group Phương pháp này

thường dựa trên tiện ích chia sẻ ổ cứng tập trung, ví dụ SAN (cho phép hệ điều hành nhìn các phần cứng phân tán như phần cứng cục bộ của nó) Mỗi node trong cluster thường tương ứng với một DB instance

- Table partitioning: chia bảng lớn thành nhiều phần nhỏ, đặt trên các ổ cứng

khác nhau để tăng hiệu năng I/O Các bảng này có thể chia theo dòng (theo điều kiện) hoặc theo cột

- Federated tables: một hay nhiều bảng có thể được truy cập từ nhiều server

khác nhau Loại này chỉ phù hợp với mục đích hạn chế, như báo cáo hoặc phân tích

Các kỹ thuật trên nhằm phân chia việc đọc/ghi dữ liệu trên các server riêng biệt, hoặc tận dụng phần cứng phân tán thành ổ cứng để tận dụng dung lượng Các cách này cũng cải thiện được phần nào hiệu năng, nhưng vẫn dựa trên ổ đĩa cứng nên không cải thiện được nhiều

- Query result caches: loại này thường được thực hiện ở tầng ứng dụng và

được quản lý bởi một phần mềm đặc biệt, ẩn đi sự có mặt của cache với ứng dụng Với cách làm này, phần mềm caching tự động lưu kết quả truy vấn dữ liệu từ CSDL Nếu câu truy vấn sau trùng với câu truy vấn trước cả về cú pháp cũng như tham số, nó sẽ lấy kết quả từ trong cache ra trả về cho ứng dụng Cách này thực hiện đơn giản và phù hợp với loại ứng dụng mà chỉ chạy với một số ít câu lệnh giống nhau nhiều lần Các hệ quản trị CSDL dựa trên ổ đĩa truyền thống thường hỗ trợ cơ chế cache này khi lưu các câu truy vấn gần nhất trong kho, để giảm bớt các công việc cần thực hiện nếu không cần thiết, như phân tích tối ưu câu lệnh

- Object-relational mapping caches: cách này ẩn đi sự có mặt của CSDL với

ứng dụng bằng cách cung cấp các bộ mapping giữa object và dữ liệu trong CSDL Khi đó, lập trình viên chỉ làm việc với các object, các object này đã được mapping sẵn với các bảng dữ liệu trong CSDL Việc làm này sẽ được thực hiện bởi O/R mapping tool Lợi thế của cách này là tránh công đoạn mapping giữa mô hình đối tượng của ngôn ngữ lập trình với mô hình quan

hệ của CSDL

- Object caches: cách này thường tạo các kho chứa đối tượng để ứng dụng sử

dụng Các đối tượng này hướng nghiệp vụ hơn, thường không giống hoàn

toàn các bảng trong CSDL, có thể là một phần hoặc là kết quả join, tổng hợp của các nhiều đối tượng Đối tượng mới này được đưa vào và lấy ra khỏi kho bằng các API như put, get, insert, delete Kỹ thuật này có thể áp dụng trong việc cache các trang web cần hiển thị Khi có yêu cầu, ứng dụng chỉ cần lấy đối tượng này từ trong kho, mà không cần phải truy vấn tới CSDL

và join nhiều thông tin từ nhiều bảng nữa Tuy nhiên, cách làm này cũng chỉ phù hợp cho một lớp các bài toán cụ thể, hoặc các yêu cầu nghiệp vụ chuyên biệt

Qua trên cho thấy các kỹ thuật caching thường khá đơn giản về kiến trúc, thời gian thực hiện không nhiều, và có những hiệu quả nhất định Tuy nhiên, chúng thường không tổng quát và chỉ áp dụng cho một số bài toán với yêu cầu chuyên biệt

IMDB chuyển hẳn CSDL truyền thống lên RAM, với những tối ưu tương ứng,

và phù hợp với nhiều loại bài toán, yêu cầu khác nhau

II.3.4 NoSQL database

Sự ra đời của CSDL NoSQL là sự đánh dấu giải pháp cho các bài toán không thể thực hiện hiệu quả với CSDL quan hệ NoSQL là viết tắt của Not-only SQL, nghĩa

là “Không chỉ là SQL” NoSQL đã manh nha xuất hiện từ hơn chục năm, nhưng không được coi trọng, vì có các giải pháp cải tiến CSDL quan hệ để đáp ứng được bài toán

mà NoSQL định giải quyết Mãi đến vài năm trở lại đây, khi mạng xã hội trở thành một hiện tượng và phát triển rất mạnh mẽ, khiến số lượng dữ liệu tăng đột biến, đi kèm

là sự đa dạng về dữ liệu Bài toán Xử lý dữ liệu lớn đặt ra và trở nên cấp thiết Cơ sở

dữ liệu quan hệ không thể giải quyết tốt được yêu cầu Các loại CSDL NoSQL ra đời

và phát triển mạnh mẽ phục vụ yêu cầu này

Hadoop là một điểm sáng Nó là một framework mã nguồn mở tin cậy, có thể

mở rộng theo chiều ngang, và tính toán phân tán Nó giúp quản lý file dung lượng lớn

và có mô hình lập trình giúp tính toán phân tán, giúp tận dụng các phần cứng thông thường để giải quyết các bài toán mà lẽ ra phải dùng các phần cứng rất mạnh Hai thành phần quan trọng nhất của Hadoop là Hadoop Distributed File System (HDFS) –

hệ quản lý file phân tán, và Hadoop MapReduce – mô hình lập trình Mô hình triển khai của Hadoop gồm một master server và các slave server Khi có một yêu cầu về thực hiện tác vụ nào đó, tác vụ đó gửi đến master server, tại đó master server phân nhỏ công việc và gửi xuống thực hiện song song tại các slave Kết quả thực hiện được gom lại và trả lại ứng dụng tại master server

Hình II.6 – Hadoop và Hbase

Hadoop ưu việt là vậy, nhưng nó là framework tổng quát, và việc lập trình trên

nó tương đối phức tạp Từ đó, nhiều sub-project dựa trên Hadoop ra đời với các mục đích khác nhau, nhóm CSDL có Hbase Về phía ứng dụng, Hbase chỉ như một CSDL thông thường, nhưng các câu lệnh gửi tới Hbase để thực hiện sẽ được chuyển thành các nhiệm vụ cho Hadoop thực hiện Điều này tạo sự tiện dụng, dễ dàng cho người lập trình, mà vẫn tận dụng được sức mạnh của Hadoop

Tuy nhiên, mục đích phát triển Hadoop vẫn tập trung vào bài toán xử lý dữ liệu lớn trên các phần cứng thông thường, không quá quan trọng về tốc độ, chỉ cần xử lý được và trả lại kết quả Do đó, nếu xét theo khía cạnh cần cải tiến hiệu năng CSDL, giải quyết bài toán số lượng truy cập nhiều, với yêu cầu thời gian truy vấn nhỏ, NoSQL – cụ thể là Hadoop không có nhiều lợi thế so với các IMDB như Oracle TimesTen hay IBM solidDB

Hiện tại, có một số loại CSDL “lai”, nó là NoSQL nhưng lại dựa trên bộ nhớ, chúng được xếp vào nhóm IMDB

II.4 Ƣu nhƣợc điểm của IMDB

II.4.1 Ưu điểm

- Thời gian đáp ứng nhanh:

 Dữ liệu được đặt trong bộ nhớ, với các thuật toán (query optimizer, tìm kiếm,…) được thiết kế đặc thù cho dữ liệu trong bộ nhớ, loại bỏ các thành phần không cần thiết (buffer pool, I/O) của disk-based DB làm cho IMDB tăng tốc độ đáng kể, thậm chí đạt đến mức real-time

- Đáp ứng lượng truy vấn (thông lượng) cao:

 Disk-based DB sử dụng bộ đệm để lưu một số dữ liệu được sử dụng thường xuyên, nhằm làm tăng tốc độ truy xuất Tuy nhiên, khi có một lượng rất lớn các truy vấn, hoặc truy vấn lấy số lượng dữ liệu lớn (select *…), buffer pool không đáp ứng được yêu cầu, có thể dẫn đến treo, sập hệ thống CSDL

 IMDB lưu dữ liệu trong bộ nhớ, việc tìm kiếm chỉ là tìm kiếm địa chỉ

dữ liệu được lưu trong bộ nhớ Vì vậy, IMDB đáp ứng được số lượng truy vấn rất lớn

- Bền vững và có thể phục hồi (đảm bảo tính ACID):

 IMDB vẫn đảm bảo được tính bền vững qua các thuộc tính của một

hệ quản trị CSDL

 Riêng Durability: Tính bền vững của dữ liệu Sử dụng bộ nhớ sẽ làm mất hết dữ liệu khi tắt máy, nên một số IMDB cung cấp thêm tính năng ghi định kỳ dữ liệu trong bộ nhớ ra ổ đĩa cứng Sau có thể khôi phục lại DB bị sập từ những file này Tính năng này thường được cung cấp qua việc lưu trữ dữ liệu vào các file checkpoint và transaction log

- Tuân theo các chuẩn thế giới cho CSDL:

 Đa phần các sản phẩm IMDB đều hỗ trợ chuẩn kết nối từ ứng dụng bằng SQL chuẩn

 Hỗ trợ PL/SQL

 Hỗ trợ các kiểu kết nối chuẩn qua ODBC, JDBC

 Tương thích với nhiều nền tảng hệ điều hành: Windows, Unix/Linux, Solaris, AIX

- Có tương đối đầy đủ các tính năng như một CSDL quan hệ thông thường:

 Hỗ trợ truy cập đồng thời

 Tối ưu hóa truy vấn

 Tính sẵn sàng cao: IMDB đảm bảo tính sẵn sàng cao của dữ liệu bằng việc cung cấp cơ chế Replication với các tùy chọn khác nhau (active/standby, active/active) để đảm bảo dữ liệu luôn sẵn sàng khi xảy ra sự cố

- Một số tính năng nâng cao chuyên biệt:

 Cache: có những tình huống sử dụng IMDB như một CSDL trung gian giữa CSDL truyền thống và ứng dụng, trên IMDB chỉ lưu trữ dữ liệu hay được truy cập và cần hiệu năng cao Do đó, các sản phẩm IMDB thường cung cấp thêm cơ chế cache, giúp đồng bộ dữ liệu hai chiều giữa IMDB và CSDL truyền thống

 Tự động loại bỏ dữ liệu không cần thiết (data aging): để tiết kiệm dung lượng bộ nhớ chính, những dữ liệu không cần thiết có thể bị loại bỏ Các IMDB thường hỗ trợ hai cơ chế Data aging: loại bỏ dữ liệu theo thời gian, hoặc theo thuật toán LRU

II.4.2 Nhược điểm

- Dữ liệu được lưu trên bộ nhớ nên dung lượng bộ nhớ phải lớn hơn độ lớn toàn bộ dữ liệu, cộng thêm lượng RAM cho các tiến trình kết nối tới IMDB Hiện nay giá của bộ nhớ trong vẫn đắt hơn ổ đĩa cứng Tuy nhiên, xu hướng phần cứng: dung lượng bộ nhớ, ổ đĩa tăng 80%/năm; hiệu năng bộ nhớ tăng 10%/năm; tốc độ ổ đĩa cứng không tăng và giá cả bộ nhớ ngày càng giảm

- Khuyến cáo sử dụng của tất cả công nghệ IMDB là ứng dụng sử dụng kiểu kết nối trực tiếp/nhúng tới IMDB để đạt hiệu năng tối đa Nghĩa là, ứng dụng và IMDB phải triển khai trên cùng một máy vật lý

- Chưa nhiều sản phẩm IMDB hỗ trợ nâng cấp phần cứng theo chiều ngang

II.5 Kết luận chương 2

Chương này đã cung cấp những thông tin, kiến thức cơ sở về Cơ sở dữ liệu trên

bộ nhớ như khái niệm, kiến trúc, các đặc điểm tính năng Đồng thời, chương cũng có

sự so sánh IMDB với các công nghệ cạnh tranh khác để có cái nhìn đầy đủ về các giải pháp CSDL để cải thiện hiệu năng, từ đó đưa ra các điểm khác biệt nổi bật để lựa chọn IMDB Cuối cùng, chương tổng hợp những ưu nhược điểm của IMDB để người đọc có thể sử dụng một cách phù hợp

Chương 3: CÁC SẢN PHẨM CƠ SỞ DỮ LIỆU TRÊN BỘ NHỚ

Giải pháp Cơ sở dữ liệu trên bộ nhớ đã thu hút được sự quan tâm của các công

ty lớn cũng như của cộng đồng mã nguồn mở Dưới đây giới thiệu các sản phẩm nổi bật về IMDB

III.1 Sản phẩm thương mại

III.1.1 Oracle TimesTen

a/ Giới thiệu

Oracle TimesTen là một bộ sản phẩm của Oracle, gồm hai sản phẩm: CSDL dữ liệu trên bộ nhớ Oracle TimesTen IMDB, và Oracle IMDB Cache – cung cấp khả năng đồng bộ dữ liệu giữa CSDL Oracle và TimesTen Oracle TimesTen IMDB cho phép ứng dụng truy cập, xử lý, cập nhật dữ liệu nhanh hơn nhiều so với CSDL dựa trên ổ cứng truyền thống Nó rất thích hợp cho các chức năng đòi hỏi hiệu năng cao của các ứng dụng doanh nghiệp trong các lĩnh vực như viễn thông, tài chính, ngân hàng,…

Oracle TimesTen In-Memory Database (TimesTen - IMDB) là một cơ sở dữ liệu nằm trên memory Nó giúp tối ưu hóa các ứng dụng, làm tăng khả năng đáp ứng

và lượng input data lớn, như các ứng dụng viễn thông hay quân sự

IMDB và IMDB Cache tối ưu hóa bằng cách thay đổi cách lưu trữ dữ liệu lúc runtime Bằng cách quản lý dữ liệu trên bộ nhớ và tối ưu hóa cấu trúc dữ liệu và các thuật toán truy cập dữ liệu tương ứng, các thao tác với CSDL được thực thi với tốc độ

và hiệu quả cao nhất Điều này giúp TimesTen tăng khả năng đáp ứng cũng như lượng

dữ liệu đưa vào, thậm chí còn nhanh hơn fully-cached, disk-based RDBMS Thư viện của TimesTen và IMDB Cache được nhúng vào ứng dụng, bỏ qua giai đoạn chuyển đổi môi trường (context switching) và các kết nối mạng không cần thiết

Oracle IMDB Cache giúp đồng bộ dữ liệu hai chiều từ Oracle DB sang TimesTen Ngoài cách sử dụng TimesTen như một CSDL riêng rẽ, các hệ thống có thể

sử dụng IMDB cache cho các dữ liệu hay thay đổi và cần truy cập nhiều, và sử dụng CSDL Oracle cho các dữ liệu còn lại Dưới đây trình bày về IMDB Cache:

Cache grid:

Cache grid là một tập hợp các TimesTen DB phân tán, những DB này làm việc cùng nhau và cache dữ liệu từ Oracle DB, đồng thời đảm bảo tính gắn kết giữa những TimesTen DBs

Một grid chứa một hoặc nhiều grid member, các grid member quản lý dữ liệu thông qua mô hình dữ liệu quan hệ Một grid member cache dữ liệu từ một Oracle DB Mỗi grid member là một standalone TimesTen DB hoặc một active standby pair (một kiểu Replication của TimesTen DB gồm một active data store và standby data store)

Một grid node là các database của một grid member Một grid node có thể là: + Một standalone TimesTen DB hoặc

+ Active master DB và standby master DB trong một active standby pair

Như vậy nếu grid member là một standalone DB thì sẽ là một grid node Nếu grid member là một active standby pair sẽ gồm 2 grid nodes

Ví dụ: Một cache grid gồm 2 standalone DB và một active standby pair

Hình III.1 – Ví dụ về cache grid

Trong một cache grid, dữ liệu được tự động phân phối giữa những grid member, không dùng bộ nhớ chia sẻ Kiến trúc này cho phép dung lượng của một cache grid có thể “co giãn” dựa trên yêu cầu của ứng dụng Khi khối lượng công việc tăng hoặc giảm, một grid member mới được attach vào grid hoặc một grid member được detach từ grid Việc attach hoặc detach một grid member sẽ không ảnh hưởng đến các grid member khác

Cache instance: Dữ liệu từ Oracle được load vào TimesTen cache group trong các unit gọi là cache instance Một cache instance gồm một dòng trong bảng root table

và tất cả các dòng tương ứng (thông qua ràng buộc foreign key) trong các child table liên quan

Nguồn: Oracle

Hình III.2 – Ví dụ về cache group b/ Lịch sử phát triển

Oracle TimesTen IMDB được phát triển lần đầu bởi công ty TimesTen – một công ty phần mềm cung cấp các giải pháp xử lý sự kiện thời gian thực Năm 1992, phòng thí nghiệm HP khởi động nghiên cứu IMDB cho các ứng dụng mạng trong ngành công nghiệp viễn thông Bà Marie-Anne Neimat làm việc tại phòng thí nghiệm này, sau đã tách ra lập một công ty riêng mang tên TimesTen năm 1996 Ban đầu, công ty tập trung vào quản lý giao tác, cấu trúc dữ liệu phân tán cho sản phẩm TimesTen TimesTen được giới thiệu lần đầu vào năm 1999 Đến năm 2001, TimesTen và TimesTen cache được phát hành

TimesTen được mua lại bởi Oracle vào 20/06/2005 Năm 2007, Oracle TimesTen 7.0 được phát hành, đây là bản phát hành chính thức đầu tiên Đến nay, Oracle TimesTen đã có phiên bản 11.2.2

c/ Kiến trúc

 Shared libraries

Các routine (thường trình – tương tự như hàm) thực hiện các chức năng của TimesTen được ghép lại trong thư viện chia sẻ để người phát triển sử dụng trong các ứng dụng cụ thể như một phần của các tiến trình ứng dụng Mục đích của những thư viện chia sẻ này trái ngược với các quy ước trong RDBMS – thường được thực thi như

bộ sưu tập các chương trình tự chạy để các ứng dụng kết nối đến thông qua mô hình client/server Các ứng dụng cũng có thể sử dụng kiểu kết nối client/server để truy cập TimesTen DB, tuy nhiên cách tốt nhất là sử dụng kiểu kết nối direct driver

Nguồn: Oracle

Hình III.3 – Kiến trúc TimesTen IMDB

 Memory-resident data structures

TimesTen DB nằm hoàn toàn trong bộ bộ nhớ chính lúc runtime Nó được duy trì trong phần bộ nhớ chia sẻ trong hệ điều hành và chứa toàn bộ user data, index, system catalog, log buffer, lock table và temp space Nhiều ứng dụng có thể chia sẻ một DB, cũng như một ứng dụng có thể truy cập nhiều DB trên cùng một hệ thống

 Database processes

TimesTen gán mỗi tiến trình riêng biệt cho mỗi DB để thực thi các tác vụ sau:

- Load DB vào bộ nhớ từ một checkpoint file trên ổ đĩa cứng

- Phục hồi DB nếu cần sau khi load vào bộ nhớ

 Checkpoint and log files

Checkpoint files lưu một ảnh của DB trên ổ đĩa cứng TimesTen sử dụng dual checkpoint files để tăng độ an toàn, phòng trường hợp hệ thống bị sập khi việc thực hiện checkpoint đang được thực hiện Những thay đổi ở DB được ghi lại trong transaction logs và được ghi vào ổ đĩa cứng định kỳ Khi một DB cần phục hồi, TimesTen kết hợp DB checkpoint trên đĩa cứng với các transaction trên log files

Nguồn: Oracle

 Replication

TimesTen replication cho phép đạt đến mức sắn sàng dữ liệu gần như tuyệt đối, hoặc phân chia workload bằng cách gửi các update giữa các server Master server gửi những update và subscriber server nhận những update ấy Một server có thể vừa đóng vai trò master và subscriber trong kiến trúc bidirectional replication Hệ thống phát hiện và giải quyết xung đột của TimesTen được sử dụng để thiết lập tính chính xác của

dữ liệu trong trường hợp nhiều truy vấn update cùng một dữ liệu tại một thời điểm

d/ Đặc điểm và tính năng

- TimesTen API:

TimesTen hỗ trợ kết nối thông qua các giao diện lập trình ứng dụng gồm ODBC, JDBC, OCI, DBP.net TimesTen cũng cung cấp các thủ tục và tiện ích kế thừa chức năng ODBC, JDBC và OCI để phục vụ cho các hoạt động đặc thù của TimesTen, cũng như hỗ trợ PL/SQL

- Điều khiển truy cập:

TimesTen và IMDB Cache được cài đặt với quyền truy cập cho phép chỉ có người dùng với những quyền được cấp mới có thể truy cập sử dụng các tính năng của TimesTen TimesTen sử dụng SQL chuẩn để thiết lập, gán quyền cho tài khoản

- Kết nối CSDL:

TimesTen hỗ trợ hai kiểu kết nối tới CSDL là trực tiếp (direct) và khách/chủ (client/server) Kết nối trực tiếp cho tốc độ truy cập dữ liệu nhanh nhất, nhưng ứng dụng phải đặt cùng máy vật lý với TimesTen

- Tính bền vững:

TimesTen cho phép ghi log vào ổ cứng để sao lưu và phục hồi hệ thống khi cần thiết Log được ghi đồng bộ hoặc bất đồng bộ sau mỗi transaction

- Tối ưu hóa truy vấn:

TimesTen và IMDB Cache có cơ chế tối ưu hóa truy vấn dựa trên các thông tin

về chỉ mục, bảng và lệnh order by trong câu truy vấn TimesTen cung cấp range, hash

và bitmap index

- Truy cập đồng thời:

TimesTen và IMDB cache cung cấp đầy đủ sự hỗ trợ cho CSDL chia sẻ Người dùng có thể chọn phương pháp tốt nhất cho ứng dụng của mình bằng cách cân bằng các tham số thời gian response time, thông lượng

- Tự động loại bỏ dữ liệu

TimesTen cung cấp khả năng tự động loại bỏ dữ liệu không cần thiết Có hai phương pháp: loại bỏ dữ liệu quá cũ dựa trên thời gian , hoặc loại bỏ dữ liệu ít được sử dụng nhất

- Hỗ trợ globalization (quốc tế hóa)

TimesTen hỗ trợ lưu trữ, truy vấn và xử lý dữ liệu với rất nhiều ngôn ngữ, character set Cấu hình characterset trong tham số kết nối cho phép ứng dụng chạy trên một characterset khác với TimesTen, việc chuyển đổi này được thực hiện tự động

- Quản trị và tiện ích:

TimesTen cung cấp các tiện ích điển hình của CSDL như truy vấn bằng SQL, sao lưu và phục hồi, migrate dữ liệu Rất nhiều các tiện ích quản trị được cung cấp bởi TimesTen sử dụng SQL extension TimesTen cũng cung cấp các thủ tục có sẵn, các tiện ích dòng lệnh để kiểm tra trạng thái kết nối, khóa, replication,

- Replication:

TimesTen cung cấp khả năng replication thời gian thực giữa các máy chủ cho mục đích High availability và load sharing TimesTen cung cấp mô hình active-active, active-standby replication, chuyển dữ liệu đồng bộ hoặc bất đồng bộ, phát hiện xung đột, và tự động đồng bộ sau khi một máy chủ hỏng được phục hồi

- IMDB Cache:

Oracle IMDB cache tạo ra một cache thời gian thực, có thể cập nhật cho dữ liệu

từ CSDL Oracle IMDB cung cấp khả năng đồng bộ hai chiều, từ CSDL Oracle sang TimesTen và ngược lại

III.1.2 IBM SolidDB

a/ Giới thiệu

IBM solidDB là một dòng sản phẩm được phát triển và cung cấp bởi IBM Nó gồm hai sản phẩm là CSDL trên bộ nhớ IBM solidDB, và solidDB Universal Cache IBM solidDB là một CSDL quan hệ đầy đủ tính năng, dựa trên bộ nhớ, cung cấp tốc

độ và tính sẵn sàng rất cao để thỏa mãn yêu cầu về hiệu năng và tính tin cậy của các ứng dụng thời gian thực SolidDB universal cache là phần mềm cache dữ liệu từ các CSDL truyền thống (DB2, Infomix, Oracle, SQL server, Sybase) lên solidDB, giúp tốc

độ truy vấn dữ liệu tăng lên nhiều lần

b/ Lịch sử phát triển

Solid Information Technology là một hãng cung cấp hàng đầu các giải pháp cơ

sở dữ liệu nhanh, kết nối liên tục và với mức giá hợp lý Khởi đầu thành lập vào năm

1992 ở Helsinki, Phần Lan, hãng Solid sớm đã có tầm nhìn về cung cấp các giải pháp

cơ sở dữ liệu cho phép truy cập đến dữ liệu nhanh chóng, không gặp thất bại Bắt đầu với sản phẩm đầu tiên phát hành vào năm 1994, Solid đã phục vụ hầu hết các nhu cầu

Nguồn: IBM