Tải bản đầy đủ (.pdf) (13 trang)

Tối ưu hóa xử lý giao tác với H-Store

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (625.33 KB, 13 trang )

Tối ưu hóa xử lý giao tác với H-Store
Đào Trọng Lực
Trường Đại học Công nghệ
Luận văn Thạc sĩ ngành: Hệ thống thông tin; Mã số: 60 48 05
Người hướng dẫn: TS. Nguyễn Ngo ̣c Hóa
Năm bảo vệ: 2011
Abstract: Nghiên cứu, tìm hiểu được mơ hình H-Store trong việc tối ưu xử lý các giao
tác trên những hệ thống đa vi xử lý. Xây dựng mơ hình thực nghiệm ứng dụng HStore: bài toán quản lý khách hàng và kho số cho cơng ty Viễn Thơng Điện Lực nhằm
khắc phục tồn diện thực trạng của hệ thống phần mềm “Hệ thống tính cước và quản
lý khách hàng Viễn thơng” 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 với các chức năng quản
lý khách hàng và kho số; Thường xuyên bổ xung phần cứng và hiệu chỉnh mã nguồn
(Code); Không tận dụng được lợi thế phần cứng của ngành điện : Hàng trăm máy chủ
HP, SUN, IBM với đa bộ vi xử lý (CPU), nhiều RAM. 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.
Keywords: Hệ thống thông tin; Xử lý giao tác; Công nghệ thông tin
Content
1. Giới thiệu
Ngày nay, nhu cầu khai thác dữ liệu với băng thông lớn quy mô ngày càng mở rộng. Hệ
thống Cluster với multicore đang xâm nhập mạnh mẽ trong mọi ứng dụng và phần mềm tin
học của đời sống. Mục tiêu nhắm tới các ứng dụng OLTP ở các doanh nghiệp lớn với mơ
hình giao dịch trực tuyến băng thông cao, H-Store là một hướng đi mang đầy tính khả thi.
Một kiến trúc DBMS mới có tên là VoltDB, một cài đặt cụ thể của H-Store, đã tận dụng được
hết khả năng của các hệ thống đa xử lý trong việc tối ưu các giao tác. Tác giả cũng đã xây
dựng một ứng dụng thử nghiệm trong hệ thống chăm sóc khách hàng và kho số cho cơng ty
viễn thông Điện lực dựa trên công nghệ H-Store nhằm đánh giá được hiệu năng thực sự của
công nghệ mới này, đồng thời so sánh được hiệu năng của H-Store với các hệ thống DBMS
truyền thống như Oracle, MySQL trong việc xử lý khối lượng giao dịch lớn.
Mục tiêu chính: Nghiên cứu, tìm hiểu và ứng dụng mơ hình tối ưu hoá giao tác trên những
hệ thống đa vi xử lý (clusters, multi-cores)
Nội dung chính:








Nghiên cứu, tìm hiểu về mơ hình H-Store và hệ quản trị CSDL VoltDB
Xây dựng mơ hình hình thử nghiệm với bài toán thực tế: quản lý khách hàng &
kho số
Thực nghiệm và đánh giá kết quả

2. Mơ hình kiến trúc H-Store
H-Store là hệ thống cơ sở dữ liệu phân tán, chạy trên Cluster. Với kiến trúc gồm 2 phần :
Lược đồ triển khai và lược đồ thực thi (hình 2.1).

Hình 2.1 Kiến trúc hệ thống H-Store
Trong lược đồ triển khai, đầu vào bao gồm 4 thành phần : Thủ tục (Stored procedures),
lược đồ cơ sở dữ liệu (database schema), tải trọng mẫu (Sample Workload) và thông tin
Cluster (Cluster information). Trong đó
+ Stored procedures : Được thể hiện dưới dạng Java Class, lai giữa ngôn ngữ Java và
ngôn ngữ Sql, đây là một chuẩn của H-Store và người lập trình phải tuân theo. Nó có dạng
như sau:
import org.voltdb.*;
public class HowManySeats extends VoltProcedure {
public final SQLStmt GetSeatCount = new SQLStmt(
"SELECT * FROM Flight;");
public long run(){
VoltTable[] queryresults;
voltQueueSQL( GetSeatCount, flightid);
queryresults = voltExecuteSQL();

VoltTable result = queryresults[0];
}}
+ Database schema: Là một file đuôi .sql, chứa các câu lệnh định nghĩa cơ sở dữ liệu, các
tập lệnh tạo bảng, tạo index theo đúng chuẩn của Sql. Ví dụ như : CREATE TABLE ….


