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

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ =======   ====== ĐÀO TRỌNG LỰC TỐI ƯU HÓA XỬ LÝ GIAO TÁC VỚI H-STORE LUẬN VĂN THẠC SĨ Hà Nội - 2011 ĐẠI HỌC QUỐC GIA HÀ NỘI KHOA LUẬT NGUYỄN VĂN LÂM PHÁP NHÂN TRONG HỆ THỐNG CÁC CHỦ THỂ CỦA QUAN HỆ PHÁP LUẬT Chuyên ngành: Lý luận và lịch sử nhà nước và pháp luật Mã số : 60 38 01 LUẬN VĂN THẠC SĨ LUẬT HỌC Người hướng dẫn khoa học: GS. TS. Hoàng Thị Kim Quế HÀ NỘI - 2011 3 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 KÝ HIỆU, CÁC TỪ VIẾT TẮT ............................................... 6 DANH MỤC CÁC BẢNG BIỂU ............................................................................... 7 DANH MỤC CÁC HÌNH VẼ .................................................................................... 8 MỞ ĐẦU .................................................................................................................... 9 CHƢƠNG 1 : TỔNG QUAN MÔ HÌNH XỬ LÝ GIAO TÁC H-STORE ............ 11 1.1 Giới thiệu ............................................................................................................ 11 1.2 Tổng quan của hệ thống H-Store ...................................................................... 11 1.2.1 Lược đồ triển khai (System deployment) ....................................................... 12 1.2.2 Lược đồ thực thi (Runtime Model) ................................................................ 12 1.2.3 Lớp giao dịch (Transaction Classes) .............................................................. 13 1.2.4 Tổ chức dữ liệu vật lý.................................................................................... 13 1.3 Nguyên tắc thiết kế hệ thống H-Store ............................................................... 14 1.3.1 Giao dịch tổ chức dưới các thủ tục lưu trữ ( stored Procedures) ..................... 14 1.3.2 Không cần ổ cứng (No disk) .......................................................................... 14 1.3.3 Phân vùng dữ liệu (Partitioning) .................................................................... 14 1.4 Cách thức thực thi giao dịch (Executing Transactions) ................................... 15 1.4.1 Các thành phần hệ thống (System components) ............................................. 15 1.4.2 Giao dịch một phân vùng (Single Partition Transactions) .............................. 15 1.4.3 Giao dịch nhiều phân vùng (Multi Partition Transactions) ............................. 16 1.5 Cơ chế điều khiển phân tranh ........................................................................... 16 1.5.1 Phong tỏa (Blocking) .................................................................................... 16 1.5.2 Thực thi suy diễn(Speculative Execution) ..................................................... 17 1.5.3 Khóa (Locking) ............................................................................................. 19 1.6. Kết luận ............................................................................................................. 20 CHƢƠNG 2 : PHÁT TRIỂN ỨNG DỤNG XỬ LÝ GIAO TÁC TRỰC TUYẾN VỚI VOLTDB .......................................................................................................... 21 2.1 Tổng quan .......................................................................................................... 21 2.1.1 Giới thiệu VoltDB ......................................................................................... 21 2.1.2 Ứng dụng VoltDB ......................................................................................... 21 2.1.3 Hoạt động của VoltDB .................................................................................. 22 4 2.2 Cách cài đặt VoltDB .......................................................................................... 24 2.2.1 Yêu cầu hệ điều hành và phần mềm .............................................................. 24 2.2.2 Cài đặt VoltDB ............................................................................................. 25 2.2.3 Các thành phần trong bộ phân phối VoltDB .................................................. 25 2.3 Cách thiết kế ứng dụng Voltdb ......................................................................... 26 2.3.1. Thiết kế Cơ sở dữ liệu .................................................................................. 26 2.3.2. Thiết kế thủ tục truy nhập dữ liệu (Stored Procedures) ................................. 29 2.3.3. Thiết kế ứng dụng logic ................................................................................ 33 2.4. Xây dựng ứng dụng VoltDB ............................................................................. 37 2.4.1. Dịch ứng dụng Client và thủ tục Server ........................................................ 37 2.4.2. Tạo file định nghĩa dự án (Project Definition File) ....................................... 37 2.4.3. Xây dựng hồ sơ thời gian chạy (Runtime Catalog) ....................................... 38 2.5. Chạy ứng dụng VoltDB..................................................................................... 38 2.5.1. Định nghĩa file cấu hình Cluster ................................................................... 38 2.5.2. Khởi động VoltDB Database ........................................................................ 39 2.5.3. Tắt VoltDB Database ................................................................................... 40 2.5.4. Các mô hình hoạt động ................................................................................. 40 2.6. An Ninh ............................................................................................................. 41 2.6.1. Mô hình an ninh trong VoltDB ..................................................................... 41 2.6.2. Kích hoạt chế độ xác thực và phân quyền ..................................................... 42 2.6.3. Định nghĩa người dùng và nhóm người dùng................................................ 42 2.6.4. Phân quyền truy cập thủ tục ......................................................................... 43 2.6.5. Cho phép truy cập thủ tục hệ thống và Ad Hoc Queries................................ 43 2.7. Mô hình sẵn sàng .............................................................................................. 43 2.7.1. Mô hình K-Safety......................................................................................... 43 2.7.2. Kích hoạt K-Safety ....................................................................................... 44 2.7.3. Khôi phục hệ thống khi bị lỗi ....................................................................... 46 2.7.4. Tránh phân vùng mạng (Network Partitions) ................................................ 46 2.8. Quản trị CSDL .................................................................................................. 48 2.8.1. VoltDB Enterprise Manager ......................................................................... 49 2.8.2. Quản trị các Databases ................................................................................. 50 2.8.3 Cài đặt và khởi động VoltDB Enterprise Manager ......................................... 50 2.8.4. Khám phá Enterprise Manager ..................................................................... 51 2.8.5. Thêm Database............................................................................................. 53 5 2.8.6. Khởi động và tắt Cơ sở dữ liệu ..................................................................... 57 2.8.7. Theo dõi Cluster ........................................................................................... 58 2.8.8. Nâng cấp Cơ sở dữ liệu ................................................................................ 60 2.8.9. Bảo dưỡng và sữa chữa Cluster .................................................................... 61 2.9. Kết luận ............................................................................................................. 64 CHƢƠNG 3 : HỆ THỐNG QUẢN LÝ KHÁCH HÀNG VÀ KHO SỐ CỦA CÔNG TY VIỄN THÔNG NGÀNH ĐIỆN ............................................................ 65 3.1 Bài toán đặt ra .................................................................................................... 65 3.2 Thiết kế, cài đặt hệ thống thử nghiệm ............................................................... 69 3.2.1 Thiết kế cơ sở dữ liệu .................................................................................... 69 3.2.2 Thiết kế giao diện .......................................................................................... 72 3.2.3 Thiết kế kiến trúc phần cứng – Cluster .......................................................... 78 3.2.4 Cài đặt chương trình ...................................................................................... 79 3.3 Quản trị hệ thống ............................................................................................... 79 3.3.1 Mục đích ....................................................................................................... 79 3.3.2 Thiết kế giao diện .......................................................................................... 79 3.3.3 Cài đặt chương trình ...................................................................................... 82 3.4 Đánh giá, so sánh với hệ quản trị Oracle và MySQL ....................................... 82 KẾT LUẬN .............................................................................................................. 86 TÀI LIỆU THAM KHẢO ....................................................................................... 87 6 DANH MỤC CÁC KÝ HIỆU, CÁC TỪ VIẾT TẮT OLTP Online Transaction Processing PDF Project Definition File ACID Atomicity, Consistency, Isolation, và Durability ETL Extract, Transform, and Load . TPS Transactions Processed per Second RSS Resident Set Size JMX Java Management Extensions CBS Customer Care and Billing System 7 DANH MỤC CÁC BẢNG BIỂU Bảng 2.1 Yêu cầu hệ điều hành và phần mềm VoltDB ............................................... 24 Bảng 2.2 Các thành phần trong bộ phân phối VoltDB ................................................ 26 Bảng 2.3 Tải trọng mẫu ............................................................................................. 27 Bảng 2.4 Các phương thức của lớp VoltTable ............................................................ 33 Bảng 2.5 Nhóm công việc quản trị ............................................................................. 50 Bảng 2.6 Yêu cầu hệ điều hành và phần mềm VoltDB Enterprise Manager ............... 50 Bảng 2.7 Biểu tượng thể hiện trạng thái của cơ sở dữ liệu.......................................... 53 Bảng 2.8 Cấu hình cơ sở dữ liệu ................................................................................ 55 Bảng 2.9 Cấu hình cơ sở dữ liệu nâng cao ................................................................. 56 Bảng 3.1 Tần suất dữ liệu .......................................................................................... 71 Bảng 3.2 Tải trọng dữ liệu ......................................................................................... 71 Bảng 3.3 Bảng dữ liệu thực nghiệm ........................................................................... 72 Bảng 3.4 Bảng phần cứng thực nghiệm ...................................................................... 78 Bảng 3.5 Bảng kết quả thực nghiệm so sánh VoltDB với CSDL truyền thống ........... 85 8 DANH MỤC CÁC HÌNH VẼ Hình 1.1 Kiến trúc hệ thống H-Store .......................................................................... 12 Hình 1.2 Thành phần hệ thống ................................................................................... 15 Hình 1.3 Mã giả cơ chế điều khiển phân tranh ―Phong tỏa‖ ....................................... 17 Hình 1.4 Mã giả cơ chế điều khiển phân tranh ―Thực thi suy diễn‖ ............................ 19 Hình 2.1 Phân vùng bảng dữ liệu ............................................................................... 22 Hình 2.2 Tiến trình tuần tự hóa .................................................................................. 23 Hình 2.3 Nhân bản bảng dữ liệu................................................................................. 23 Hình 2.4 Lược đồ được định nghĩa theo SQL chuẩn. ................................................ 26 Hình 2.5 Hoạt động với thông số K-Safety ................................................................ 44 Hình 2.6 Phân mảnh mạng ......................................................................................... 47 Hình 2.7 Hoạt động bảo vệ lỗi mạng .......................................................................... 48 Hình 2.8 Mô hình Cluster với cơ sở dữ liệu VoltDB. ................................................. 49 Hình 2.9 Mô hình Enterprise Manager. ...................................................................... 49 Hình 2.10 Các thành phần giao diện........................................................................... 51 Hình 2.11 Màn hình Dashboard của Enterprise Manager. .......................................... 52 Hình 2.12 Danh sách cơ sở dữ liệu............................................................................. 52 Hình 2.13 Cấu hình Cơ sở dữ liệu. ............................................................................. 54 Hình 2.14 Thêm máy chủ tới danh sách máy chủ. ...................................................... 56 Hình 2.15 Tham số thêm máy chủ mới. ..................................................................... 56 Hình 2.16 Khởi động cơ sở dữ liệu. ........................................................................... 57 Hình 2.17 Các chế độ khởi động cơ sở dữ liệu. .......................................................... 57 Hình 2.18 Biểu đồ theo dõi hoạt động ........................................................................ 59 Hình 2.19 Tải hồ sơ mới ............................................................................................ 60 Hình 2.20 So sánh giữa các Catalog ........................................................................... 61 Hình 2.21 Phát hiện và ước lượng lỗi ......................................................................... 62 Hình 2.22 Thu thập Snapshots ................................................................................... 63 Hình 3.1 Các khối chức năng chính của hệ thống CBS .............................................. 65 Hình 3.2 Mô hình hoạt động của hệ thống CBS ......................................................... 66 Hình 3.3 Phạm vi triển khai của hệ thống CBS .......................................................... 67 Hình 3.4 Mô hình chức năng chính mô phỏng VoltDB .............................................. 69 Hình 3.5 Sơ đồ quan hệ dữ liệu .................................................................................. 70 9 MỞ ĐẦU Giới thiệu ản trị (CSDL) , cho phép xử lý được những bài toán có quy mô lớn cả về dữ liệu lẫn số lượng người dùng đồng thời. Tuy nhiên, việc khai thác triệt để những mô hình đa vi xử lý trong các hệ thống Cluster của những hệ quản trị đó còn chưa được chú trọng một cách xứng đáng: các hệ quản trị này được xây dựng thuần từ những mô hình dữ liệu dựa trên một bộ vi xử lý. Từ đó, bài toán đượ ử lý truy vấ . H-Store là một trong những cách tiếp cận xây dựng mô hình CSDL song song dựa trên việc tận dụng hiệu năng tính toán đã được cải thiện theo những mô hình Cluster, multi-cores. Việc nghiên cứu, tìm hiểu về mô hình này sẽ cho phép cải thiện, nâng cao hiệu năng quá trình xử lý các truy vấn cũng như lưu trữ dữ liệu trên các DBMS với số lượng dữ liệu và người dùng đồ sộ. Một trong các thể hiện tiêu biểu nhất của mô hình H-Store là hệ quản trị VoltDB. Với một kiến trúc cơ sở dữ liệu hoàn toàn mới mẻ, dữ liệu được chứa đựng hoàn toàn trong bộ nhớ, triển khai trên các hệ thống máy chủ Cluster, tận dụng tối đa các máy tính chủ nhiều CPU vào quá trình xử lý song song và góp phần cải thiện lớn trong băng thông và hiệu năng của các ứng dụng đặc thù mà nhiều người biết đến đó là hệ thố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 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 H-Store, cụ thể 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. 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 ―Hệ thống tính cước và quản lý khách hàng Viễn thông‖ như : 10  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. 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 mô hình xử lý giao tác H-Store - Kiến trúc hệ thống H-Store, các khái niệm và mô hình lược đồ triển khai, lược đồ thực thi. - Nguyên tắc thiết kế hệ thống H-Store - Cách thức thực thi giao dịch và Cơ chế điều khiển phân tranh. Chương 2. Phát triển ứng dụng xử lý giao tác trực tuyến với VoltDB - Giới thiệu VoltDB - Cách xây dựng ứng dụng và triển khai ứng dụng VoltDB - Các mô hình bảo mật, sẵn sàng, backup và khôi phục dữ liệu - Quản trị ứng dụng trong VoltDB Chương 3. Thực nghiệm - Bài toán đặt ra: quản lý hệ thống khách hàng và kho số của Công ty viễn thông điện lực - Thiết kế và cài đặt hệ thống - Kết quả thu đươc (các chức năng chính của hệ thống) - Đánh giá, so sánh với một số hệ quản trị CSDL 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. 11 CHƢƠNG 1 : TỔNG QUAN MÔ HÌNH XỬ LÝ GIAO TÁC HSTORE 1.1 Giới thiệu Nhiều hệ thống sử dụng thành phần kiến trúc từ hệ thống cơ sở dữ liệu quan hệ truyền thống, mà không quan tâm liệu ứng dụng có thực sự cần các kỹ thuật chậm chạp đó không. Với khối lượng làm việc (workloads) cho các hệ thống xử lý giao dịch trực tuyến (OLTP) có tính chất lặp đi lặp lại, liên tục và thực thi giao dịch sống với thời gian ngắn, điều này đã bị cản trợ bởi hiệu năng của thiết bị vào ra I/O trên nền tảng hệ thống quản trị cơ sở dữ liệu quan hệ (RDBMS) [4, 5, 6]. Một chiến lược để giảm thiểu vấn đề này là mở rộng hệ thống theo chiều ngang bằng cách phân vùng cho cả dữ liệu và trách nhiệm xử lý dọc theo nhiều máy chủ không chia sẻ. Ứng dụng OLTP lớn nhất có thể đưa toàn bộ dữ liệu của nó vào bộ nhớ chính trong kiến trúc phần cứng máy chủ Cluster hiện đại với mô hình không chia sẻ. Do đó lưu trữ ổ cứng và cấu trúc chỉ số hóa (indexing) là không cần thiết. Nghiên cứu của tôi tập trung vào H-Store, một hệ thống OLTP thế hệ mới. Hệ thống này vận hành trên môi trường Cluster phân tán và không chia sẻ, với đặc tính toàn bộ dữ liệu được chứa trong bộ nhớ chính.Mô hình hệ thống dựa trên sự phối hợp của nhiều luồng đơn nhằm cung cấp thực thi giao dịch OLTP hiệu quả hơn [2]. H-Store là hệ thống có một luồng cho mỗi vùng dữ liệu riêng. Trong hệ thống này, duy nhất một luồng có thể truy cập dữ liệu và điều khiển tương tranh theo kiểu truyền thống là không cần thiết. Phân vùng dữ liệu cũng được sử dụng cùng với hệ thống không chia sẻ (Shared-nothing systems). Dữ liệu được chia dọc theo nhiều máy chủ cơ sở dữ liệu và các giao dịch được định tuyến tới các phân vùng (patitions) có dữ liệu cần thiết. Cách tiếp cận này cải thiện hiệu năng cơ sở dữ liệu một cách đáng kể. Một vài ứng dụng có khả năng phân vùng hoàn hảo (mọi giao dịch có thể được thực thi trong toàn bộ một phân vùng), trong trường hợp đó, nếu dữ liệu được lưu trong bộ nhớ chính, mỗi giao dịch có thể chạy mà không cần điều khiển tương tranh, chạy cho đến khi hoàn thành ở phân vùng phù hợp. Tuy nhiên, nhiều ứng dụng có một vài giao dịch trải rộng nhiều phân vùng. Với những giao dịch đó, một vài mô hình điều khiển tương tranh là cần thiết [1]. 1.2 Tổng quan của hệ thống H-Store Hệ thống H-Store là cơ sở dữ liệu quan hệ với cơ chế lưu trữ dựa trên dữ liệu hàng (row) và có tính phân tán cao [7]. Hệ cơ sở dữ liệu này được chạy trên môi trường Cluster với các máy (nodes) thực thi trong bộ nhớ chính và không chia sẻ. Chúng ta định nghĩa ―một thể hiện H-Store đơn là một Cluster với 2 hoặc nhiều Nodes‖. Node là hệ thống máy tính vật lý đơn. Node có thể chứa một hoặc nhiều 12 sites. Site là một thực thể hoạt động độc lập trong hệ thống, nó được coi như là một tiến trình đơn mà hệ thống ứng dụng OLTP từ ngoài kết nối đến để thực thi giao dịch. Chúng ta giả sử rằng, một Node của hệ thống H-Store tiêu biểu có nhiều bộ vi xử lý và mỗi Site được gắn thực thi chính xác trên một vi xử lý đó. Mỗi Site độc lập với Site khác và do đó không chia sẻ bất cứ kiến trúc dữ liệu hoặc bộ nhớ với Site đồng nghiệp nào trên cùng một máy. Mọi quan hệ trong cơ sở dữ liệu được phân chia vào một hoặc nhiều phân vùng (Partitions). Một phân vùng được nhân bản và chứa trên nhiều Site. Ứng dụng OLTP thực hiện các cuộc gọi tới hệ thống H-Store để thực thi các thủ tục lưu trữ đã được định nghĩa trước (stored procedures). Mỗi thủ tục được xác định bởi một tên duy nhất và chứa mã điều khiển có cấu trúc pha trộn với tập lệnh SQL được tham số hóa. Một thể hiện của thủ tục được khởi tạo bởi ứng dụng OLTP được gọi là một giao dịch (Transaction). Sử dụng những định nghĩa như trên, chúng ta miêu tả lược đồ triển khai (deployment schemes) và lược đồ thực thi (execution schemes) của hệ thống H-Store như trong hình 1.1 [2] Hình 1.1 Kiến trúc hệ thống H-Store 1.2.1 Lược đồ triển khai (System deployment) Lược đồ triển khai có đầu vào là một tập các thủ tục (Stored procedures), lược đồ cơ sở dữ liệu (database schema), tải trọng mẫu (Sample Workload)[9] và thông tin các sites sẵn sàng trong Cluster (Cluster information). Kiến trúc đầu ra là một danh sách các điều khiển triệu gọi duy nhất, được sử dụng như thể hiện của thủ tục ở thời gian chạy. Có thể đưa các thủ tục mới vào trong hệ thống sau khi triển khai. Lược đồ triển khai tạo ra một tập các thủ tục đã biên dịch và lớp cơ sở dữ liệu vật lý được sử dụng để khởi tạo H-store Cluster mới. [2] 1.2.2 Lược đồ thực thi (Runtime Model) Ở thời gian chạy, ứng dụng client OLTP yêu cầu một giao dịch bằng cách sử dụng trình điều khiển thủ tục được tạo ra trong lược đồ triển khai. Nếu giao dịch yêu 13 cầu giá trị tham số như là đầu vào thì Client phải truyền những giá trị này tới hệ thống cùng với yêu cầu. Một phân vùng bất kỳ trong H-Store cluster đều có thể thực thi bất cứ yêu cầu OLTP nào mà không cần quan tâm liệu dữ liệu cần thiết có được lưu trữ trên phân vùng này hay không. Trừ khi tất cả các giá trị tham số của truy vấn trong giao dịch đã được biết ở thời gian chạy, chúng ta sử dụng chiến lược giải thuật lười (lazy-planning strategy) để tạo giải thuật thực thi phân tán tối ưu. Nếu tất cả các giá trị tham số được biết ngay từ đầu, thì chúng ta thực thi thêm các tối ưu hóa dựa vào các thuộc tính của giao dịch. Khi một giao dịch thực thi câu lệnh SQL, nó tạo ra một yêu cầu nội tại thông qua H-Store API. Ở khâu này, tất cả các giá trị tham số cho truy vấn đã được biết trong hệ thống và do đó giải thuật được định hướng tới các phân vùng chính xác cho mỗi thao tác con truy vấn. Kế hoạch cập nhật được truyền tới bộ quản lý giao dịch và nó có trách nhiệm phối hợp truy cập với các phân vùng khác. Bộ quản lý truyền những phân mảnh của giải thuật tới các phân vùng phù hợp thông qua Socket và kết quả trung gian sẽ được truyền ngược lại tới phân vùng khởi tạo. H-Store sử dụng kiến trúc giao dịch phân tán để đảm bảo tính tuần tự. Kết quả cuối cùng của truy vấn được truyền ngược lại cho tiến trình giao dịch đang chờ và tiến trình này sẽ hủy bỏ giao dịch, thực thi thêm nhiều truy vấn hoặc commit giao dịch và trả lại kết quả cho ứng dụng client. [2] 1.2.3 Lớp giao dịch (Transaction Classes) Giao dịch đơn điểm (Single-sited Transactions): một giao dịch được gọi là đơn điểm nếu tất cả các truy vấn chứa trong nó được thực thi tính toán trên một phân vùng của cluster. Mặc dù giao dịch gửi tới hai hoặc nhiều phân vùng để thực thi (do dữ liệu nhân bản), nhưng nó không yêu cầu kết quả trung gian từ bất cứ điểm nào. Lớp giao dịch này là lớp mong muốn nhất và nó không cần sử dụng thông tin undo logs, cơ chế điều khiển phân tranh hoặc truyền thông với các phân vùng khác. Khi HStore nhận một yêu cầu giao dịch đơn điểm, phân vùng nhận yêu cầu sẽ truyền điều khiển thực thi cùng với giải thuật đã biên dịch tới phân vùng phù hợp. Phân vùng này bắt đầu xử lý giao dịch và thực thi truy vấn. Giao dịch một lần (One-shot Transactions): một giao dịch được gọi là một lần nếu nó không thể thực thi ở đơn điểm, nhưng mỗi truy vấn con riêng biệt của nó được thực thi chỉ ở đơn điểm. Không giống như giao dịch đơn điểm, chúng ta giả sử đầu ra của các truy vấn không dùng làm đầu vào cho các truy vấn con trong cùng giao dịch. H-store thực hiện công nghệ tối ưu đơn giản nếu giao dịch được khai báo là one-shot: Yêu cầu được chuyển đến phân vùng phù hợp nhất và ở đó giao dịch được đối sử theo cách thực hiện của giao dịch đơn điểm. [1, 4, 6] 1.2.4 Tổ chức dữ liệu vật lý Có hai mục tiêu xung đột nhau trong bất kỳ thiết kế cơ sở dữ liệu H-Store nào : Khả năng thực thi giao dịch càng nhanh càng tốt và cần thiết để duy trì sự sẵn sàng 14 của hệ thống. Để đạt được điều đó, một giao dịch được thực thi càng ở ít phân vùng càng tốt. Và do đó tối thiểu hóa bản tin truyền giữa các phân vùng trong bộ quản lý giao dịch. Các chiến lược hiển nhiên bao gồm tần suất nhân bản hoặc các bảng chỉ đọc (read-only) trên tất cả các phân vùng và sự sắp đặt các bảng được kết nối với nhau trên cùng phân vùng. Nhiều thiết kế phức tạp có thể phân vùng theo chiều ngang và các vùng dữ liệu liên quan được sắp đặt cùng với nhau. Vấn đề chọn lược đồ phân lớp nào để các chính sách, thủ tục tối ưu được thực hiện tốt nhất. H-Store lưu dữ liệu trên RAM, nên hệ số K-safety được thiết kế cho khả năng sẵn sàng lỗi. Nếu K quá nhỏ thì khi chỉ cần một số lượng nhỏ các node bị lỗi sẽ dẫn tới toàn bộ hệ thống không thể hoạt động. Còn nếu K quá cao thì các nodes không đủ bộ nhớ để lưu giữ các bản copy của dữ liệu và làm giảm băng thông của toàn hệ thống. [1, 5, 6] 1.3 Nguyên tắc thiết kế hệ thống H-Store 1.3.1 Giao dịch tổ chức dưới các thủ tục lưu trữ ( stored Procedures) H-Store duy nhất hỗ trợ các giao dịch thực thi dưới dạng các thủ tục đã được khai báo và biên dịch trước. Mỗi thủ tục được gọi bởi giao dịch hoặc phải hủy bỏ hoặc commit trước khi trả lại kết quả tới client [2, 4, 5, 6]. 1.3.2 Không cần ổ cứng (No disk) Ngày nay, một low-end 1U server có thể lên tới 128 GB RAM, nằm trong tủ rack của trung tâm dữ liệu khoảng 40 Servers thì công suất RAM có thể lên tới 5 TB. Do đó, với khối lượng phần cứng hiện đại nhất có thể giữ được tất cả cơ sở dữ liệu OLTP lớn nhất trong bộ nhớ, giảm sự cần thiết truy nhập ổ cứng trong suốt thao tác cơ bản, và điều này làm giảm nhu cầu xử lý tương tranh. Các cơ sở dữ liệu truyền thống dựa trên đĩa cung cấp tính bền vững, Tuy nhiên nhiệm vụ thiết yếu của ứng dụng OLTP là cần sự sẵn sàng cao và thường dùng các hệ thống nhân bản dữ liệu. HStore giữ nguyên các thế mạnh của việc nhân bản cho sự bền vững, cũng như tính sẵn sàng cao. Một giao dịch được commit khi nó đã nhận bởi k>1 bản sao, trong đó k là tham số điều chỉnh [2, 4, 5, 6]. 1.3.3 Phân vùng dữ liệu (Partitioning) H-Store đơn giản thực hiện các giao dịch từ đầu cho đến khi hoàn thành trong một luồng đơn. Để khai thác thế mạnh của nhiều máy chủ vật lý và nhiều CPUs thì dữ liệu phải được chia thành các phân vùng riêng rẽ. Mỗi phân vùng thực thi giao dịch một cách độc lập. Thử thách là việc chia dữ liệu của ứng dụng như thế nào để mỗi giao dịch chỉ truy cập một phân vùng. Với nhiều ứng dụng OLTP, phân vùng ứng dụng bằng tay là đơn giản. Ví dụ, ứng dụng TPC-C OLTP có thể phân vùng đến mức trung bình 89% giao dịch có thể truy cập duy nhất 1 phân vùng. Đó là một bằng chứng để các nhà phát triển sẵn sàng mở rộng ứng dụng của h-store và các nghiên 15 cứu khoa học cung cấp một vài cách tiếp cận cho việc lựa chọn nhân tố phân vùng tự động tốt nhất [2, 3, 4, 6]. 1.4 Cách thức thực thi giao dịch (Executing Transactions) 1.4.1 Các thành phần hệ thống (System components) Hình 1.2 Thành phần hệ thống Hệ thống bao gồm 3 kiểu tiến trình (Hình 1.2). Đầu tiên, dữ liệu được lưu trữ trong các phân vùng, một tiến trình đơn lưu trữ một phần dữ liệu trong bộ nhớ và thực thi thủ tục sử dụng luồng đơn. Với mỗi phân vùng, có một tiến trình chính và k1 tiến trình dự phòng (backup). Thứ hai, một tiến trình được gọi là bộ điều phối trung tâm được sử dụng điều kiển các giao dịch phân tán. Nó đảm bảo các giao dịch được thực thi tuần. Cuối cùng, tiến trình client là ứng dụng đầu cuối người sử dụng. Khi thư viện client kết nối đến cơ sở dữ liệu, nó sẽ tải một phần hồ sơ hệ thống (chứa thông tin thủ tục, địa chỉ mạng cho các phân vùng, cách dữ liệu được phân bổ). Điều này cho phép thư viện client có thể trực tiếp giao dịch với tiến trình phù hợp. Giao dịch được viết dưới dạng các thủ tục [2]. 1.4.2 Giao dịch một phân vùng (Single Partition Transactions) Khi client xác định yêu cầu là giao dịch đơn vùng, nó sẽ chuyển tới phân vùng chính có liên quan đến dữ liệu. Phân vùng chính sử dụng giao thức nhân bản để đảm bảo tính bền vững. Trong khi chờ phản hồi, phân vùng chính thực thi giao dịch. Khi là giao dịch đơn vùng thì giao dịch này sẽ không phong tỏa. Khi nhận được tất cả các phản hồi từ các vùng , kết quả của giao dịch sẽ được gửi trả lại cho client. Giao thức đảm bảo giao dịch ổn định là ít nhất một phân vùng sao lưu sống xót. Không có điều khiển tương tranh nào cần thiết cho giao dịch đơn vùng. Trong hầu hết trường hợp, 16 hệ thống thực hiện các giao dịch này mà không lưu thông tin undo, làm hạn chế quá tải. Điều này là có thể bởi vì giao dịch được chú thích xác định nếu người dùng hủy bỏ. 1.4.3 Giao dịch nhiều phân vùng (Multi Partition Transactions) Nhìn chung, các giao dịch đa vùng có các dữ liệu tùy ý phục thuộc giữa các phân mảnh giao dịch. Ví dụ một giao dịch có thể cần đọc giá trị ở vùng P1 và sau đó cập nhật giá trị ở vùng P2. Để đảm bảo giao dịch đa vùng được thực thi lần lượt có thứ tự mà không xảy ra deadlocks, chúng ta phải chuyển chúng tới bộ điều phối trung tâm và gán cho nó một thứ tự toàn cục. Mặc dù cách tiếp cận này khá dễ dàng, bộ điều phối trung tâm hạn chế tốc độ của giao dịch đa vùng. Để điểu khiển nhiều giao dịch đa vùng hơn, nhiều bộ điều phối phải được sử dụng. Bộ điều phối trung tâm chia giao dịch thành các phân mảnh (fragments) và gửi chúng tới các vùng phù hợp. Khi nhận được phản hồi, bộ điều phối thực thi mã ứng dụng để xác định cách tiếp tục giao dịch, có thể yêu cầu gửi nhiều phân mảnh hơn. Mỗi phân vùng thực thi các phân mảnh do giao dịch đưa tới một cách tuần tự. Giao dịch đa vùng được thực thi sử dụng bộ đệm undo và two-phase commit (2PC) để xác định kết quả. Không có thông tin undo, hệ thống sẽ cần phong tỏa cho đến khi lỗi được sửa. Bộ điều phối ghi thông tin 2PC ―prepare‖ với phân mảnh cuối cùng của giao dịch. Khi tiến trình chính nhận được phân mảnh cuối cùng, nó gửi tất cả phân mảng của giao dịch tới các máy chủ dự phòng và đợi thông tin phản hồi trước khi gửi kết quả cuối cùng tới bộ điều phối. Khi bộ điều phối có tất cả các phản hồi, nó hoàn thành giao dịch và gửi bản tin ―commit‖ tới các phân vùng và trả lại kết quả cuối cùng cho ứng dụng. Khi thực thi giao dịch đa vùng, mạng cần được cài đặt và thời gian rỗi (idle time) có thể gây hiệu năng cổ chai. Với hệ thống mạng gigabit Ethernet, ping giữa 2 máy tính sấp xỉ 40 µs, thời gian trung bình CPU cho giao dịch TPC-C là khoảng 26 µs. Do đó trong khi chờ phản hổi từ mạng, phân vùng có thể thực thi ít nhất 2 giao dịch đơn vùng. Một vài cơ chế điều khiển tương tranh cần cho phép một cách hữu ích trong lúc thời gian rỗi. 1.5 Cơ chế điều khiển phân tranh 1.5.1 Phong tỏa (Blocking) Cơ chế đơn giản nhất cho điều khiển giao dịch đa vùng là phong tỏa, ngăn chặn giao dịch cho đến khi nó thực hiện xong. Khi phân vùng nhận được phân mảnh đầu tiên của giao dịch, nó thực thi và trả lại kết quả. Tất cả các giao dịch khác được đưa vào hàng đợi. Khi nhận được phân mảnh con tiếp theo của giao dịch hiện tại, nó xử lý theo đúng thứ tự. Sau khi giao dịch được commit hoặc abort, giao dịch tiếp theo trong hàng đợi được xử lý. Mã giả cho cơ chế này như sau : 17 Hình 1.3 Mã giả cơ chế điều khiển phân tranh ―Phong tỏa‖ 1.5.2 Thực thi suy diễn(Speculative Execution) Lược đồ điều khiển phân tranh thực thi suy diễn giao dịch trong hàng đợi khi giao dịch phong tỏa nhằm tránh thời gian rỗi. Chính xác hơn, khi phân mảnh cuối cùng của giao dịch được thực thi, phân vùng phải đợi liệu giao dịch commits hay aborts. Trong phần lớn các trường hợp, nó sẽ commit. Do đó, chúng ta có thể thực thi giao dịch trong hàng đợi trong khi chờ 2PC kết thúc. Kết quả của các giao dịch được suy đoán thực hiện này không được gửi ra bên ngoài cơ sở dữ liệu vì nếu giao dịch trước đó bị hủy bỏ thì kết quả của giao dịch suy đoán này sẽ không chính xác. Thông tin Undo phải được ghi lại cho giao dịch suy diễn, vì vậy nó có thể rolled back khi cần thiết. Nếu giao dịch trước đó commits, tất cả các giao dịch suy diễn sẽ được commit ngay lập tức. Do đó, cơ chế duy diễn này dấu đi độ trễ của 2PC bằng cách thực thiện công việc hữu ích hơn thay vì phong tỏa. Suy diễn tạo ra lịch trình thực thi cũng tuần tự bởi vì một giao dịch t hoàn thành tất cả việc đọc và ghi của nó và đơn giản đợi liệu t có commit hay abort. Chúng ta có thể đảm bảo bất cứ giao dịch t_ nào sử dụng kết quả của t trên phân vùng p sẽ là tuần tự sau t trên phân vùng này. Tuy nhiên, t_ có thể đọc dữ liệu t ghi, vì vậy chúng ta phải hủy bỏ giao dịch t_ để tránh dữ liệu bẩn trong trường hợp t bị hủy bỏ. 1.5.2.1 Thực thi suy diễn giao dịch một phân vùng Mỗi phân vùng duy trì một hàng đợi các giao dịch chưa thực thi và hàng đợi các giao dịch chưa commit. Phía đầu của hàng đợi giao dịch chưa commit luôn luôn là giao dịch không phải suy diễn. Sau khi phân vùng thực thi phân mảnh cuối cùng, nó thực thi giao dịch suy diễn từ hàng đợi chưa thực thi và thêm vào cuối hàng đợi giao dịch chưa commit. Bộ đệm undo được lưu lại cho mỗi giao dịch. Nếu giao dịch không suy diễn hủy bỏ, mỗi giao dịch được loại bỏ từ đuôi của hàng đợi giao dịch 18 chưa commit và undone và đẩy ngược lại vào đầu của hàng đợi giao dịch chưa thực thi để có thể thực thi lại. Nếu nó commit, giao dịch được lấy ra khỏi hàng đợi từ phía đầu và kết quả được gửi trả lại. Khi hàng đợi chưa commit rỗng, hệ thống phục hồi việc thực thi các giao dịch không suy diễn (Các giao dịch không thể hủy bỏ, thực thi có thể được xử lý mà không gây quá tải do ghi thông tin undo). Một ví dụ, Một cơ sở dữ liệu có 2 phân vùng (P1 và P2) với 2 bản ghi integer, x trên P1 và y trên P2. Khởi tạo, x = 5 và y = 17. Giả sử hệ thống có 3 giao dịch, A, B1 và B2 một cách tuần tự. Giao dịch A là giao dịch đa vùng : Đổi chỗ giá trị x và y. Giao dịch B1 và B2 là giao dịch đơn vùng trên P1 : Tăng x và trả lại giá trị. Cả 2 phân vùng thực thi phân mảnh đầu tiên của giao dịch A, đọc x và y. P1 và P2 thực thi phân mảnh và trả lại giá trị cho bộ điều phối. Khi A chưa hoàn thành, suy diễn của B1 và B2 chưa thể bắt đầu. Nếu nó làm điều đó thì kết quả của giao dịch B1 sẽ là x = 6 và là sai. Bộ điều phối gửi phân mảnh cuối cùng, viết x = 17 trên phân vùng P1 và y = 5 trên phân vùng P2. Sau khi kết thúc những phân mảnh này, phân vùng gửi thông báo ―ready to commit‖ tới bộ điều phối và đợi quyết định. Bởi vì A đã kết thúc, suy diễn có thể bắt đầu. Giao dịch B1 và B2 được thực thi với bộ đệm undo và kết quả được đưa vào hàng đợi. Nếu giao dịch A bị hủy bỏ thì cả B2 và B1 sẽ undone và thực thi lại. Khi P1 thông báo giao dịch A đã commited, nó sẽ gửi kết quả của B1 và B2 tới client và client bỏ qua bộ đệm undo. 1.5.2.2 Thực thi suy diễn giao dịch đa phân vùng Quan tâm đến cùng ví dụ, ngoại trừ hệ thống thực thi A, B1 và một giao dịch mới đa vùng C : Tăng cả x và y, và cuối cùng là B2. Hệ thống thực thi giao dịch A trước và phân vùng P1 suy diễn B1. Phân vùng P2 có thể suy diễn phân mảnh của C và tính toán y = 6. Với sự suy diễn cục bộ miêu tả ở trên, nó phải đợi A commit trước khi trả lại kết quả cho bộ điều phối vì nếu A hủy bỏ, kết quả sẽ không chính xác. Tuy nhiên, bởi vì A và C có cùng bộ điều phối, phân vùng P2 có thể trả lại kết quả cho phân mảnh của nó là C với một chỉ dẫn rằng phụ thuộc vào giao dịch A. Tương tự, phân vùng P1 có thể suy diễn phân mảnh của C, tính toán và trả lại kết quả x = 17, cùng với chỉ dẫn phụ thuộc vào A. Nó cũng suy diễn B2, và tính toán x = 18. Tuy nhiên, nó không thể gửi kết quả này, vì nó sẽ đi trực tiếp tới client và không nhận thức được giao dịch trước đó, bởi vì giao dịch đơn vùng không đi qua bộ điều phối trung tâm. Khi một giao dịch đa vùng commited, hàng đợi giao dịch chưa commited rỗng, các phân vùng có thể phục hồi các thực thi không suy diễn. Sau khi bộ điều phối commit A, nó kiểm tra kết quả của C. Vì C phụ thuộc A và A commited, kết quả suy diễn là chính xác và C có thể commit. Nếu A bị hủy bỏ, bộ điều phối sẽ gửi thông báo hủy bỏ của A tới P1 và P2, và hủy bỏ các kết quả không đúng mà nó nhận từ C. Như trước đã đề cập, thông báo hủy bỏ sẽ gây ra các phân vùng undo các giao dịch trên hàng đợi giao dịch chưa commited. Giao dịch A sẽ hủy bỏ, nhưng các giao dịch khác sẽ được đặt trở lại hàng đợi chưa thực thi và thực thi lại 19 theo đúng thứ tự. Phân vùng sau đó gửi lại kết quả của C. Kết quả náy sẽ không phụ thuộc vào giao dịch trước, vì vậy bộ điều phối điều khiển bình thường. Mã giả cho cơ chế này như sau : Hình 1.4 Mã giả cơ chế điều khiển phân tranh ―Thực thi suy diễn‖ 1.5.3 Khóa (Locking) Trong cơ chế khóa, giao yêu cầu đọc và ghi phải khóa dữ liệu trước khi thực thi và treo (suspended) nếu tạo ra yêu cầu khóa xung đột. Giao dịch phải ghi thông tin undo để rollback trong trường hợp deadlock. Khóa cho phép phân vùng đơn thực thi và commit các giao dịch không xung đột của giao dịch đa vùng. Cơ chế khóa phải đảm bảo kết quả tương đương với việc thực thi giao dịch theo đúng trật tự. Nhược điểm là giao dịch khi thực thi có thể gây ra quá tải khi yêu cầu lock và khi phát hiện ra deadlock. Khi hệ thống của chúng ta không có giao dịch tích cực (active) nào và nhận được giao dịch đơn vùng, giao dịch sẽ được xử lý mà không cần lock và thông tin undo theo cùng phương pháp với cơ chế phong tỏa (blocking) và suy diễn 20 (speculation). Điều này là có thể bởi vì không có giao dịch tích cực nào gây ra xung đột, và giao dịch đảm bảo thực thi hoàn thành trước khi phân vùng thực thi giao dịch khác. Do đó, Lock duy nhất được yêu cầu khi có giao dịch đa vùng tích cực. Cơ chế khóa tuân theo giao thức khóa 2 pha nghiêm ngặt. Bởi vì điều này đảm bảo tạo ra trật tự tuần tự thực hiện giao dịch, client gửi giao dịch đa vùng trực tiếp tới các phân vùng mà không đi qua bộ điều phối trung tâm. Sẽ hiệu quả hơn khi không có xung đột, vì nó làm giảm độ trễ mạng và loại bớt các tiến trình xử lý phát. Tuy nhiên nó đưa ra khả năng deadlock phân tán. H-Store cài đặt cơ chế sử dụng phát hiện vòng tròn để điều khiển deadlock cục bộ và timeout để điểu khiển deadlock phân tán. Nếu vòng tròn được tìm thấy, nó sẽ kill giao dịch đơn để phá vỡ vòng tròn [1]. 1.6. Kết luận Trong chương một, tôi đã giới thiệu tổng quan mô hình xử lý giao tác với HStore. Đây là hệ thống cơ sở dữ liệu phân tán, chạy trên Cluster và với kiến trúc gồm 2 phần : Lược đồ triển khai và lược đồ thực thi. Hệ thống gồm 2 kiểu giao dịch : đơn vùng và đa vùng. Khả năng chịu đựng lỗi với công nghệ K-safes giúp cho H-Store luôn có tính sẵn sàng cao. Kiến trúc được thiết kế hoàn toàn hướng thủ tục, lưu trữ toàn bộ ở bộ nhớ trong. Với cơ chế điều khiển phân tranh gồm 3 cơ chế : Phong tỏa, thực thi suy diễn và khóa, đảm bảo các giao dịch được thực hiện đồng bộ và tuần tự. Trong chương thứ hai, tôi sẽ làm rõ việc ứng dụng mô hình H-Store trong việc quản trị CSDL, đặc biệt là xử lý giao tác trực tuyến với hệ thống quản trị cơ sở dữ liệu VoltDB – Một thể hiện tiêu biểu của H-Store.