Luận văn thạc sĩ VNU UET ứng dụng FoundationDB trong việc nâng cao hiệu năng xử lý truy vấn trực tuyến

Hệ quản trị CSDL NoSQL có khả năng tận dụng rất tốt phần cứng kèm theo khả năng mở rộng, tăng cường năng lực xử lý đơn giản nhưng lại vấp phải một số khiếm khuyết như: khó tiếp cận đối v

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

Nguyễn Mạnh Thắng

ỨNG DỤNG FOUNDATIONDB TRONG VIỆC NÂNG CAO HIỆU NĂNG XỬ LÝ TRUY VẤN TRỰC TUYẾN Ngành: Công nghệ thông tin

Chuyên ngành: Hệ thống thông tin

Mã số: 60480104

LUẬN VĂN THẠC SỸ CÔNG NGHỆ THÔNG TINNGƯỜI HƯỚNG DẪN KHOA HỌC:Tiến sĩ Nguyễn Ngọc Hóa

HÀ NỘI - 2014

LỜI CAM ĐOAN

Tôi xin cam đoan bản luận văn “Ứng dụng FoundationDB trong việc nâng cao hiệu năng xử lý truy vấn trực tuyến”là công trình nghiên cứu và thử nghiệm của tôi, tại đơn vị công tác, tham khảo các nguồn tài liệu đã được chỉ rõ trong trích dẫn và danh mục tài liệu tham khảo Các nội dung công bố và kết quả trình bày trong luận văn này là trung thực và chưa từng được ai công bố trong bất cứ công trình nào

LỜI CẢM ƠNTôi xin gửi lời cảm ơn tới các thầy, cô Trường Đại học Công nghệ, Đại học Quốc gia Hà Nội đã tận tình giảng dạy và truyền đạt kiến thức trong suốt khóa học cao học vừa qua Xin chân thành cảm ơn TS.Nguyễn Ngọc Hóa, người đã định hướng đề tài, trực tiếp hướng dẫn và tận tình chỉ bảo tôi trong suốt quá trình thiết kế, xây dựng và hoàn thiện luận văn này

Tôi xin chân thành cảm ơn các anh chị, các bạn đồng nghiệp trong phòng Phát triển phần mềm - Trung tâm Công nghệ thông tin BIDV đã tạo điều kiện cho tôi tìm hiểu hệ thống và tạo môi trường thử nghiệm

Tôi xin bày tỏ lòng biết ơn sâu sắc tới gia đình, vợ, con… những người đã luôn

ở bên cạnh, động viên, chia sẻ cùng tôi trong quãng thời gian học cao học cũng như quá trình thực hiện luận văn cao học

MỤC LỤC

LỜI CAM ĐOAN 3

LỜI CẢM ƠN 4

MỤC LỤC 5

DANH MỤC CÁC KÝ HIỆU CÁC TỪ VIẾT TẮT 8

DANH MỤC CÁC HÌNH VẼ 9

MỞ ĐẦU 11

CHƯƠNG 1: TỔNG QUAN FOUNDATIONDB 13

1.1 Tổng quan hệ thống xử lý giao tác trực tuyến - OLTP 13

1.1.1 Hệ thống OLTP 13

1.1.2 Nguyên tắc thiết kế, xây dựng hệ thống OLTP 13

1.2 FoundationDB[4] 14

1.2.1 NewSQL[5] 14

1.2.2 Key-value store 14

1.2.2.1 Chống chịu lỗi 14

1.2.2.2 Mở rộng theo hướng tuyến tính 16

1.2.2.3 Hỗ trợ mạnh giao tác ACID 16

1.2.2.4 Đa dạng mô hình dữ liệu 18

1.2.3 Sql Layer 21

1.2.3.1 Kiến trúc vật lý 21

1.2.3.2 Các tính năng chính 23

1.2.3.3 Tích hợp ORM 24

1.3 Quản trị FoundationDB[4] 24

1.3.1 Khởi động và dừng 24

1.3.2 Tập tin Cluster 24

1.3.3 Thêm node vào cluster 25

1.3.4 Loại bỏ node từ cluster 26

1.3.5 Xem thông tin trạng thái cluster 26

1.3.6 Quản lý tập tin trace 28

1.3.7 Gỡ bỏ 28

1.3.8 Nâng cấp 28

1.4 Kết luận 29

CHƯƠNG 2: PHÁT TRIỂN ỨNG DỤNG XỬ LÝ GIAO TÁC TRỰC TUYẾN VỚI FOUNDATIONDB 30

2.1 Xây dựng ứng dụng với API của FoundationDB[4] 30

2.1.1 Mô hình dữ liệu 30

2.1.2 Quản lý không gian tên 30

2.1.3 Làm việc với các hàm APIs 30

2.1.4 Cơ bản về giao tác trong FoundationDB 30

2.2 Quản trị SQL Layer[4] 31

2.2.1 Cài đặt SQL layer 31

2.2.2 Khởi động và dừng dịch vụ trên môi trường windows 31

2.2.3 Công cụ client 33