+ Cluster information : Là một file dạng XML. Chứa tồn bộ các thơng tin về Cluser : bao
nhiêu máy chủ, bao nhiêu CPU … của hệ thống phần cứng mà ứng dụng sẽ triển khai. Nó có
dạng như sau :
<?xml version="1.0"?>
<deployment>
<cluster hostcount="1" sitesperhost="2" />
</deployment>
Tham số hostcount : Số máy chủ, sitesperhost : Số Core CPU/một máy chủ
Với các đầu vào như vậy, đầu ra của lược đồ triển khai là một file có định dạng Jar. Bao
gồm 3 thành phần : Các java Class đã được biên dịch của các thủ tục, kiến trúc Cluster và các
Plan thực thi giao dịch.
Trong lược đồ thực thi, File Jar sẽ được phát tán lên các máy chủ và thực hiện chạy dưới
cơ chế của core H-Store. Trong mỗi máy chủ của Cluster sẽ có các thành phần như nhau và
như hình vẽ. Khi ứng dụng Client thực hiện một yêu cầu giao dịch sẽ dùng các hàm H-Store
API và thực hiện cuộc gọi đúng như các thủ tục đã được định nghĩa trước trong lược đồ triển
khai. Một yêu cầu từ Client có thể kết nối đến bất cứ máy chủ nào của Cluster. Với thành
phần Transaction Initiator, yêu cầu sẽ được gửi tới đúng máy chủ cần xử lý (đó là máy chủ
chứa dữ liệu mà Client cần) (mục 3 – Tối ưu hóa truy vấn đồng thời sẽ nói rõ cách thức tổ
chức này). Trong trường hợp xử lý yêu cầu trên đúng máy chủ thì mọi yêu cầu được xử lý bởi
trình quản lý giao dịch (Transaction Manager) nhằm đảo bảo đồng bộ và tuần tự dựa trên 3 cơ
chế điều khiển phân tranh : Phong tỏa, suy diễn và khóa (tham khảo thêm tài liệu để hiểu rõ
hơn về 3 cơ chế này).
3. Tối ưu hoá truy vấn đồng thời
H-Store được thiết kế với 3 tiêu chí :

+ Giao dịch được tổ chức dưới dạng thủ tục
+ Không cần ổ cứng
+ Phân mảnh dữ liệu
Với một máy chủ ngày nay có thể đạt được 128G RAM, một hệ thống Cluster với khoảng 40
máy chủ sẽ đạt được công suất khoảng 5TB RAM. Như vậy, một ứng dụng OLTP lớn nhất
hiện nay hoàn toàn 100% dữ liệu được chứa trong RAM (in-memory). Đây là điểm nổi bật
đầu tiên của nguyên tắc thiết kế H-Store. Với việc lưu giữ trong RAM, không cần phải lưu trữ
dữ liệu trên ổ cứng, tốc độ xử lý của giao dịch được thực hiện ngay trong các bộ nhớ chính,
điều này làm cho băng thông của ứng dụng OLTP tăng lên gấp hàng trăm, hàng nghìn lần.
Ngồi ra, kiến trúc H-Store cịn cho phép phân mảnh dữ liệu theo chiều ngang, nghĩa là các
bảng dữ liệu có thể được phân vùng dựa trên giá trị của 1 cột trong bảng. Dữ liệu sẽ được chia
đều cho các máy chủ, trong từng máy chủ lại được phân quyền cho từng Chip CPU xử lý. Với
ưu điểm này, dữ liệu được triển khai một cách phân tán và độc lập nhau, tận dụng được toàn
bộ các Core CPU trong việc xử lý dữ liệu. Theo thực nghiệm bản đánh giá của hiệp hội xử lý
giao dịch online (TPC) : VoltDB nhanh hơn 100 lần so với MySQL, hơn 13 so với Cassandra,