2.2.4 JVM warmup 33

2.2.5 Quản lý phiên người dùng (Managing User Sessions) 33

2.2.6 Sử dụng tệp tin LOG 34

2.2.7 Gỡ bỏ SQL Layer 35

2.2.8 Nâng cấp 35

2.3 Xây dựng ứng dụng tích hợp với SQL Layer[4] 35

2.3.1 Kiểu dữ liệu 35

2.3.2 Truy cập với SQL 36

2.3.2.1 Tạo bảng và truy vấn dữ liệu 37

2.3.2.2 Tạo chỉ mục(index) 39

2.3.3 Thủ tục và hàm 41

2.3.3.1 Functions được xây dựng sẵn của SQL layer 41

2.3.3.2 Lập trình thủ tục và hàm 44

2.4 Kết luận 46

CHƯƠNG 3: XÂY DỰNG ỨNG DỤNG THỰC NGHIỆM 46

3.1 Bài toán đặt ra 46

3.2 Thiết kế và cài đặt hệ thống thử nghiệm 48

3.2.1 Các mô hình kiến trúc 48

3.2.1.1 Mô hình hoạt động hiện tại 48

3.2.1.2 Mô hình vật lý hiện tại của hệ thống BIB 49

3.2.1.3 Mô hình giải pháp BIDV Online 50

3.2.2 Thiết kế cơ sở dữ liệu 52

3.2.2.1 Thiết kế bảng, khóa, chỉ mục 52

3.2.2.2 Khối lượng dữ liệu 52

3.2.3 Thiết kế chức năng và giao diện 53

3.2.4 Thiết kế máy chủ vật lý-cluster 59

3.2.5 Cài đặt chương trình 60

3.3 Đánh giá so sánh FoundationDB và Oracle 60

KẾT LUẬN 63

TÀI LIỆU THAM KHẢO 64

DANH MỤC CÁC KÝ HIỆU CÁC TỪ VIẾT TẮT

ACID Atomicity, Consistency, Isolation, và Durability BIB BIDV Internet Banking

DANH MỤC CÁC HÌNH VẼ

Chương 1 : Hình 1: Chức năng của CSDL OLTP 13

Chương 1 : Hình 2: mô hình cluster và các bị lỗi 15

Chương 1 : Hình 3: minh họa về khả năng mở rộng của KVS 16

Chương 1 : Hình 4: Đa dạng mô hình dữ liệu 18

Chương 1 : Hình 5: mô hình tích hợp ứng dụng với FDB 19

Chương 1 : Hình 6: Mô hình logic của KVS 20

Chương 1 : Hình 7: Kiến trúc vật lý đơn giản của SQL layer 21

Chương 1 : Hình 8: Kiến trúc SQL layer được khuyến nghị 22

Chương 1 : Hình 9: Cấu hình cluster cơ bản bao gồm hai nodes 25

Chương 1 : Hình 10: trạng thái của cluster 27

Chương 2: Hình 1: dịch vụ SQL layer trên window 32

Chương 2: Hình 2: ví dụ đánh chỉ mục nhóm 40

Chương 3: Hình 1: Các chức năng chính của hệ thông BIDV Internet Banking 47

Chương 3: Hình 2: Mô hình hoạt động của BIB 48

Chương 3: Hình 3: Mô hình vật lý của BIB 49

Chương 3: Hình 4: Mô hình BIDV online 50

Chương 3: Hình 5: Mô hình vật lý hệ thống BIDV Online 51

Chương 3: Hình 6: thiết kế bảng BIDV Online 52

Chương 3: Hình 7: biểu đồ Usecase BIDV Online 53

Chương 3: Hình 8: Màn hình giao diện đăng nhập 54

Chương 3: Hình 9: Màn hình chức năng quản lý chi nhánh 55

Chương 3: Hình 10: Thêm mới người dùng 56

Chương 3: Hình 11: sửa thông tin người dùng 56

Chương 3: Hình 12: Thêm mới tài khoản cho khách hàng 57

Chương 3: Hình 13: chức năng kiểm tra tải hệ thống 57

Chương 3: Hình 14: chức năng chuyển khoản 58

Chương 3: Hình 15: Chức năng vấn tin tài khoản 58

Chương 3: Hình 16: mô hình cluster FDB của BIDV Online 60

Chương 3: Hình 17: kết quả cấu hình cluster 60

Chương 3: Hình 18: cấu hình connection pool tomcat 61

MỞ ĐẦU

 Giới thiệu Trong các hệ thống lớn tài chính – ngân hàng – chứng khoán một ngày phải giải quyết số lượng truy vấn và giao dịch rất lớn phát sinh trong quá trình tác nghiệp nên việc đảm bảo tải cho hệ thống là rất quan trọng Đồng thời các truy vấn và giao dịch phải đáp ứng tính chính xác và phần lớn trong đó phải đảm bảo về mặt thời gian xử lý cho kết quả đầu ra gần như trực tuyến hoặc có thể coi là trực tuyến

Hiện nay, các hệ quản trị CSDL truyền thống như Oracle, MS SQL Server…

không đáp ứng được những dịch vụ có số lượng truy vấn đồng thời lớn [1-2] Hơn nữa, các mô hình quản trị CSDL truyền thống này ban đầu đều được xây dựng trên các hệ thống máy tính đơn vi xử lý (CPU) Vì thế, việc tận dụng các bộ vi xử lý đa nhân hay đa vi xử lý mới chỉ được quan tâm ở mức hệ điều hành Có rất nhiều cách tiếp cận mới theo hướng NoSQL để giải quyết những vấn đề đặt ra ở trên [2-3] Hệ quản trị CSDL NoSQL có khả năng tận dụng rất tốt phần cứng kèm theo khả năng mở rộng, tăng cường năng lực xử lý đơn giản nhưng lại vấp phải một số khiếm khuyết như: khó tiếp cận đối với những nhà phát triển chưa có kinh nghiệm, một số hệ quản trị CSDL NoSQL không hỗ trợ thực thi các giao tác Do đó từ đầu năm 2011 một lớp

hệ quản trị CSDL mới ra đời kết hợp các điểm mạnh của các hệ quản trị NoSQL và SQL truyền thống Lớp hệ quản trị CSDL này được gọi là NewSQL, đều hỗ trợ mô hình dữ liệu quan hệ và sử dụng ngôn ngữ truy vấn SQL Một trong số đó là FoundationDB được thiết kế để hoạt động trên cluster, nhà phát triển có thể truy vấn, tương tác với FoundationDB thông qua ngôn ngữ SQL nhằm tăng khả năng tận dụng phần cứng tối đa và tăng khả năng tương thích với các ứng dụng đã xây dựng trước đây có truy vấn CSDL thông qua SQL do đó cải thiện hiệu năng xử lý giao tác trực tuyến

 Mục tiêu của luận văn Với vấn đề đã được đặt ra như ở phần mở đầu, mục tiêu của luận văn này bao gồm:

- Nghiên cứu, tìm hiểu được cách thiết kế hệ thống OLTP trong việc tối ưu xử

lý các giao tác trên những hệ thống đa vi xử lý

- Nghiên cứu, tìm hiểu hệ quản trị CSDL FoundationDB áp dụng vào bài toán

cụ thểQuản lý giao dịch chuyển tiền BIDV online Với mục đích khắc phục toàn diện thực trạng của hệ thống phần mềm “BIDV internet banking” như :

 Khó khăn khi đáp ứng yêu cầu nhiều giao dịch trên giây (TPS)

 Hệ thống không ổn định và thường xuyên quá tải khi lượng giao dịch đồng thời lớn

 Chưa tận dụng được lợi thế phần cứng máy chủ đa nhân, cluster

- Phát triển thử nghiệm ứng dụng và so sánh đánh giá hiệu năng với một số hệ quản trị truyền thống

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

Mở đầu: Giới thiệu về đề tài luận văn, tính thiết thực của đề tài và tổ chức của luận văn

Chương 1 Tổng quan về FoundationDB

- Các yêu cầu về thiết kế hệ thống OLTP

- Giới thiệu về FoundationDB

o Key-Value Store

o SQL Layer

- Quản trị FoundationDB

o Cài đặt cấu hình FoundationDB trên cluster

o Sao lưu và khôi phục

Chương 2 Phát triển ứng dụng xử lý giao tác trực tuyến với FoundationDB

- Xây dựng ứng dụng với API của FoundationDB

- Xây dựng ứng dụng tích hợp với SQL Layer

- Quản trị ứng dụng với SQL Layer Chương 3 Thực nghiệm

- Bài toán đặt ra: Quản lý giao dịch chuyển tiền-BIDV Online

- Thiết kế và cài đặt hệ thống website

- Kết quả thu được của hệ thống

- Xây dựng công cụ đánh giá hiệu năng xử lý so với các hệ cơ sở dữ liệu truyền thống

Kết luận chung và những hướng phát triển tiếp theo: Tổng kết những kết quả đạt được qua quá trình hoàn thành đề tài luận văn; đề ra hướng phát triển, hoàn thiện cho đề tài nghiên cứu

CHƯƠNG 1: TỔNG QUAN FOUNDATIONDB

1.1 Tổng quan hệ thống xử lý giao tác trực tuyến - OLTP

Chương 1 : Hình 1: Chức năng của CSDL OLTP 1.1.2 Nguyên tắc thiết kế, xây dựng hệ thống OLTP

Để xây dựng một hệ thống OLTP, nhà thiết kế phải dự đoán, đánh giá được số lượng người dùng đồng thời mà không làm ảnh hưởng đến hiệu năng chung của hệ thống Các yếu tố sau đây có ảnh hưởng quyết định đến hiệu năng của một hệ thống OLTP

1.2 FoundationDB[4]

1.2.1 NewSQL[5]