và hơn 45 lần so với Oracle, với khả năng mở rộng tuyến tính (đạt được 4 triệu giao dịch đồng
thời với 30 máy chủ)

Hình 3.2 Thử nghiệm hiệu năng VoltDB của TPC
4. Thực nghiệm
Nhằm minh chứng cho lý thuyết về công nghệ H-Store, Tác giả thực hiện một thực
nghiệm thực tế “Bài toán quản lý khách hàng và kho số cho Cơng ty Viễn Thơng Điện Lực”
bằng chính cơng nghệ này, với cài đặt cụ thể bằng VoltDB DBMS.
Đây là hệ thống quản lý khách hàng EVN tập trung online trên toàn quốc, triển khai cho
64 tỉnh thành, với số điểm giao dịch lên tới 3000 đại lý. Đây là hệ thống phức tạp và yêu cầu
băng thông lớn, một bài tốn rất thực tế cho thử nghiệm cơng nghệ H-Store.



Phần cứng sử dụng để thực nghiệm :
Chức năng

Cấu hình

Số lượng

VoltDB Database

CPU : Intel(R) Core(TM) 2 Duo CPU 02
E7400 @ 2.8 Ghz
Ram : 4G RAM
OS : Ubuntu 10.04.3 LTS

VoltDB Manager

CPU : Intel(R) Core(TM) 2 Duo CPU 01
E7400 @ 2.8 Ghz
Ram : 4G RAM
OS : Ubuntu 10.04.3 LTS

Client

CPU: Intel(R) Core(TM) 2 Duo CPU
P7450 @ 2.13 Ghz
Ram : 4G RAM
OS : Windows 2003 Servers

01


Tác giả đã hoàn thành ứng dụng thực nghiệm với các chức năng quan trọng bao gồm: Phát
triển thuê bao, cấp số, xác nhận cấp số, xác nhận hòa mạng, chọn gói cước, tra cứu doanh thu,
giữ số đẹp và đấu giá số đẹp hồn tồn bằng cơng nghệ H-Store. Sau đây là một số giao diện
chính của chương trình thực nghiệm :
Màn hình giao diện chính :


Chức năng phát triển khách hàng :

Chức năng chọn gói cước :


Chức năng cấp dải số :

Chức năng đấu giá số đẹp:


Ngồi ra tác giả cũng chú trọng vào việc mơ phỏng hệ thống gửi nhiều giao dịch cùng một
lúc, so sánh với các hệ quản trị như Oracle, MySQL:

Giao diện so sánh :


5. Đánh giá

Số
Trans

One
Node

Multi
Conn

KẾT QUẢ THỰC NGHIỆM
VOLTDB
ORACLE
Multi
Two
Pooling
Single
One Node
Conn
Node
Conn
Conn
Trans/Sec
Trans/S
Trans/Sec
Trans/Sec Trans/Sec
ec

MYSQL
Multi
Conn
Trans/Sec
156
Error :
“Too
many
connectio

ns”
190
Error :
“Too
many
connectio
ns”

Batch Execute
Trans/Sec

5.000

109

2.516

1.182

77

189

112

10.00
0

171


4.553

3.120

111

201

112

20.00
0

213
(82%
RAM)

11.396

7.132

114

206

112

x

8.791


x

12.730

12.445

129

208

114

x

10.227

x

13.365

15.231

x

x

x

x


9.963

14.782
(67 giây)

x

x

x

x

9.020

11.485
(261
giây)

x

x

x

x

9.092


100.0
00
200.0
00
1.000
.000

x

3.000
.000

x