NewSQL là một lớp CSDL quan hệ hướng đến việc cung cấp khả năng mở rộng hiệu năng giống như hệ CSDL NoSQL phục vụ cho nhu cầu đọc ghi lớn của hệ thống OLTP trong khi vẫn đảm bảo tính ACID của các hệ CSDL quan hệ truyền thống

Thuật ngữ này lần đầu tiên được sử dụng bởi 451 Group analyst Matthew Aslett trong một bài báo năm 2011 nghiên cứu và thảo luận về sự phát triển của hệ thống CSDL mới như một thách thức cho các nhà cung cấp Nhiều hệ thống doanh nghiệp cần có khả năng mở rộng quy mô nhưng không thể sử dụng NoSQL do chúng không cung cấp đầy đủ các yêu cầu về quan hệ dữ liệu và giao tác Các giải pháp trước đây thường là mua một máy chủ CSDL mạnh hơn hoặc phát triển phần mềm lớp giữa tùy chỉnh và phân phối các truy vấn trên các nút máy chủ CSDL quan hệ truyền thống Cả hai phương pháp này đều tốn kém nên không nhiều doanh nghiệp lựa chọn

Do đó trong bài báo này Matthew Aslett đã thảo luận về cách NewSQL khởi đầu và đang sẵn sàng để thách thức các nhà cung cấp thương mại đặc biệt là Oracle

Mặc dù các hệ thống NewSQL khác nhau rất nhiều trong kiến trúc của chúng nhưng có hai đặc tính chung là tất cả đều hỗ trợ các mô hình dữ liệu quan hệ và sử dụng ngôn ngữ truy vấn SQL Những ứng dụng mà NewSQL hướng tới có số lượng lớn giao tác có thời gian sống ngắn, tác động đến một nhóm dữ liệu nhỏ thông qua các chỉ mục (index), và có tính lặp lại giao tác với các giá trị đầu vào khác nhau Một trong những hệ CSDL NewSQL đầu tiên là H-Store

1.2.2 Key-value store

Đây là lớp nằm ở dưới cùng trong thiết kế của FoundationDB, như một nền tảng lưu trữ Key-value Store là một CSDL kết hợp khả năng mở rộng(scalability), chống lỗi(fault-tolerance), có hiệu năng rất tốt và hỗ trợ mạnh mẽ giao tác ACID đa khoa (multi-key ACID transactions)

1.2.2.1 Chống chịu lỗi

Khả năng chịu lỗi được đặc trưng bởi số lượng, thời gian, và khả năng dữ liệu

và dịch vụ bị mất có thể xảy ra

Chương 1 : H

 Phân tán và nhân bản Key-Value Store đượsẻ(distributed shared-nothing) Ki

hệ thống chỉ chạy trên một máy tínhvật lý xảy ra sự cố KVS chia dbản sao ra các máy chủ lưu trữ

KVS có thể chịu được trong tối đa vài giây và dữ liệu đư

bị ảnh hưởng Một máy tính bnày là rất cần thiết

 Chiến lược phân tán dữTrong trường hợp nhiềkhả năng dịch vụ có thể bị mấchỉ có một số lượng hữu hạn các bvực lưu trữ của các máy tính

Bất kỳ một hệ thống phân tán nào đ

dữ liệu VD: khi chúng ta có mchia ra một triệu phần và mỗi phcùng bị lỗi thì khả năng mất mát dmột con số khả năng xảy ra lỗi như v

 Giả định Chúng ta có thể nhận ra rnhư các máy chủ chung một k

để phân tán các bản sao các m

bị lỗi cùng nhau là thấp nhất

Chương 1 : Hình 2: mô hình cluster và các bị lỗi

ợc xây dựng trên kiến trúc phân tán không chia nothing) Kiến trúc này mang lại rất nhiều ưu điểm so v

t máy tính tránh trường hợp hệ thống gặp lỗi khi máy tính KVS chia dữ liệu thành nhiều phần và phân tán chúng thành nhi

ữ khác nhau, các máy chủ này kết nối mạng v

c sự hỏng hóc của một máy tính với dịch vụ

u được bảo toàn, dù vậy thì thông lượng của h

t máy tính bị hỏng hóc là lỗi rất phổ biến, do đó khả năng ch

ữ liệu

ều máy tính bị hỏng hóc, KVS vẫn có thể giao d

ất, gián đoạn Tuy nhiên dữ liệu bị mất có th

n các bản sao của các phần dữ liệu được tạo ra trên khu

ng phân tán nào đều phải đối mặt với một xác su

u VD: khi chúng ta có một hệ thống cluster bao gồm 40 máy tính, d

i phần được sao chép ở bốn máy tính, khi 4 máy tính đó

t mát dữ liệu là có thể xảy ra Qua tính toán chúng ta có

i như vậy rất thấp khoảng mười phần triệu

n ra rằng các máy tính có xu hướng xảy ra lỗ

t kết nối mạng, nguồn điện KVS có thể chọn các máy tính

n sao các mảnh dữ liệu sao cho khả năng xảy ra việc các máy tính

n trúc phân tán không chia

giao dịch với

t có thể xảy ra do

o ra trên khu

t xác suất mất mát