10.666
(93 giây)
(80%
RAM)
7.139
(420 giây)
(90%
RAM)

4.537

6.071

Với kết quả thực nghiệm đạt được, tác giả có một số đánh giá như sau :
+ Khi so sánh nội bộ VoltDB giữa 1 máy chủ và 2 máy chủ : Hệ thống VoltDB 2 máy chủ
vượt trội khi xử lý 3.000.000 giao dịch đồng thời tốc độ đạt gần 11.000 giao dịch/giây (một

máy chỉ đạt 7.000 giao dịch/giây)
+ Với cùng lượng giao dịch 3.000.000 giao dịch đồng thời, hệ thống Oracle và MySQL
chỉ đạt được ở mức 9.000 giao dịch /giây và khơng có khả năng tăng nữa. Nhưng chỉ với 2


máy PC hiện nay, VoltDB đạt mức 11.000 giao dịch/giây và tăng tuyến tính nếu thêm máy
chủ và RAM.


6. Kết luận
Mơ hình H-Store thực sự khai thác được những kiến trúc đa nhân cũng như những hệ
thống cluster, và hồn tồn có thể nâng cao được hiệu năng xử lý các giao tác đồng thời từ
phía người dùng. Đây là một hướng đi đầy mới mẻ và mang đầy tính khả thi. Với sản phẩm
mang tính thương mại, một thể hiện, cài đặt cụ thể của H-Store với nền tảng Open Source
hoàn toàn hỗ trợ các nhà phát triển ứng dụng có thể thiết kế và triển khai các ứng dụng OLTP
của mình với cơng nghệ này vào trong thực tế.
Luận văn đã có các đóng góp chính:
 Nghiên cứu, tìm hiểu được mơ hình H-Store trong việc tối ưu xử lý các giao tác trên
những hệ thống đa vi xử lý
 Xây dựng mơ hình thực nghiệm với bài toán quản lý khách hàng và kho số với các
chức năng quá tải chính hiện nay nhằm đánh giá hiệu năng và hiệu ích của cơng nghệ
VoltDB.
 Thử nghiệm và đánh giá kết quả
Đề xuất hướng phát triển trong tương lai :
 VoltDB và bài toán khác OLTP
 VoltDB với khả năng tích hợp CSDL khác bằng Hadoop
 Hệ thống tính tốn đám mây, Neural với VoltDB
References
[1] Evan P. C. Jones MIT CSAIL Cambridge, MA, USA and Daniel J. Abadi Yale University
New Haven, CT, USA and Samuel Madden MIT CSAIL Cambridge, MA, USA (2010),

Low Overhead Concurrency Control for Partitioned Main Memory Databases
[2] Robert Kallman Brown University and Evan P. C. Jones Massachusetts Institute of
Technology and John Hugg Yale University (2008), HStore:A HighPerformance,
Distributed Main Memory Transaction Processing System
[3] The Transaction Processing Council. TPC-C Benchmark (Revision 5.9.0).
June 2007.
[4] M.Tamer Ozsu, Patrick Valduriez. Principles of Distributed Database System, Prentice
Hall, 1999.
[5] Elmarsi Navathe, Fundamentals of Database System, Addison-Wesley, 2000.
[6] Hector Garcia-Molina et al, Database Systems: The Complete Book, Prentice Hall, 2002.
[7] M. T. Oszu and P. Valduriez, Principles of Distributed Database Systems (2nd ed.),
Prentice Hall, 1999.
[8] Michael Blaha, William Premerlani. Object Oriented Modelling and Design for Database
Applications, Prentice Hall, 1998.
[9] Azza Abouzeid, Kamil Bajda-Pawlikowski, Daniel J. Abadi, Alexander Rasin, Avi
Silberschatz, HadoopDB: An Architectural Hybrid of MapReduce and DBMS
Technologies for Analytical Workloads. VLDB 2009.
[10] , 2011
[11] 2010
[12] 2010


[13]
[14]
[15]
[16]

, 2010
, 2010
2008

, 2011




×