m 40 máy tính, dữ liệu được

n máy tính, khi 4 máy tính đó Qua tính toán chúng ta có

ỗi cùng nhau

n các máy tính

c các máy tính

 Các loại lỗi khác

Có rất nhiều các loại lỗkết nối lỗi, hiệu suất máy tính bthử nghiệm trên môi trường giđảm bảo an toàn cho dữ liệu

1.2.2.2 Mở rộng theo hướng tuy

Do sử dụng kiến trúc phân tán không chia sbằng việc thêm máy vật lý vào cluster ch

năng của một máy Khả năng mthành công Nó cũng là một trong ba thành phđến hiệu năng chung của hệ th

 Sự mềm dẻo Khả năng thích ứng và thay đ1.2.2.3 Hỗ trợ mạnh giao tác ACID

@fdb def

# Read

a =

ỗi, hỏng hóc khác nhau như: đầy đĩa cứng lưu tr

t máy tính bị suy hao, lỗi hệ điều hành…KVS được xây d

ng giả lập các loại lỗi này để nâng cao khả năng ch

ng tuyến tính

n trúc phân tán không chia sẻ nên KVS có thể mở rộ

t lý vào cluster chứ không phải chỉ mở rộng bằng cách tăng khnăng mở rộng là một thuộc tính cần thiết cho m

t trong ba thành phần ảnh hưởng lẫn nhau và thống bao gồm: Hiệu năng cao, Sự mở rộng

Chương 1 : Hình 3: minh họa về khả năng mở rộng của KVS

u năng cao nhất cho một cấu hình

ch vụ hiệu quả ở các mức độ mở rộng khác nhau

ng và thay đổi quy mô đơn giản

nh giao tác ACID

@fdb transactional example ( tr ):

Read two values from the database

tr get ('a')

ng lưu trữ, mạng

c xây dựng và năng chịu lỗi và

b = tr get ('b')

# Write two key-value pairs to the database

tr set ('c', a + )

tr set ('d', a + ) example ( db )

Giao tác ACID là mô hình lập trình đơn giản và mạnh mẽ nhất để giải quyết các vấn đề liên quan đến tính đồng thời KVS là một trong số ít CSDL phân tán cung cấp đầy đủ giao tác ACID với hiệu năng cao

 Giao tác Một giao tác được định nghĩa là một tập các thao tác đọc ghi vào CSDL được

xử lý như một thao tác với một vài thuộc tính quan trọng Thứ nhất tất cả các thao tác đọc đều đọc vào một ảnh của CSDL(không thấy được thay đổi của dữ liệu khi có các giao tác thực thi đồng thời) Thứ hai các thao tác ghi trong cùng một giao tác thì tất cả đều thành công hoặc tất cả đều thất bại Cuối cùng khi giao tác hoàn thành(commit) những thay đổi dữ liệu do thao tác ghi đều được lưu trữ vĩnh viễn vào CSDL.Mọi ứng dụng đều có nhu cầu hỗ trợ nhiều người dùng đồng thời, nên cần được xây dựng để sử dụng các giao tác có đầy đủ tính ACID Giao tác ngày càng đóng vai trò quan trọng trong sự phát triển của NoSQL

 Giao tác giải quyết sự đồng thời

Sự đồng thời (Concurrency) xảy ra khi có nhiều người dùng, hay một phần của ứng dụng đọc và ghi vào cùng một dữ liệu cùng một lúc Giao tác giúp cho việc quản

lý sự đồng thời đơn giản hơn cho nhà phát triển Thuộc tính chính của giao tác dễ đạt được là tính cô lập (Isolation) Khi một hệ thống đảm bảo rằng giao tác thực sự được

cô lập, nhà phát triển có thể coi mỗi giao tác là thực thi tuần tự dù thực sự chúng đang thực thi đồng thời.Một vài hệ thống chỉ cung cấp các giao tác ACID cho một tập hạn chế các chế độ hoạt động, thông thường bị giới hạn bởi cấu trúc của mô hình dữ liệu

Tuy nhiên, sức mạnh thật sự của giao tác nằm ở chỗ chúng có thể được định nghĩa bởi nhà phát triển trên bất cứ tập yếu tố dữ liệu nào Một nhà phát triển làm việc với KVS

có thể định nghĩa các giao tác đọc và ghi bất cứ số lượng bộ key-value Khi nhà phát triển có thể tự do định nghĩa các giao tác mà không gặp rào cản nào, họ có thể sử dụng giao tác như các khối cơ bản của ứng dụng

 Giao tác tăng khả năng trừu tượng Giao tác cho phép xây dựng các lớp trừu tượng một cách đơn giản và hiệu quả cung cấp khả năng mở rộng để hỗ trợ đa dạng mô hình dữ liệu Mô hình dữ liệu được

tối ưu hóa cho biểu đồ, tài liệthể được cài đặt ở các lớp bên trên ctượng dữ liệu đơn lẻ trong m

khóa-giá trị Giao tác làm cho nó đơn giđóng gói các thao tác cập nhậ

(Atomic units).Những lợi ích mà giao tác mang lhoạt về mô hình dữ liệu cấp cao Chúng có thhơn trong một mô hình cụ thể

1.2.2.4 Đa dạng mô hình dữ li

Chương 1 : HKiến trúc lớp độc đáo cliệu của nó Điều này cho phép các nhà phát trivẫn tiếp tục lưu trữ dữ liệu trong m

ệu, dữ liệu tổ chức theo cột, hay dữ liệu quan h

p bên trên của KVS Trong hầu hết các trường htrong một mô hình cao cấp hơn sẽ được sắp xếp trên nhi

ao tác làm cho nó đơn giản để thực hiện các ánh xạ này b

ật vào các bộ khóa –giá trị trong các đơn v

i ích mà giao tác mang lại còn lớn hơn là một lự

p cao Chúng có thể cho phép một đại diện dữ li

liệu

Chương 1 : Hình 4: Đa dạng mô hình dữ liệu

c đáo của KVS tách riêng công nghệ lưu trữ và

u này cho phép các nhà phát triển tạo ra các lớp mà họ c

u trong một hệ thống có khả năng mở rộng

u quan hệ đều có

ng hợp, một đối

p trên nhiều bộ này bằng cách trong các đơn vị nguyên tử

ựa chọn linh liệu hiệu quả

và mô hình dữ cần trong khi

Chương 1 : Hình 5: mô hình tích hợp ứng dụng với FDB

 Lớp ứng dụng có thể thao tác trực tiếp với KVS thông qua api

 SQL layer hoặc Your Layer mô hình dữ liệu mới có khả năng tương thích với

hệ thống có sẵn hoặc phục vụ như một framework

 Lớp dưới cùng là KVS tất cả dữ liệu được lưu trữ ở đây

Chương 1 : Hình 6: Mô hình logic của KVS

1.2.3 Sql Layer

SQL layer là một lớp phthừa các đặc tính của KVS SQL layer là phù hquyết bài toán nhiều người dùng

nguồn mở

 Chống chịu lỗi (Fault tolerance)

 Mở rộng được (Scalable)1.2.3.1 Kiến trúc vật lý

Chương 1 : HMột hệ thống được xây d

 Trên cùng là lớp ứng ddụng, máy chủ web đây là nơi

 Ở giữa là lớp SQL layer bao gSQL hoặc truy cập đối tưFoundationDB Cluster

thủ tục hay các hàm (Stored Procedure, Functions)

phần mềm trung gian(engine) nó lưu dữ liệu

a KVS SQL layer là phù hợp nhất cho các ứng dụng OLTP gi

i dùng đồng thời Đặc biệt SQL layer là mộ

i (Fault tolerance)

c (Scalable)

Chương 1 : Hình 7: Kiến trúc vật lý đơn giản của SQL layer

c xây dựng với FoundationDB thường bao gồm ba l

ng dụng (Application Layer) bao gồm nhiều máy chweb đây là nơi ứng dụng triển khai và chạy

p SQL layer bao gồm nhiều tiến trình SQL layer cung c

i tượng vào lớp ứng dụng SQL layer lưu dFoundationDB Cluster Một phần ứng dụng có thể nhúng vào lớp này như các

c hay các hàm (Stored Procedure, Functions)

n trình SQL layer cung cấp giao tiếp

ng SQL layer lưu dữ liệu trong

p này như các

 Dưới cùng là FoundationDB cluster (KVS cluster) xcủa hệ thống Nó nên đư

mức chống chịu lỗi mong muKiến trúc vật lý được đcùng một máy vật lý hoặc máy

Chương 1 : H

 Độ trễ thấp do hai lớp ứ

 Khả năng chống lỗi đơn giFoundationDB client và FoundationDB cluster mà giao tilỗi Nếu một máy cài lớ

layer và không ảnh hưkhác

 Dễ dàng cân bằng tải do FoundationDB client quFoundationDB client và FoundationDB cluster Cân bdùng cho một máy chủ

i cùng là FoundationDB cluster (KVS cluster) xử lý tất cả các tr

ng Nó nên được cấu hình một chế độ dự phòng phù h

i mong muốn

c đề nghị một bộ SQL layer và ứng dụng nên n

c máy ảo:

Chương 1 : Hình 8: Kiến trúc SQL layer được khuyến nghị

ứng dụng và SQL layer nằm trên cùng một máy

i đơn giản: do chỉ có giao tiếp giữa các máy là FoundationDB client và FoundationDB cluster mà giao tiếp này là ch

ớp ứng dụng bị lỗi hay hỏng hóc nó sẽ kéo theo c

nh hưởng đến các tiến trình ứng dụng đang chạy

i do FoundationDB client quản lý cân bằng tả

à FoundationDB cluster Cân bằng tải của yêu c ứng dụng cụ thể là không thay đổi

các trạng thái phòng phù hợp cho các

ng nên nằm trên

t máy

a các máy là

p này là chống chịu kéo theo cả SQL

y ở các máy

ải giữa tất cả

a yêu cầu người

 Chia sẻ bộ xử lý đa nhân hiệu quả do lớp ứng dụng thường là đa luồng và có thể chia sẻ các nhân của vi xử lý với SQL layer Điều này lại trái ngược với việc mỗi tiến trình FoundationDB server chỉ sử dụng một nhân của bộ xử lý

Mở rộng theo chiều ngang như thêm các node

Hiệu năng truy vấn

Phụ thuộc vào tổng số dữ liệu truy cập, tốt khi tất cả dữ liệu nằm trong bộ nhớ chính

Batch pipelining để thực thi các câu truy vấn song song

giao tác

Cấu hình được thông thường

Timeout giao tác Cấu hình được Tối đa 5 giây Những tính năng chính:

 Tính sẵn sàng cao (Highly avaiable)

 Khả năng mở rộng(Stateless scalability)

 Giao tác (Truly transactionnal)

 Lược đồ phân cấp (Hierarchical schema)

 SQL và JSON (SQL and JSON)

Trên môi trường linux sử dụng các câu lệnh sau để khởi động và dừng dịch vụ:

user@host$ sudo service foundationdb start

user@host$ sudo service foundationdb stop

1.3.2 Tập tin Cluster

FoundationDB server và client sử dụng tập tin cluster (thường đặt tên fdb.cluster) để kết nối đến một cluster Nội dung của tệp này là giống nhau cho các tiến trình cùng kết nối vào một cluster Tệp này được tạo ra ngay khi cài đặt FoundationDB server và cập nhật tự động khi chúng ta thay đổi máy chủ điều phối

Để có thể kết nối đến cluster từ máy trạm (client) cần phải sao chép tệp cluster từ máy chủ điều phối vào đúng thư mục của FoundationDB client trên máy trạm

 Linux: /etc/foundationdb/fdb.cluster1.3.3 Thêm node vào cluster

Các bước để thêm một máy vào cluster(FoundationDB chỉ hỗ trợ xây dựng cluster với phiên bản trên hệ điều hành họ linux)

 Cài đặt FoundationDB vào máy tính muốn thêm vào cluster

 Cấu hình để mỗi tiến trình FDB servers chạy trên một nhân của vi xử lý VD:

CPU có 4 nhân thì chúng ta nên cấu hình chạy 4 tiến trình FDB servers để tận dụng tối đa hiệu năng của máy(lưu ý là mỗi tiến trình cần 4GB bộ nhớ RAM)

Cấu hình có thể thay đổi trong file:foundationdb.conf.

 Sao chép tệp cluster từ một máy(node) trong cluster vào đúng đường dẫn trên máy mới cài đặt

 Khởi động lại dịch vụ FDB servers trên máy mới

user@host2$ sudo service foundationdb restart

Chương 1 : Hình 9: Cấu hình cluster cơ bản bao gồm hai nodes

1.3.4 Loại bỏ node từ cluster

 Lựa chọn chế độ dự phòng thích hợp với số node còn lại trong cluster

 Nếu máy cần loại bỏ đang là một trong nhưng máy điều phối cần thiết lập lại

để máy này không là máy chủ điều phối

 Sử dụng lệnhexclude trên máy muốn loại bỏ

user@host1$ fdbcli

Using cluster file `/etc/foundationdb/fdb.cluster'

The database is available

Welcome to the fdbcli For help, type `help'

fdb> exclude 1.2.3.4 1.2.3.5 1.2.3.6

Waiting for state to be removed from all excluded servers

This may take a while

It is now safe to remove these machines or processes from the cluster

 Dừng dịch vụ trên máy đã loại bỏ

user@host3$ sudo service foundationdb stop

user@host3$ sudo update-rc.d foundationdb disable

 Kiểm tra lại CSDL để chắc chắn tất cả đều hoạt động ổn định

 Có thể gỡ bỏ và xóa các file liên quan đến FDB server trên máy bị loại bỏ

1.3.5 Xem thông tin trạng thái cluster

Sử dụng câu lệnh status để xem trạng thái của cluster đang chạy:

user@host$ fdbcli

Using cluster file `/etc/foundationdb/fdb.cluster'

The database is available

Welcome to the fdbcli For help, type `help'

fdb> status

Chương 1 : Hình 10: trạng thái của cluster Redundancy mode Chế độ dự phòng đang sử dụng Storage engine Cấu hình hiện tại của phương thức lưu trữ Coordinators Số lượng máy chủ điều phối của cluster FoundationDB

processes Số lượng tiến trình FDB server chạy trên cluster Machines Sô lượng máy vật lý(node) của cluster

Overall load Ước tính lượng sử dụng tài nguyên phần cứng Memory availability RAM cho mỗi tiến trình FDB server

Replication health Ước lượng tình trạng của dữ liệu nhân bản Moving data Lượng dữ liệu chuyển qua lại các máy

Sum of key-value sizes

Ước tính dung lượng của KVS không bao gồm các bản sao

Operating space Ước tính lượng bộ nhớ ram còn trống của mỗi

máy

Read rate Số lượng đọc trên giâyWrite rate Số lượng ghi trên giây Transaction rate Số lượng giao tác trên giây Conflict rate Số lượng xung đột trên giây

1.3.6 Quản lý tập tin trace

 /var/log/foundationdb/ LinuxCác tập tin trace(truy vết) có mục đích để chẩn đoán các lỗi hay xung đột trên cluster

1.3.8 Nâng cấp

Để nâng cấp FDB cluster lên phiên bản mới thì cần phải nâng cấp phiên bản ở từng máy trong cluster Cluster sẽ không hoạt động cho đến khi toàn bộ các node được cập nhật thành công

1.4 Kết luận

Trong chương một, tôi đã giới thiệu tổng quan mô hình một hệ thống xử lý giao tác trực tuyến(OLTP system) Đây là hệ thống cơ sở dữ liệu phân tán, chạy trên Cluster Sau đó giới thiệu về FoundationDB một hệ quản trị CSDL thế hệ mới chú trọng và tập trung vào sức mạnh của giao tác FouandationDB có rất nhiều đặc tính phù hợp với một hệ thống OLTP hiện đại như hỗ trợ rất mạnh giao tác ACID, khả năng mở rộng quy mô và phòng chống lỗi rất tốt

Trong chương thứ hai, tôi tập trung vào vấn đề xây dựng ứng dụng với FoundationDB

CHƯƠNG 2: PHÁT TRIỂN ỨNG DỤNG XỬ LÝ GIAO TÁC TRỰC TUYẾN VỚI FOUNDATIONDB

2.1 Xây dựng ứng dụng với API của FoundationDB[4]

2.1.1 Mô hình dữ liệu

Mô hình dữ liệu lõi của FDB là key-value store có trật tự Cũng được biết đến như một mảng, từ điển có sắp xếp, đây là cấu trúc dữ liệu kết hợp bởi một tập các bộ khóa-giá trị (key-value) trong đó tất cả khóa là duy nhất và có thứ tự Tất cả khóa và giá trị trong FDB đều là các chuỗi byte Ngoài việc phục hồi và lưu trữ, CSDL không phụ thuộc vào nội dung của giá trị Sự kết hợp của mô hình dữ liệu lõi cùng với giao tác đa khóa cho phép ứng dụng có thể xây dựng các mô hình dữ liệu phong phú hơn đồng thời thừa hưởng những đặc tính của FDB

2.1.2 Quản lý không gian tên

Do sự sắp xếp của các khóa nên một không gian tên (namespace) trong FDB được định nghĩa bởi bất cứ tiền tố nào được thêm vào trước khóa

2.1.3 Làm việc với các hàm APIs

FDB hỗ trợ các hàm API (Application Programming Interface) cho các ngôn ngữ Python, Ruby, Node.js, Java và C Ở mức cao mỗi tập APIs đều hỗ trợ giao tác cho phép:

 Thiết đặt một bộ khóa-giá trị

 Lấy ra giá trị nhờ vào khóa

 Lấy ra một dải khóa-giá trị

 Xóa đi một bộ khóa-giá trị

 Xóa đi một dải khóa-giá trị

2.1.4 Cơ bản về giao tác trong FoundationDB

FDB cung cấp mô hình điều khiển sự đồng thời, tương tranh bằng giao tác cho phép nhiều người dùng cùng lúc đọc và ghi vào CSDL Tất cả các thao tác đọc ghi các

bộ khóa-giá trị đều được thực hiện trong phạm vi một giao tác Một giao tác là một đơn vị nhỏ của công việc được thực thi tin cậy và về mặt logic thì độc lập với các giao tác khác

Trong Python thì Giao tác của FDB được viết như sau:

@fdb.transactional defexample(tr):

# Read two values from the database

$ fdbsqlcli -c "SELECT VERSION()"

2.2.2 Khởi động và dừng dịch vụ trên môi trường windows

Sql layer cũng giống các dịch vụ khác trên hệ điều hành windows có thể khởi động, dừng, vô hiệu bằng trình quản lý dịch vụ:

Chương 2: HHoặc bằng các câu lệnh sau:

C:\Windows\system32> net start fdbsqllayer

The FoundationDB SQL Layer

The FoundationDB SQL Layer

C:\Windows\system32> net stop fdbsqllayer

The FoundationDB SQL Layer

Vô hiệu hóa khởi động cùng h

C:\Windows\system32>sc config fdbsqllayer start= demand

[SC] ChangeServiceConfig SUCCESS

Chương 2: Hình 1: dịch vụ SQL layer trên window

nh sau:

system32> net start fdbsqllayer

The FoundationDB SQL Layer service is starting…

The FoundationDB SQL Layer service was started successfully.

system32> net stop fdbsqllayer

The FoundationDB SQL Layer service was stopped successfully.

ng cùng hệ điều hành:

system32>sc config fdbsqllayer start= demand

[SC] ChangeServiceConfig SUCCESS

cessfully

service was stopped successfully

system32>sc config fdbsqllayer start= demand