Parallel and Distributed Databases- Full Version

PARALLEL AND DISTRIBUTED DATABASESMục lục

22.1 GIỚI THIỆU...........................................................................................................2

22.2 CẤU TRÚC CƠ SỞ DỮ LIỆU SONG SONG.........................................................3

22.3 ƯỚC LƯỢNG SONG SONG TRUY VẤN QUAN HỆ.............................................5

22.3.1 Data Partitioning..............................................................................................6

22.3.2 Parallelizing Sequential Operator Evaluation Code.........................................7

22.4 ĐỒNG BỘ TỪNG THAO TÁC RIÊNG LẺ.............................................................7

22.4.1 Bulk Loading and Scanning.............................................................................7

22.4.2 Sorting..............................................................................................................7

22.4.3 Joins..................................................................................................................8

22.5 ĐỒNG BỘ VIỆC TỐI ƯU CÂU TRUY VẤN........................................................10

22.6 GIỚI THIỆU VỀ CƠ SỞ DỮ LIỆU PHÂN TÁN..................................................11

22.6.1 Các loại cơ sở dữ liệu phân tán......................................................................12

22.7 MÔ HÌNH KIẾN TRÚC CƠ SỞ DỮ LIỆU PHÂN TÁN.......................................12

22.7.1 Hệ thống kết nối client/server........................................................................12

22.7.2 Hệ thống server cộng tác................................................................................13

22.7.3 Hệ thống trung gian........................................................................................13

22.8 LƯU TRỮ DỮ LIỆU TRONG CƠ SỞ DỮ LIỆU PHÂN TÁN.............................14

22.8.1 Sự phân mảnh.................................................................................................14

22.8.2 Sự nhân bản....................................................................................................15

22.9 QUẢN LÝ MỤC LỤC PHÂN TÁN.......................................................................15

22.9.1 Đối tượng tên..................................................................................................15

22.9.2 Cấu trúc danh mục..........................................................................................16

22.9.3 Sự độc lập của dữ liệu phân tán.....................................................................17

22.10 XỬ LÝ TRUY VẦN PHÂN TÁN:.........................................................................18

22.10.1 Thực thi Nonjoin trong hệ quản trị cơ sở dữ liệu phân tán:........................18

Page 1

PARALLEL AND DISTRIBUTED DATABASES

22.10.2 Thực thi Join trong hệ quản trị cở sở dữ liệu phân tán:................................19

22.10.3 Tối ưu chi phí cơ bản câu truy vấn:..............................................................23

22.11 CẬP NHẬT DỮ LIỆU PHÂN TÁN.....................................................................23

22.11.1 Nhân bản đồng thời.....................................................................................24

22.11.2 Sự nhân bản không đồng thời.......................................................................24

22. 12 GIAO TÁC PHÂN TÁN:....................................................................................27

22.13 ĐIỀU KHIỂN ĐỒNG THỜI ĐƯỢC PHÂN TÁN...............................................27

22.13.1 Phân bố deadlock.........................................................................................29

22.14 KHÔI PHỤC LẠI DỮ LIỆU PHÂN TÁN...........................................................31

22.14.1 Normal Execution and Commit Protocols...................................................32

22.14.2 Restart after a Failure...................................................................................33

22.14.3 Two-Phase Commit Revisited......................................................................34

22.14.4 Three Phase Commit....................................................................................36

Page 2


22.1 GIỚI THIỆU - Chúng ta xem như các hệ thống quản lý dữ liệu tập trung thì toàn bộ dữ liệu luôn duy trì tại 1 site đơn lẻ và giả định rằng việc xử lý 1 transaction riêng biệt là xử lý tuần tự. Một trong những hướng quan trọng của cơ sở dữ liệu là mở rộng sử dụng các kỹ thuật định lượng song song và sự phân tán dữ liệu.

- Một hệ thống cơ sở dữ liệu song song cố gắng cải tiến sự thực thi bằng việc thực hiện song song các hoạt động khác nhau, như: load dữ liệu, xây dựng chỉ mục, và định lượng các truy vấn. Mặc dù dữ liệu có thể được lưu trữ theo kiểu phân tán trong hệ thống, sự phân tán bị chi phối bởi việc đánh giá sự thực thi.

- Trong hệ thống cơ sở dữ liệu phân tán, về mặt vật lý dữ liệu được lưu trữ ở một vài site, và mỗi site được quản lý bởi 1 DMBS có khả năng chạy độc lập với những site khác , vị trí của mỗi data và mức độ tự quản của mỗi site có sự ảnh hưởng có ý nghĩa trong toàn mặt của hệ thống, bao gồm sự tối ưu hóa và thực thi truy vấn, việc quản lý đồng nhất và việc khôi phục. Ngược lại với những cơ sở dữ liệu song song, dữ liệu phân tán bị chi phối bởi nhiều nhân tố như quyền sở hữu cục bộ và mở rộng tính sẵn sàng, và các kết quả sự thực thi.

- Khi trạng thái song song được kích hoạt bởi những xem xét sự thực thi, một vài vấn đề riêng biệt thúc đẩy sự phân tán dữ liệu:

Mở rộng tính sẵn sàng: nếu một quan hệ chứa trong 1 site bị hỏng, thì quan hệ đó vẫn tiếp tục sử dụng được nếu có 1 bản copy được duy trì tại 1 site khác.

Phân bổ việc truy cập vào dữ liệu: một vài công ty có sự tổ chức gồm nhiều chi nhánh. Những người phân tích có thể cần truy cập vào data với những site khác nhau, thông thường chúng ta tìm ở vị trí của các mẫu truy cập (như người quản lý ngân hàng thì thường dựa vào các tài khoản của các khách hàng tại chi nhánh cục bộ) và vị trí này có thể được khai thác qua việc phân bổ dữ liệu phù hợp.

Phân tích dữ liệu được phân bổ: Các tổ chức muốn kiểm tra toàn bộ dữ liệu có giá trị đối với họ, ngay cả khi nó được lưu trữ qua nhiều site và trên nhiều hệ thống cơ sở dữ liệu. Hỗ trợ cho sự truy cập được tích hợp bao gồm nhiều vấn đề, bằng việc cho phép truy cập nhiều vào dữ liệu được phân tán có thể là một thách thức.

22.2 CẤU TRÚC CƠ SỞ DỮ LIỆU SONG SONG - Ý tưởng cơ bản của cơ sở dữ liệu song song là tiến hành các bước định giá song song bất cứ khi nào có thể, hệ quản trị cơ sở dữ liệu quan hệ có rất nhiều ưu điểm này, các cơ sở dữ liệu mô tả một trong những đối tượng thành công nhất của việc tính toán song song.

Page 3


- Có 3 kiến trúc chính được đề nghị trong việc xây dựng các DBMS song song:

Trong hệ thống shared-memory , các CPU được gắn liền với 1 mạng nối liền với nhau và có thể truy cập một vùng chung trên bộ nhớ chính.

Trong hệ thống shared-disk , mỗi CPU có mộ bộ nhớ riêng và truy cập trực tiếp tới các đĩa qua mạng nối liền nhau.

Trong hệ thống shared-nothing, mỗi CPU có bộ nhớ chính và đĩa trống cục bộ, nhưng 2 CPU ko thể truy cập cùng 1 vùng lưu trữ, toàn bộ việc truyền thông tin giữa các CPU là thông qua sự kết nối mạng.

- Kiến trúc shared-menory gần với máy thông thường, nhiều hệ thống cơ sở dữ liệu thương mại đã dùng để chia sẻ bộ nhớ tương đối dễ dàng. Sự kết nối ở tầng trên thì rất thấp, do bộ nhớ chính được dùng cho mục đích này, và các dịch vụ điều khiển hệ thống có tác dụng để tận dụng các CPU cộng thêm vào. Mặc dù phương pháp này đạt được trạng thái song song vừa phải – khoảng 10 CPU có thể khai thác trong mô hình này – sự tranh giành bộ nhớ sẽ gây ra hiện tượng thắt cổ chai khi số lượng CPU tăng lên. Kiến trúc shared-disk hướng về vấn đề tương tự do số lượng lớn dữ liệu di chuyển qua mạng kết nối liền nhau.

- Vấn đề cơ bản trong kiến trúc shared-memory và shared-disk là sự can thiệp: khi có nhiều CPU được cộng thêm, các CPU hiện đang tồn tại sẽ bị chậm lại do sự tranh giành truy cập vào bộ nhớ và băng thông của mạng tăng lên. Trung bình khi CPU chậm lại 1% thì vận tốc lớn nhất là hệ số của 37, và việc cộng thêm các CPU thực sự làm chậm lại hệ thống, 1 hệ thống với 1000 CPU thì chỉ có 4% làm việc hiệu quả như 1 hệ thống chỉ gồm 1 CPU đơn lẻ. Sự theo dõi này được thực hiện bởi các developer của kiến trúc shared-nothing, đây là kiến trúc hiện được coi là kiến trúc tốt nhất cho các hệ thống cơ sở dữ liệu song song lớn.

- Kiến trúc shared-nothing đòi hỏi mở rộng sự tổ chức lại của mã DBMS, nó được đưa ra nhằm cung cấp vận tốc tuyến tính, thời gian cho các hoạt động giảm xuống tương ứng với số lượng các CPU và disk tăng lên, và tăng lên

Page 4


tuyến tính, sự thực thi được duy trì liên tục nếu số lượng CPU và các đĩa tăng lên tương đối với số lượng dữ liệu. Do đó, ngày càng nhiều hệ thống cơ sở dữ liệu song song được xây dựng bằng việc cải tiến sự thực thi của hệ thống CPU đơn lẻ và việc kết nối nhiều CPU như mô tả trên.

- Speed-up và scale-up được mô tả trong hình 22.2 . Đường cong speed-up chỉ ra rằng đối với 1 kích thước database cố định, các transactions có thể thực thi bằng các thêm CPU. Các đường cong scale-up chỉ ra cách cộng thêm các tài nguyên (trong hình thái của các CPU) làm cho chúng ta được truy cập vào các vấn đề lớn hơn. Hình scale-up đầu tiên đo số lượng các transaction thực thi mỗi giây khi kích thước cơ sở dữ liệu tăng lên và số lượng CPU giảm tương ứng. Một cách khác để đo scale-up là xem xét thời gian của mỗi transaction như khi các CPU được cộng thêm để xử lý thì số lượng transaction tăng lên trong mỗi giây, mục đích là để duy trì thời gian trả lời cho mỗi transaction.

22.3 ƯỚC LƯỢNG SONG SONG TRUY VẤN QUAN HỆ

- Trong chương này, chúng ta thảo luận việc ước lượng song song truy vấn quan hệ trong DBMS với kiến trúc shared-nothing. Mặc dù nó được xem là có thể thực thi đa truy vấn, nhưng nó cũng khó để mở rộng các truy vấn chạy đồng thời.Do đó ở đây nhấn mạnh việc thực thi song song truy các truy vấn đơn.

- Bản đồ sự thực thi truy vấn quan hệ là biểu đồ các toán tử số học quan hệ, và các toán tử trong biểu đồ có thể thực thi song song. Nếu 1 toán tử dùng output của toán tử thứ 2, chúng sẽ truyền song song (output của toán tử số 2 sẽ được dùng bởi toán tử thứ nhất ngay khi nó được tạo ra); ngược lại, cả 2 toán tử có thể tiến hành độc lập. Một toán tử bị chặn nếu nó ko đưa ra output cho tới khi nó sử dụng hết toàn bộ các tham số input. Trạng thái song song được cung cấp thì bị giới hạn bởi các toán tử (sort hay kết hợp).

Page 5


- Nói thêm về sự ước lượng các toán tử khác nhau trong trạng thái song song, chúng ta có thể ước lượng mỗi toán tử riêng biệt trong bản đồ truy vấn mô hình song song. Khóa để ước lượng 1 toán tử trong song song là partition dữ liệu đưa vào. Chúng ta có thể làm việc trên mỗi partition trong song song và kết hợp các kết quả lại. Phương pháp này gọi là định lượng song song data-partitioned.

- Một sự theo dõi quan trọng giải thích tại sao hệ thống cơ sở dữ liệu song song shared-nothing rất thành công, đó là do việc định lượng truy vấn cơ sở dữ liệu rất tuân thủ việc định lượng song song data-partitioned. Mục đích là làm nhỏ nhất việc di chuyển dữ liệu bằng việc phân chia dữ liệu và cấu trúc của thuật toán để thực hiện hầu hết các xử lý tại processor (processor là CPU và ổ cứng cục bộ của nó).

22.3.1 Data Partitioning

- Việc phân chia một tập dữ liệu lớn theo chiều ngang qua các đĩa cho phép chúng ta có thể khai thác băng thông I/O của đĩa bằng việc đọc và viết chúng song song. Có nhiều cách để phân chia quan hệ theo chiều ngang. Chúng ta có thể gán các bộ để xử lý theo mô hình round-robin., hoặc băm (hashing) hoặc gán các bộ xử lý bằng các miền của các giá trị của trường. Nếu có n xử lý, xử lý thứ i sẽ được gán là i mod n trong mô hình round-robin. Để gọi lại việc phân chia round-robin dùng hệ thống lưu trữ RAID (xem chương 9.2). Trong hash partitioning, hàm hash sẽ được áp dụng cho 1 bộ để xác định bộ xử lý của nó. Trong range partitioning, các bộ được sắp xếp (dựa trên khái niệm), và n miền được chọn theo các giá trị khóa sắp xếp nên mỗi miền chứa xấp xỉ cùng 1 số bộ, các bộ trong miền i được gán cho bộ xử lý thứ i.

- Việc phân chia round-robin thì có khả năng ảnh hưởng đến việc định lượng các truy vấn để truy cập vào toàn bộ quan hệ. Nếu chỉ có 1 tập nhỏ các quan hệ (vd: chỉ cần thỏa mãn điều kiện select age = 20) được yêu cầu, hash partitioning và range partitioning thì tốt hơn round-robin partitioning vì chúng cho phép chúng ta truy cập vào vùng đĩa có chứa các bộ dữ liệu đó. (câu lệnh select age = 20 chỉ đưa ra những bộ có thuộc tính thỏa mãn điều kiện nếu age = 20) . Mặt khác, range partitioning có thể làm cho dữ liệu bị chênh lệch, các partition có các giá trị khác nhau của các bộ qua các partition hoặc các disk. Sự chênh lệch làm các bộ xử lý với số lượng partition lớn trở thành hiện tượng thắt cổ chai. Hash partitioning có ưu điểm là giữ cho dữ liệu bị phân tán nếu dữ liệu tăng lên và co lại theo thời gian.

- Để giảm bớt sự chênh lệch dữ liệu trong range partitioning, câu hỏi chính là làm sao để chọn ra miền từ các bộ được phân tán. 1 phương pháp có hiệu quả

Page 6


là lấy ví dụ từ mỗi bộ xử lý, tập hợp và sắp xếp lại các ví dụ này, và chia các tập ví dụ đã được sắp xếp vào các tập con cùng kích thước. Nếu các bộ là các partition age, miền age của tập con được ví dụ của bộ có thể được dùng như phần cơ bản cho việc phân tán lại toàn bộ quan hệ.

22.3.2 Parallelizing Sequential Operator Evaluation Code

- Một kiến trúc phần mềm của DMBS song song có thể cho chúng ta đọc song song các mã đang tồn tại cho cho việc định lượng quan hệ tuần tự. Ý tưởng cơ bản là sử dụng data streams song song. Streams ( từ nhiều ổ cứng khác nhau hoặc là output của các toán tử khác) được kết hợp để cung cấp input cho 1 toán tử quan hệ, và output của 1 toán tử được tách ra để thực hiện song song xử lý các dãy con.- Một sơ đồ định lương song song bao gồm 1 dataflow network, các toán tử kết hợp và tách rời. Các toán tử tích hợp và tách rời có thể làm vùng đệm cho các dữ liệu và có thể tạm ngưng các toán tử đưa ra dữ liệu input của chúng.-Để đạt được các kiểu thuật toán song song song tốt cho các câu truy vấn định lượng toán tử tuần tự đòi hỏi sự cân nhắc cẩn thận.

22.4 ĐỒNG BỘ TỪNG THAO TÁC RIÊNG LẺ - Phần này cho ta thấy làm sao mà nhiều thao tác có thể được xử lý song song với nhau trong một cấu trúc shared- nothing.Chúng ta giả định rằng mỗi quan hệ (relation) được tách ngang trên nhiều đĩa, mặc dù sự phân chia này có hoặc không thích hợp với yêu cầu (query) đề ra.

22.4.1 Bulk Loading and Scanning

- Chúng ta bắt đầu với 2 thao tác đơn giản: Scanning và Loading một quan hệ. Nhiều trang có thể được đọc cùng lúc khi scan một quan hệ.-Tương tự cho bulk loading. Nếu 1 quan hệ có index, bất kì việc sắp xếp dữ liệu đầu vào nào được yêu cầu để xây dựng index trong suốt quá trình bulk loading có thể được làm song song (chúng ta sẽ thấy rõ hơn ở các phần sau).

22.4.2 Sorting

- Một ý tưởng đơn giản là cho mỗi CPTJ sort 1 phần của quan hệ và sau đó merge tập hợp các bộ đã được sắp xếp này lại với nhau. Mức độ song song bị giới hạn bởi giai đoạn merge.

- Một ý kiến tốt hơn là phân phối lại các bộ dữ liệu trong quan hệ sử dụng range partition (phân chia phạm vi). Ví dụ , nếu chúng ta muốn sắp xếp 1 tập

Page 7


các bộ nhân viên theo mức lương từ 10-210, và chúng ta có 20 bộ xử lý, chúng ta có thể gởi tất cả các bộ có giá trị tiền lương trong khoảng từ 10-20 vào bộ xử lý đầu tiên, từ 21-30 cho bộ xử lý thứ hai và tiếp tục như thế.

- Mỗi bộ xử lý sắp xếp các bộ được gán cho nó, sử dụng thuật toán sắp xếp tuần tự. Ví dụ, bộ xử lý tập hợp các bộ dữ liệu cho đến khi bộ nhớ của chúng đầy, sau đó sắp xếp các bộ này và write out a run, cho đến khi tất cả các bộ dữ liệu thành các sorted run trên local disk, những run này có thể được merge lại để tạo ra phiên bản được sắp xếp của tập các bộ được gán cho bộ xử lý này.

- Thách thức cơ bản của việc sắp xếp đồng thời là tạo range partition để mỗi bộ xử lý nhận được số bộ dữ liệu gần giống nhau, hay nói cách khác, khi có một bộ xử lý nhận được một số lượng lớn các bộ dữ liệu để sắp xếp gây ra tình trạng thắt cổ chai và làm giới hạn việc sắp xếp song song.

- Một cách tiếp cận tương đối tốt để phân chia phạm vi là thu mẫu của toàn bộ quan hệ bằng cách lấy mẫu ở mỗi bộ xử lý mà chứa 1 phần quan hệ. Mẫu này (tương đối nhỏ) được sắp xếp và sử dụng để xác định các phạm vi cho số bộ bằng nhau. Tập những giá trị phạm vi này, được gọi là splitting vector, được phân phối đến toàn bộ các bộ xử lý và được sử dụng để phân chia phạm vi toàn quan hệ.

- Một ứng dụng đặc biệt quan trọng của việc sắp xếp đồng thời là sắp xếp các dữ liệu đầu vào (data entry) trong cấu trúc chỉ mục dạng cây (tree-structured index). Việc sắp xếp dữ liệu đầu vào có thể làm tăng tốc quá trình bulk loading chỉ mục.

22.4.3 Joins

- Trong đoạn này, chúng ta quan tâm đến cách làm cho phép kết có thể được xử lý song song. Chúng ta đã đưa ra ý tưởng cơ bản về quá trình song song và minh họa việc sử dụng phương thức merge và split trong phần 22.3.2.

- Giả sử rằng, chúng ta muốn kết 2 quan hệ, quan hệ A và B theo thuộc tính tuổi. Chúng ta giả định rằng chúng được phân tán trên nhiều đĩa và sự phân chia không dựa trên thuộc tính kết. Ý tưởng cơ bản cho việc kết A và B thực hiện song song là phân tích phép kết thành k phép kết nhỏ. Chúng ta có thể phân tích phép kết bằng việc phân chia cả A và B thành 1 tập k logical bucket hoặc partition. Bằng cách sử dụng hàm phân chia giống nhau cho cả A và B, chúng ta bảo đảm rằng việc kết k phép kết nhỏ hơn giống như kết A và B lớn.

- Một cách khác, chúng ta có thể chia A và B bằng cách chia phạm vi của thuộc tính tuổi thành k phạm vi con. Những bộ dữ liệu của A và B được chia thành partition căn cứ vào phạm vi con của giá trị tuổi. Ví dụ, chúng ta có 10 bộ xử lý, thuộc tính dùng để kết là tuổi với giá trị 0-100. Ta phân phối theo

Page 8


hình thức: những bộ dữ liệu của A và B với độ tuổi 0-10 chuyển cho bộ xử lý 1, 10-20 cho bộ xử lý 2, …

- Chúng ta có thể gán mỗi partition cho 1 processor và thực thi phép kết cục bộ, sử dụng bất kì thuật toán kết nào mà chúng ta muốn ở mỗi bộ xữ lý. Trong trường hợp này, số partiton k được chọn bằng số bộ xử lý n sẳn sàng để thực thi phép kết và trong suốt quá trình phân chia, mỗi bộ xử lý gửi các bộ trong partition thứ i tới bộ xử lý. Sau quá trình phân chia, mỗi bộ xử lý kết các bộ của A và B được gán cho nó. Mỗi tiến trình kết thực hiện tuần tự với join code và nhận input các bộ dữ liệu A và B từ nhiều bộ xử lý; một thao tác merge merge tất cả các bộ của A và một thao tác merge khác merge tất cả các bộ của B. Dựa vào việc chúng ta muốn phân tán kết quả của phép kết của A và B hay không, output của tiến trình kết có thể bị split thành nhiều data steam. Hệ thống các thao tác của việc thực hiện song song phép kết trong hình 22.3. Để đơn giản hình này, chúng ta giả định các bộ xử lý thực hiện phép kết thì riêng biệt với các bộ xử lý mà chứa các bộ dữ liệu A và B và chỉ có 4 bộ xử lý.

- Nếu range partition được sử dụng, thuật toán này dẫn tới phiên bản song song của sort merge join với thuận lợi là output thì được sắp xếp có thứ tự sẳn. Nếu hash partition được sử dụng, chúng ta thu được một phiên bản song song của hash join.

Improved Parallel Hash Join

- Các tiếp cận cải tiến hash cơ bản là cải tiến hiệu năng. Lí do là, nếu A và B quá lớn và số partition k được chọn bằng với số bộ xử lý n, thì kích thước của mỗi partition có thể vẫn còn rất lớn, dẫn đến chi phí cao ở mỗi phép kết cục bộ tại n bộ xử lý.

Page 9


- Cách khác là thực thi các phép kết nhỏ Ai với Bi (i=1…k), tuần tự (one after the other) nhưng với mỗi phép kết được thực thi song song sử dụng tất cả các bộ xử lý. Cách tiếp cận này cho chúng ta tận dụng toàn bộ bộ nhớ chính có thể tại tất cả n bộ xử lý trong mỗi phép kết Ai với Bi và được miêu tả chi tiết như sau:

1. Tại mỗi nơi, áp dụng hàm hash h1 để phân chia các bộ của A và B tại nơi này thành các partition i=1 … k. A thành nhiều quan hệ nhỏ hơn. Số lượng partition k là số partition của A thích hợp với toàn khối hay một phần bộ nhớ của tất cả n bộ xử lý.

2. For i= 1… k, xử lý phép kết của partition thứ i của A và B. Để thực hiện Ai kết Bi, làm các bước sau tại mỗi nơi:

a. Áp dụng hàm hash h2 cho tất cả các bộ Ai nhằm xác định nơi chúng nên được kết và send bộ t vào vị trí h2(t).

b. Khi các bộ Ai tới đến để được kết, thêm chúng vào bảng hash in-memory

c. Sau khi tất cả các bộ Ai được phân bố, áp dụng h2 cho tất cả các bộ của Bi nhằm xác định nơi chúng nên được kết và send bộ t vào vị trí h2(t).

d. Khi các bộ Bi tới để được kết, dò bảng in-mermory của các bộ Ai và output các bộ kết quả.

- Sử dụng hàm hash h2 bảo đảm rằng các bộ (nhiều hay ít) được phân bố đều trên tất cả n bộ xử lý tham gia vào phép kết. Cách tiếp cận này làm giảm đáng kể chi phí của từng phép kết nhỏ và do đó giảm chi phí trên toàn phép kết. Cho thấy rằng tất cả các bộ xử lý sẵn sàng (available) đều được tận dụng hoàn toàn, dù là những phép kết nhỏ hơn được thực hiện tuần tự (one after the other).

22.5 ĐỒNG BỘ VIỆC TỐI ƯU CÂU TRUY VẤN

- Ngoài đồng bộ từng thao tác riêng lẽ, chúng ta có thể thực hiện song song những thao tác khác nhau trong 1 câu query và thực thi nhiều câu query cùng lúc. Việc tối ưu 1 câu query là việc nên làm, hệ thống sẽ tối ưu những câu query mà không cần quan tâm đến những câu query khác đang được thực thi tại cùng thời điểm đó.

Hai loại hoạt động đồng thời có thể được khai thác trong câu query: Kết quả của một toán tử có thể được chuyển đến toán tử khác. Chẳng

hạn cho một kế hoạch left-deep mà trong đó tất cả các phép kết sử dùng index nested loop. Những bộ được sinh ra bởi phép kết thứ nhất, chúng trở thành quan hệ đầu vào cho phép kết thứ hai. Kết quả của phép kết thứ 2 được chuyễn tương tự vào phép kết tiếp đó, và tiếp tục như thế.

Page 10


Nhiều thao tác độc lập có thể thực hiện đồng thời. Ví dụ,cho kế hoạch trong đó quan hệ A kết với B,C kết với D, và kết quả của hai phép kết này kết với nhau. Rõ ràng là phép kết giữa A và B có thể thực hiện đồng thời với phép kết giữa C và D.

- Optimizer (bộ tối ưu) phải quan tâm tới nhiều vấn đề, và chúng ta chỉ phát thảo những vấn đề chính. Chi phí cho việc thực thi các thao tác riêng lẽ song song (ví dụ: sắp xếp song song) khác rõ ràng với thực thi chúng tuần tự và optimizer nên đánh giá những chi phí thao tác 1 cách phù hợp.

- Tiếp theo, kế hoạch mà cho câu trả lời nhanh nhất có thể không là kế hoạch có chi phí ít nhất. Ví dụ chi phí của A kết B cộng chi phí C kết D cộng chi phí kết kết quả của 2 kết trước có thể nhiều hơn chi phí kế hoạch cheapest left-deep. Tuy nhiên thời gian thực hiện việc A kết B cộng C kết D cộng thời gian kết kết quả thì ít hơn thời gian thực hiện kế hoạch cheapest left-deep

- Cuối cùng, 1 số các thông số, như không gian buffer available và số bộ xử lý rãnh, chỉ được biết lúc run-time. Điều này xảy ra trong môi trường đa người dùng dù chỉ xem xét các kế hoạch tuần tự. Môi trường đa người dùng là 1 ví dụ đơn giản của interquery parallelism.

22.6 GIỚI THIỆU VỀ CƠ SỞ DỮ LIỆU PHÂN TÁN

- Như chúng ta đã đề cập trước đó, dữ liệu trong hệ thống cơ sở dữ liệu phân tán được lưu trữ ở nhiều nơi, và mỗi nơi được quản lý bởi 1 DBMS mà nó chạy độc lập với các nơi khác. Quan niệm cổ điển của hệ thống cơ sở dữ liệu phân tán là hệ thống này nên làm cho các dữ liệu phân tán trong suốt. Cụ thể, những thuộc tính sau đây cần được xem xét:

Độc lập dữ liệu phân tán: người dùng có thể yêu cầu truy vấn mà không xác định rõ nơi tham chiếu đến những quan hệ. Nguyên lý này là 1 mở rộng về độc lập dữ liệu ở mức vật lý và logic một cách tự nhiên, chúng ta tìm hiểu rõ hơn 22.8. Hơn nữa, những câu truy vấn mà trải trên nhiều nơi nên được tối ưu về chi phí cơ bản.Chúng ta sẽ thảo luân rõ phần việc tối ưu hóa câu truy vấn phân tán trong phần 22.10

Atomic transaction phân tán: người dùng có thể viết các transaction truy cập và update dữ liệu ở nhiều nơi giống như là họ có thể viết các transaction trên dữ liệu hoàn toàn cục bộ. Cụ thể, ảnh hưởng của 1 transaction ở các nơi là atomic. Nghĩa là tất cả các thay đổi có hiệu lực nếu transaction commit và không có hiệu lực nếu transaction abort. Chúng ta sẽ thảo luận tiến trình transaction trên dữ liệu phân tán trong mục 22.11, 22.13 và 22.14.

- Mặc dù hầu hết mọi người đồng ý những thuộc tính này là phổ biến trong hầu hết hoàn cảnh nhưng khi các nơi này được kết nối bởi slow long distance

Page 11


network, những thuộc tính này không hiệu quả khả thi. Thật vây, có tranh luận rằng khi các vị trí được phân tán rộng rãi thì những thuộc tính đó không còn thích hợp. Ý kiến tranh cải cho rằng chi phí quản lý như hỗ trợ hệ thống với sự độc lập dữ liệu phân tán và atomic transaction- tất cả các hoạt động hỗ trợ cách nhìn toàn bộ như là 1 tập dữ liệu thống nhất thì quá cao, cần cân nhắc đến hiệu năng tối thiểu và tối đa của DBMS.

22.6.1 Các loại cơ sở dữ liệu phân tán

- Nếu dữ liệu được phân tán nhưng tất cả các server chạy cùng 1 phần mềm DBMS, chúng ta có hệ thống cơ sở dữ liệu phân tán thuần nhất (homogeneous distributed database system). Nếu các nơi khác nhau chạy dưới sự điều khiển của các DBMS khác nhau, và được kết nối bằng cách này hay cách khác để truy cập dữ liệu từ nhiều nơi, chúng ta có hệ thống cơ sở dữ liệu phân tán không thuần nhất (heterogeneous distributed database system), hay còn gọi là hệ thống đa cơ sở dữ liệu.

- Chìa khóa để xây dựng hệ thống không thuần nhất là có những chuẫn well- accepted gateway protocol. Gateway protocol là 1 API phô bày các tính năng của DBMS ra những ứng dụng bên ngoài. Ví dụ bao gồm ODBC và JDBC. Bằng cách truy cập database server thông qua gateway protocol, những sự khác nhau (về data format…) được mask và những sự khác nhau giữa những server khác nhau trong hệ thống phân tán được bắt cầu đến phạm vi lớn.

- Gateway không là vạn năng, tuy nhiên chúng có thể thêm layer cho tiến trình-có thể rất tốn kém, và chúng không hoàn toàn mask những sự khác nhau giữa các server. Ví dụ server không có khả năng cung cấp dịch vụ được yêu cầu từ bộ quản lý transaction phân tán (mục 22.13, 22.14) và thậm chí nếu có thể, chuẩn gateway protocol thấp hơn interaction level tạo ra thách thức làm yêu cầu không được giải quyết một cách thỏa mãn.

- Bộ quản lý dữ liệu phân tán, trong sự phân tích cuối, tốn chi phí đáng kể ở phần hiệu năng, độ phức tạp của phần mềm, độ khó quản lý. Sự quan sát này thì đặc biệt đúng cho hệ thống không thuần nhất.

22.7 MÔ HÌNH KIẾN TRÚC CƠ SỞ DỮ LIỆU PHÂN TÁN

Trong các mô hình kiến trúc của hệ QTCSL phân tán ,ta sẽ tìm hiểu 3 mô hình sau:Client-Server,Collaborating Server,and Middleware.

22.7.1 Hệ thống kết nối client/server

Page 12


Hệ thống kết nối client/server có một hay nhiều tiến trình client và có một hay nhiều tiến trình server ,và một tiến trình client có thể gửi câu truy vấn đến bất cứ server nào.Phía client có giao diện người dùng,và các server quản lý dữ liệu và thực thi các giao tác.Do đó,môt tiến trình client có thể chạy trên một máy tính độc lập và gửi câu truy vấn đến server trên mainframe.

Cấu trúc này cho đền nay vẫn còn phổ biến bởi các lý do sau:

Thứ nhất:Nó thì đơn giản để thực hiện vì sự phan chia các chức năng rõ rang và bởi vì server thì nơi tập trung dữ liệu.

Thứ hai:thiết bị server trang trị khá đắt có thể giải quyết được những tương tác thường xuyên của người dùng.

Thứ 3:người dùng có thể thực thi trên giao diện người dùng ,nó thì giống và tốt hơn giao diện người dùng trên server.

Trong khi thực hiện những ứng dụng với mô hình client/server,điều quan trọng cần nhớ là ranh giới giữa client và server và giữ giao tiếp giữa chúng một cách có định hướng khi có thể.

22.7.2 Hệ thống server cộng tác.

Cấu trúc client/server không cho phép một câu truy vấn đơn gửi đến các hệ thống server phức tạp bởi vì tiến trình client sẽ có thể bị ngắt như một câu truy vấn nằm trong những câu truy con thích hợp được thực thi ở những nơi khác nhau và sau đó kết hợp lại các câu trả lời lại cho câu truy vấn con.Tiến trình client sẽ trở nên phức tạp .

Khi một server nhận được câu truy vấn mà cau truy vấn này muốn truy cập vào dữ liệu ở server khác,nó sẽ phát sinh ra những câu truy vấn con thích hợp được thực thi bởi server khác và trả lại kết quả sau khi tính toán cho câu truy vấn l1uc đầu.

22.7.3 Hệ thống trung gian

Cấu trúc trung gian được thiết kế cho phép một câu truy vấn đơn đến nhiều server,mà không đòi hỏi các server hệ quản trị cơ sở dữ liệu về khả năng quản lý như là các cách để thực thi câu truy vấn ở nhiều vị trí.

Theo mô hình này ,chúng ta chỉ cần một server hệ quản trị cơ sở dữ liệu để có thể quản lý các câu truy vấn và giao tác qua nhiều server;các server còn lại chỉ thực hiện các giao táo và câu truy vấn cục bộ.Chúng ta có thể suy nghĩ server đặc biệt này như là một tầng của phần mềm ,nó phối hợp sự thực thi

Page 13


câu tri vấn và giao tác với với một hay nhiều server có hệ quản trị cơ sở dữ liệu phụ thuộc;giống như phần phềm thường được gọi là lớp trung gian.Tầng trung gian có thể tham gia thực thi và tham gia với các hoạt động có lien quan khác trên dữ liệu có được từ các server khác ,nhưng thông thường,nó không tự duy trì được dữ liệu.

22.8 LƯU TRỮ DỮ LIỆU TRONG CƠ SỞ DỮ LIỆU PHÂN TÁN.

Trong cơ sở dữ liệu phân tán,mối lien hệ được lưu trữ qua nhiều nơi. Để phân tán cơ sở dữ liệu có hai hoạt chính là :phân tán và phân mảnh,với việc phân mảnh lưu trữ ở nhiều nơi mà nơi đó họ thường truy cập thường xuyên nhất.

22.8.1 Sự phân mảnh

Sự phân mảnh chính là hoạt động chia một quan hệ thành các quan hệ nhỏ hơn và lưu trữ các phân mảnh này ở nhiều nơi khác nhau.Trong phân mảnh ngang,mỗi phân mảnh chứa tập hợp con các dòng từ quan hệ ban đầu.Trong phân mãnh dọc ,mỗi phân mãnh chứa tập con các cột từ quan hệ ban đầu.

Khi một quan hệ được phân mãnh ,chúng ta phải đảm bảo có thể khôi phục lại quan hệ ban đầu từ các phân mãnh:

Phân mãnh ngang:Kết hợp các phân mãnh ngang lại với nhau phải bằng với quan hệ lúc đầu.Các phân mãnh thì thông thường là tách rời nhau.

Phân mãnh dọc:tập hợp các phân mãnh dọc lại nên bảo toàn tính ko bị mất cột khi nối lại.

Page 14


Tóm lại ,một quan hệ có thể phân mảnh dọc hay ngang ,và mỗi kết quả khi phân mãnh có thể được phân mãnh tiếp nữa.

22.8.2 Sự nhân bản

Sự nhân bản được hiểu như sau:chúng ta có thể lưu trữ dữ liệu với nhiều bảng sao của một quan hệ hay phân mãnh quan hệ.Một quan hệ có thể được nhân bản ở một hay nhiều nơi.Ví dụ,nếu quan hệ R sau khi phân mãnh được các quan hệ:R1,R2,R3…thì có thể R1 sẽ nhân bản thêm R1 nửa,còn R2 thì sẽ được nhân bản ở hai nơi khác nhau và R3 thì được nhân bản ở mọi nơi.

Ưu điểm của nhân bản là:

Tính sẵn sang của dữ liệu/:nếu một nơi chứa nhân bản một quan hệ nào đó bị mất đi,thì chúng ta có thể tìm thấy dữ liệu ở nơi khác.Giống như,nếu bản nhân bản cục bộ của một quan hệ có sẵn,chúng ta sẽ ít gặp thất bại hơn trong việc kết nối giao tiếp.

Câu truy vấn sẽ thực hiện nhanh hơn: Câu truy vấn sẽ thực hiện nhanh hơn bằng cách truy cập lên bảng nhân bản cục bộ của một quan hệ thay vì phải truy cập đến nơi khác.

Có hai loại nhân bản :nhân bản đồng thời và không đồng thời,sự khác nhau chủ yếu trong hai cách nhân bản là giữ lại quan hệ hiện hành trước khi quan hệ đó thay đổi.

22.9 QUẢN LÝ MỤC LỤC PHÂN TÁNVết dữ liệu khi bị phân tán ở nhiều nơi có thể trở nên phức tạp.Vì vậy

chúng ta phải luu lại cách mà những quan hệ được phân mảnh và nhân bản, và những phân mãnh quan hệ được phân tán ở nhiều nơi được thực hiện như thế nào và những phân mãnh được nhân bản được lưu trữ ở đâu.

22.9.1 Đối tượng tên

Nếu một quan hệ được phân mãnh và nhân bản ,thì mỗi nhân bản của một phân mãnh được biết là duy nhất .Nếu chúng ta sử dụng tên server tổng thể để gán cho tên duy nhất,tự điều khiển cục bộ sẽ bị dung hòa,,chúng ta muốn mổi nơi có thể gán tên cho những đối tượng cục bộ mà không cần tham chiếu đến hệ thống tên.

Trường tên cục bộ:tên được gán một cách cuc bộ tại một nơi mà các quan hệ được tạo ở đó.Hai đối tượng ở những nơi khác nhau thì có thể có tên

Page 15


cục bộ giống nhau,nhưng hai đối tượng ở cùng một mơi thì không thể có tên cục bộ giống nhau.

Trường vị trí:là nơi nhận biết vị trí mà quan hệ được tạo ở đó và là nơi thông tin được giữ lại về tất cả phân mãnh và nhân bản của quan hệ.

Cả hai trường xác định được một quan hệ là duy nhất,chúng ta gọi là sự kết hợp tên quan hệ tổng thể.Để xác định một nhân bản của một quan hệ,chúng ta lấy tên quan hệ tổng thể và thêm vào trường replica-id, chúng ta gọi là sự kết hợp tên nhân bản tổng thể.

22.9.2 Cấu trúc danh mục

Danh mục hệ thống tập trung có thể được dùng nhưng nơi chứa danh mục có thể sẽ bị hư hại.Cách khác là chúng ta sẽ giữ lại bảng nhân bản của danh mục hệ thống tổng thể nó mô tả tất cả dữ liệu ở mọi nơi.Mặc dù ,dùng cách này sẽ không làm ảnh hưởng đến danh mục hệ thống dù ở nơi đó bị hư hại,nhưng vẫn gặp vấn đề là khó khăn là mỗi lần thay đổi danh mục cục bộ phải phát tán đi khắp nơi.

Cách tốt hơn để làm là,để đảm bảo cho vùng tự trị cục bộ và không làm ảnh hưởng đến từng nơi độc lập đó ,chúng ta sẽ mở rộng ra trong dự án cơ sở dữ liệu phân tán R*,đó là dự án của Systerll R ,ngườ đã thành công ở IBIV.Mỗi nơi sẽ giữ lại một từ điển cục bộ đã mô tả tất cả nhân bản của dữ liệu đã được lưu trữ ở đó.

Thêm vào đó, danh mục ở nơi đã tạo ra một quan hệ thì có nhiệm vụ phải lưu lại vết những nhân bản của quan hệ đã được lưu trữ.Cụ thể là,Mô tả chính xác mỗi nội dung của nhân bản:như liệt kê tất cả cột đối với phân mãnh dọc hay điều kiện để tập hợp lại đối với phân mãnh ngang đã được lưu trữ ở nơi đã tạo ra danh mục.Bất cứ lúc nào nhân bản mới được tạo hay nhân bản bị hủy ở nơi nào đó ,thông tin ở nơi tạo ra danh mục cho quan hệ phải được cập nhật lại.

Để xác định vị trí một quan hệ, danh mục;phải tìm kiếm nơi nào sẽ tạo ra chúng.Thông tin danh mục này có thể bị cache lại ở những nơi khác để truy cập nhanh hơn,nhưng thông tin bị cache lại có thể bị lỗi thời.Ví dụ,một phân mãnh bị huy đi,chúng ta sẽ tìm ra thông tin bị cached mà đã bị lổi thời ,khi truy cập một quan hệ,và tại thời điểm đó,chúng ta phải cập nhật lại cache bằng cách tìm kiếm trong danh mục ở nơi tạo ra nó của một quan hệ nào đó.(Nơi tạo ra của một quan hệ được ghi lại trong mỗi cache cục bộ nơi mô tả quan hệ,và nơi tạo ra sẽ không thay đối ,thậm chí khi quan hệ đó bị hủy đi.

Page 16


22.9.3 Sự độc lập của dữ liệu phân tán

Sự độc lập của cơ sở dữ liệu phân tán có nghĩa là khi người dùng thực hiện câu truy vấn mà không cần quan tâm cách một quan hệ bị phân mãnh hay nhân bản;Mà đó là trách nhiệm của DBMS sẽ thao tác trên quan hệ khi cần (bằng cách xác định vị trí những nhân bản của những phân mãnh một cách thích hợp,kết nối các phân mãnh dọc và lấy ra sự kết hợp của những phân mãnh ngang).

Đặc biệt,trong khi ước lượng một câu truy vấn,người dùng không cần phải biết chi tiết tên của những đối tượng dữ liệu truy cập.Để chúng ta thấy cách mà người dùng có thể truy cập vào những quan hệ mà không cần biết những quan hệ phân tán như thế nào.Tên cục bộ của quan hệ trong danh mục hệ thống thực chất là sự kết hợp của tên người dùng và tên quan hệ định nghĩa người dùng.’

Người dùng có thể lấy bất cứ tên gì trong những quan hệ của họ,mà không cần quan tâm những quan hệ đó được tạo bởi người khác .Khi người dùng viết một chương trình hay câu lệnh SQL mà có tham chiếu đến một quan hệ,thì họ có thể dùng tên quan hệ một cách dễ dàng.DBMS thêm tên người dùng vào một tên quan hệ để lấy tên cục bộ,sau đó thêm vào vị trí id của người dùng như là vị trí tạo ra để lấy tên quan hệ tổng thể.

Bằng cách tra tên quan hệ tổng thể trong danh mục cục bộ nếu nó bị cached tại đó hoặc trong danh mục ở nơi tạo ra,DBMS có thể xác định được những nhân bản của quan hệ.’

Người dùng có thể muốn tạo ra những đối tượng ở nhiều nơi hoặc muốn tham chiếu tới những quan hệ được tạo bởi người khác.Để làm được việc này,người dùng có thể tạo ra một tên đồng nghĩa cho tên quan hệ cục bộ bằng cách dùng kiểu câu lệnh SQL và thông thường tham chiếu đến quan hệ sử dụng tên đồng nghĩa.

Với mỗi người dùng ở một vị trí nào đó,DBMS giữ lại tên đồng nghĩa của bảng như là một phần của danh mục hệ thống ở vị trí đó và dùng bảng này để tìm tên quan hệ tổng thể.Người dùng chạy chương trình sẽ không bị thay đổi thậm chí những nhân bản của quan hệ bị xóa đi,bởi vì tên quan hệ tổng thể không bao giờ đổi cho đến khi quan hệ bị hủy đi.

Page 17


22.10 XỬ LÝ TRUY VẦN PHÂN TÁN:Đầu tiên chúng ta thảo luận về độ phức tạp xảy ra trong các phép toán

quan hệ trong cơ sở dử liệu phân tán qua các ví dụ và pháo thảo sự tối ưu hoá câu truy vấn phân tán. Cho 2 mối quan hệ sau:

Sailors(sid:integer, sname:string, rating:integer, age:real)

Reserver(sid:integer, bid:integer,day: Date, rname: string)

Giả sử mỗi bộ Reserves có chiều dài 40 byte, mỗi page có 100 bộ Reserves, và có 1000 page. Tương tự, giả sử mỗi bộ Sailor có chiều dài 50 byte, mỗi page có 80 Sailor, và có 500 page.Để đánh giá chi phí của các phương pháp, trong điều kiện đếm tổng số page phải bằng với tổng số page gửi từ 1 nơi đến 1 nơi khác bởi vì chi phí truyền thông là 1 thành phần có ý nghĩa quan trong trong toàn bộ chi phí trong 1 cơ sở dữ liệu phân tán. Chúng ta phải thay đổi mô hình chi phí của chúng ta để tính tổng chi phí vận chuyển các bộ kết quả đến nơi mà câu truy vấn được đặt từ 1 nơi mà kết quả được tập hợp lại. Chúng ta qui ước số lần đọc 1 page từ đĩa ( hoặc ghi 1 page xuống đĩa) như là td và số lần vận chuyển 1 page ( từ nơi này đến nơi khác) là ts.

22.10.1 Thực thi Nonjoin trong hệ quản trị cơ sở dữ liệu phân tán:

Các phép toán đơn giản như duyệt mối quan hệ, chọn, và phép chiếu đều bị ảnh hưởng bởi sự phân mảnh và sự tái tạo. Cho câu truy vấn như sau:

SELECT S.age

FROM Sailors S

WHERE S.rating >3 AND S.rating <7

Giả sử mối quan hệ Sailors là phân mảng theo chiều ngang, với tất cả các bộ có rating nhỏ hơn 5 ở Shanghai và tất cả các bộ có rating lớn hơn 5 ở Tokyo.

Hệ quản trị cơ sở dữ liệu phải trả lời các câu truy vấn bằng xem xét nó ở cả 2 nơi và hợp câu trả lời lại. Nếu mệnh đề SELECT chứa AVG(S.age), kết hợp câu trả lời không đơn giản chỉ hợp câu trả lời mà hệ quản trị cơ sở dữ liệu còn phải tính toán tổng và số lượng giá trị age ở cả 2 nơi và sử dụng thông tin để tính toán trung bình age của tất cả Sailors.

Page 18


Nếu mệnh đề WHERE chứa điều kiện S.rating >6 , thì hệ quản trị cơ sở dữ liệu nhận ra câu truy vấn có thể tìm thấy câu trả lời bằng cách chỉ thực thi ở Tokyo.

Một ví dụ khác, giả sử mối quan hệ Sailors được phân mảnh theo chiều dọc, với trường sid và rating ở Shanghai , trường sname và age ở Tokyo. Không có trường nào được lưu trữ ở cả 2 nơi.

Vì vậy, sự phân mảnh theo chiều dọc sẽ giảm mức độ phân tích, ngoại trừ trường chứa ID của bộ Sailor tương ứng. Hệ quản trị cơ sở dữ liệu có thể xây dựng lại mối quan hệ Sailors bằng cách nối 2 phân mảnh dựa trên trường ID của bộ và thực hiện truy vấn trên mối quan hệ tái tạo.

Cuối cùng, giả sử mối quan hệ Sailor liền mảnh được lưu trữ ở cả Shanghai và Tokyo. Chúng có thể trả lời bất kì câu truy vấn nào trước đó bằng các thực thi nó ở cả Shanghai hoặc Tokyo. Vậy nơi nào câu truy vấn sẽ thực thi? Nó phụ thuộc vào chi phí chuyển câu trả lời đến nơi thực thi câu truy vấn( có thể là Shanghai, Tokyo hoặc một nơi nào khác) tốt hơn chi phí thực thi câu truy vấn ở Shanghai và Tokyo- chi phí sử lý cục bộ phụ thuộc khác nhau về chỉ số hợp lệ Sailor.

22.10.2 Thực thi Join trong hệ quản trị cở sở dữ liệu phân tán:

Việc kết các mối quan hệ ở những nơi khác nhau có thể chi phí rất lớn, và bây giờ chúng ta xem xét đánh giá các lựa chọn trong môi trường phân tán. Giả sử mối quan hệ Sailors được lưu trữ ở LonDon và mối quan hệ Reservers được lưu trữ ở Paris. Chúng ta xem xét chi phí cho những phương pháp khác nhau trong việc sử dụng Sailors Reserves:

1. Fetch As Need

Chúng ta có thể làm 1 page- oriented nested loops join ở LonDon với Sailors như xa hơn, và mỗi page Sailors,giữ tất cả page Reserves từ Paris.Nếu chúng ta giữ các page Reserves đã nạp ở LonDon đến khi việc kết hoàn tất, những page được nạp chỉ có một, nhưng page Reserves không được giữ sẽ gặp tình trạng dữ liệu khó lấy( Tình hình sẽ tệ hơn nếu chúng ta sử dụng bộ- oriented nested loops join)

Chí phí là 500 td để duyệt Sailors, với mỗi page Sailors chi phí duyệt tìm kiếm và chi phí vận chuyển tất cả Reserves là 1000(td+ts). Tổng cộng chi phí là 500 td +500,000(td+ts).

Page 19


Trong điều kiện đó, nếu câu truy vấn không đưa ra từ LonDon, chúng ta phải cộng thêm chi phí vận chuyển kết quả đến nơi thực thi; chi phí này phụ thuộc vào kích thước kết quả. Bởi vì sid là khoá của Sailors, tổng số bộ trong kết quả là 100,000( Số bộ trong Reserves) và mỗi bộ kích thước là 40+ 50=90 byte; như vậy 4000/90=44 bộ kết quả trong 1 page, và kích thước kết quả là 100,000/44=2273 page. Chi phí vận chuyển câu trả lời đến nơi khác là 2273 ts. Chúng ta nhận thấy câu truy vấn được đặt ở nơi mà kết quả được tính toán, nếu không thì chi phí vận chuyển kết quả đến nơi truy vấn có thể gia tăng chi phí.

Trong ví dụ này, ta nhận thấy nếu nơi truy vấn không đặt ở LonDon hay Paris, chi phí vận chuyển kết quả sẽ lớn hơn chi phí vận chuyển cả Sailor và Rerserve đến site truy vấn. Vì vậy, nó sẽ có chi phí thấp hơn khi vận chuyển tất cả các mối quan hệ về nơi truy vấn và thực thi kết tại đó.

Một cách chọn lữa, chúng ta có thể có 1 chỉ mục nested loops join ở LonDon, giữ tất cả các bộ Rerverse nối với mỗi bộ Sailors. Giả sử chúng ta có hash index trên cột sid của Rerverses. Bởi vì có 100,000 bộ Rerserves và 40,000 bộ Sailor, mỗi Sailor có trung bình 2.5 Reservation. Chi phí tìm 2.5 Reservation phù hợp với một bộ Sailor là (1.2 +2.5) td. Tổng cộng chi phí là chi phí duyệt Sailor cộng thêm chi phí tìm kiếm và giữ các bộ Rerserves phù hợp với mỗi bộ Sailor: 500td +40,000(3.7 td +2.5 ts).

Tất cả các phương pháp fetch đòi hỏi bộ Reserves từ nơi xa như là sự cần thiết. Hơn nữa, đây là 1 ý kiến không tốt, chi phí vận chuyển các bộ chiếm ưu thế hơn so với tổng chi phí thậm chí có đường mạng tốt.

2. Ship to One Site

Chúng ta có thể vận chuyển Sailor từ LonDon đến Paris và thực hiện kết ở đó, hay vận chuyển Reserves đến LonDon và thực hiện kết ở đó, hay mang cả hai đến một nơi truy vấn được đặt và thực hiện kết tại đó. Chú ý là câu truy vấn được đặt ở LonDon,Paris hay là 1 nơi thứ 3.

Chí phí của việc duyệt và vận chuyển Sailor, lưu nó ở Paris, và sau đó thực hiện phép kết ở Paris là 500(2td +ts) +4500 td, .

Chi phí vận chuyển Reserves và thực hiện phép kết ở LonDon là 1000(2t(1-t-ts)

+ 4500td

3. Senmijoins and Bloomjoins

Page 20


Giả sử chiến lược vận chuyển Reserves đến LonDon và thực thi kết ở LonDon. Một số bộ trong Reserves không kết với bất kì bộ nào trong Sailors. Nếu chúng ta bằng cách nào đó nhận ra bộ Reserves đảm bào không kết với bất kỳ bộ nào của Sailor, Chúng ta có thể tránh vận chuyển chúng.

2 kĩ thuật Semijoin và Bloomjoin được đề xuất cho việc giảm bớt số lượng bộ Reserves được vận chuyển. Kỉ thuật đầu tiên được gọi là Semijoin. Ý tưởng là xử lý theo 3 bước:

a) Tại LonDon, thực hiện phép chiếu Sailor dựa trên cột kết ( trong 1 số trường hợp là trường sid) và vận chuyển sự chiếu này đến Paris.

b) Tại Paris, thực hiện kết tự nhiên của phép chiếu nhận được từ nơi đầu tiên với mối quan hệ Reserves. Kết quả của phép kết này được gọi là Reduction of Reserves với chi tiết đến Sailor. Rõ hơn, chỉ những bộ Reserves đó trong Reduction sẽ kết với các bộ trong mối quan hệ relation. Vì vậy, vận chuyển Reducion of Reserves đến LonDon, đúng hơn là toàn bộ mối quan hệ Reserves.

c) Tại LonDon, thực hiện kết Reduction of Reserves với Sailors.

Chúng ta bắt đầu tính chi phí cho việc sử dụng kĩ thuật này trong ví dụ tru vấn kết. Giả sử chúng ta có sự thực thi đầy đủ, đúng đắn của phép chiếu cơ sở trong lần duyệt Sailor đầu tiên và tạo ra mối quan hệ tạm thời với các bộ chỉ có trường sid và sau đó sắp xếp mối quan hệ tạm thời và duyệt trên mối quan hệ tạm thời đó để loại bỏ những sự trùng lắp. Nếu chúng ta cho là kích thước trường sid là 10 byte , chi phí của phép chiếu là 500 td cho việc duyệt Sailor , cộng thêm 100 td cho việc tạo mối quan hệ tạm, cộng thêm 400 td cho việc sắp xếp nó , cộng theo 100 td cho duyệt lần cuối, cộng thêm 100 td cho việc viết kết quả vào mối quan hệ tạm thời; tổng cộng là 1200 td.( Bởi vì sid là khoá, không có sự trùng lắp nên không cần loại ra, nếu lựa chọn tốt thì chi phí của phép chiếu chỉ còn (500 +100) td).

Chi phí của việc thực hiện phép chiếu và vận chuyển đến Paris là 1200 td +100ts. Chi phí thực hiện của Reduction of Reserves là 3(100+10)10=3300 td.

Kích thước của Reduction là bao nhiêu? Nếu mỗi Sailor nắm giữ it nhất một Reservation, Reduction bao gồm mỗi bộ của Reserver! Những nổ lực trong việc vận chuyển phép chiếu và giảm Reserver là hoàn toàn lãng phí. Thực vậy, bởi vì qua quan sát, chúng ta chú ý thấy Semijoin là đặc biệt hữu dụng trong sự liên kết với việc chọn một trong các mối quan hệ. Ví dụ, nếu chúng ta muốn thực thi phép kết giữa các bộ Sailor với rating lớn hơn 8 với mối quan hệ Reserves , kích thước của phép chiếu trên sid cho các bộ mà thoả mản chọn lựa sẽ 20 % của phép chiếu gốc, thường là 20 page.

Page 21


Giả sử rằng chúng ta có thêm phép chọn trên rating ( Chi phí thực thi phép chiếu của Sailor sẽ giảm đi 1 ít, chi phí cho việc vận chuyển nó giảm đi 20 ts, và chi phí của Reduction of Reserves giảm đi 1 ít, nhưng bỏ qua Reduction cho đơn giản). Chúng ta cho rằng chỉ 20% bộ Reserves được tính đến trong Reduction.Do đó, Reduction chứa 200 page và chi phí vận chuyển nó là 200ts.

Cuối cùng, ở LonDon, Reduction of Reserves được kết với Sailor, với chi phí là 3(200+500)=2100 td. Theo quan sát thì sử dụng kĩ thuật kết này co 6500 page I/Os cùng với 200 page vận chuyển. Ngược lại, để vận chuyển Reserves đến LonDon và thực hiện phép kết là 1000 ts + 4500td. Với tốc độ mạng cao, chi phí Semijoin có thể nhiều hơn chi phí vận chuyển toàn bộ Reserves, thậm chí chí phí vận chuyển, nó vẫn thấp hơn(200 ts v.s 1000 ts).

Kĩ thuật thứ 2 tương tự được gọi là Bloomjoin. Sự khác biệt chính đó là trong bước đầu tiên thì một bit-vector được vận chuyển thay vì phần chiếu của Sailors. Một bit-vector của kích thước k được tính toán bằng cách hash mỗi bộ Sailor vào trong 1 vùng giá trị từ 0 đến k-I và cài đặt bit i bằng I nếu một số bộ nào đó hash ra i và ngược lại là 0. Ở bước 2, Reduction of Reserves được tính toán bằng cách hash mỗi bộ Reserves( sử dụng sid) vào vùng từ 0 đến k-1, sử dụng hàm hash tương tự đề xây dựng bit-vector và loại bỏ những bộ mà giá trị hash I tương ứng là bit 0. Bởi vì không một bộ Sailor nào hash ra i, không một bộ Sailor nào có thể kết với bất kì bộ Reserves nên không thể giảm bớt bộ.

Chi phí vận chuyễn 1 bit-vector và chi phí giảm bớt Reserves sử dụng vector thấp hơn chi phí tương ứng trong phương pháp Semijoin. Mặt khác, kích thước của Reduction of Reserves có thể lớn hơn trong Semijoin; vì vậy chi phí vận chuyển Reduction và kết với Sailor có thể cao hơn.

Chúng ta bắt đầu tính chi phí của phương pháp này.Chi phí thực hiện bit-vector chủ yếu là chi phí duyệt Sailor, nó khoảng 500 td. Chi phí của việc gửi bit-vector phụ thuộc vào kích thước chúng ta chọn bit-vector,nó thường nhỏ hơn kích thước của bản chiếu, cụ thể chúng ta lấy chi phí là 201. Chi phí của việc tạo ra bản Reserves rút gọn là chi phí duyệt Reserves là 1000 td. Kích thước của Reduction of Reserves thường giống hoặc lớn hơn 1 chút so với kích thước của Reduction trong Semijoin, thay vì 200 chúng ta lấy kích thước là 220 page. Chi phí vận chuyển Reduction là 220 ts. Chi phí cuối cùng của việc kết ở LonDon là 3(500+220)=2160 td.

Do đó, so sánh với Semijoin, chi phí vận chuyển của phương pháp này giống nhau, mặc dù nó cao hơn nếu như bit-vector là không chọn lọc bản chiếu Sailors trong điều kiện của Reducing Reserves. Tiêu biểu, Reduction of Reserves không lớn hơn 10 đến 20% so với kích thước của Reduction of Reserves trong Semijoin. Đổi lại với chi phí vận chuyển cao hơn không đáng kể

Page 22


thì Bloomjoin giành được chi phí xử lý thấp hơn 1 cách đáng kể. Thực vậy, Bloomjoin có chi phí I/O thấp hơn và chi phi vận chuyển thấp hơn sơ với phương pháp vận chuyển tất cả Reserves về LonDon.

22.10.3 Tối ưu chi phí cơ bản câu truy vấn:Chúng ta đã biết bằng cách nào mà dữ liệu phân tán có thể tác động

đến việc thực thi các phép toán riêng lẻ như là chọn, chiếu, hợp, hoặc là kết. Tất nhiên là một câu truy vấn liên quan đến một số phép toán và việc tối ưu hoá câu truy vấn trong cơ sở dữ liệu phân tán đặt ra những thách thức sau:

Chi phí truyền thông phải được tính đến. Nếu chúng ta có 1 số bản copy của các mối quan hệ , chúng ta phải giải quyết vấn đề sao chép để sử dụng.

Nếu những nơi riêng lẻ chạy dưới sự điều khiển của những hệ quản trị cơ sở dữ liệu khác nhau, thì kĩ thuật cho mỗi nơi phải chú trọng trong khi thực thi các kế hoạch truy vấn toàn cục.

Tối ưu câu truy vấn xử lý cơ bản như một hê quản trị cơ sở dữ liệu tập trung với các thông tin về mối quan hệ ở một nơi xa chứa từ hệ thống catalogs.

Trong kế hoạch tổng thể , thao tác cục bộ của mối quan hệ ở nơi mà chúng lưu trữ được gói gọn trong một kế hoạch đề nghị cục bộ. Kế hoạch tổng thể bao gồm một số kế hoạch cục bộ mà chúng ta có thể nghĩ là nó thực thi truy vấn thay thế ở một nơi khác. Trong khi tạo ra kế hoạch tổng thể, các kế hoạch đề nghị cục bộ hiện thực chi phí ước lượng cho mối quan hệ trung gian; kế hoạch đề nghị cục bộ được xây dựng bởi phần lớn những người lạc quan để cung cấp chi phí ước lượng cục bộ. Một nơi có thể tự bỏ những kế hoạch cục bộ nếu nó tìm một kế hoạch rẻ hơn bằng những thông tin hiện tại trong catalog cục bộ.

22.11 CẬP NHẬT DỮ LIỆU PHÂN TÁNTheo quan điểm cổ điển của hệ quản trị cơ sở dữ liệu phân tán thì giống

như hệ quản trị cơ sở dữ liệu tập trung dưới cách nhìn của người dùng,sự phân tán của dữ liệu thì trong suốt với người dùng.

Mặt khác đối với câu truy vấn,theo quan điểm của hệ quản trị cơ sở dữ liệu phân tán thì người dùng có thể đưa yêu cầu bằng câu truy vấn mà không cần biết cách và nơi mà những quan hệ được lưu trữ;chúng ta đã có sẵn những mối lien quan của yêu cầu này trên định lượng câu truy vấn

Page 23


Về khía cạnh cập nhật,được hiểu như là:những giao tác nên tiếp tục thực hiện các tiến trình con bên trong,mà không cần quan tâm sự nhân bản và phân mảnh dữ liệu.Cụ thể là,tất cả bản sao của quan hệ đã bị sửa đổi phải được cập nhật trước khi giao tác hoàn tất.Chúng ta xem nhân bản theo ngữ nghĩa như là nhân bản đồng thời;trước khi giao tác cập nhật hoàn tất,nó xảy ra đồng thời với tất cả bản sao của dữ liệu đã sửa đổi.

Cách tiếp cận khác đến bản sao là nhân bản đồng thời,được sử dụng rộng rãi trong hệ quản trị cơ sở dữ liệu phân tán.Các bản sao của một quan hệ đã bị sửa đổi chỉ được cập nhật một cách định kỳ,và một giao tác sẽ xem dự đoán khác nhau những bản sao của quan hệ cùng tên để có thể tìm thấy những giá trị khác nhau.Vì vậy,sao chép đồng thời sẽ sắp xếp sự độc lập dữ liệu phân tán.

22.11.1 Nhân bản đồng thờiCó hai phương pháp để đảm bảo rằng : giao tác thấy được giá trị giống

nhau mà không cần quan tâm bản sao nào của một đối tượng nào đó mà ta muốn truy cập vào.

Cách thứ nhất:được gọi là sự bầu chọn,một giao tác phải chép lại phần lớn của những bản sao của một đối tượng đã thay đổi.Ví dụ,nếu chúng ta có 10 bản sao và có 7 bản được ghi chép bởi những giao tác cập nhật,sao đó có tối thiểu 4 bản sao phải được đọc.Mỗi bản sao đều có số version và bản sao nào có số version cao nhất là đang dùng hiện hành.Dùng phương pháp này thì không hiệu quả cao,bởi vì mỗi lần muốn đọc một đối tượng đòi hỏi phải đọc những bản sao phức tạp.Phần lớn trong ứng dụng,những đối tượng được đọc một cách thường xuyên hơn là nó được cập nhật.

Trong phương pháp thứ hai, được gọi là read-any write-all,để đọc một đối tượng ,một giao tác có thể đọc bất kỳ một bản sao nào,nhưng để ghi chép một đối tượng,nó phải được ghi trên tất cả bản sao.Đọc rất là nhanh,đặc biệt là bản sao cục bộ,nhưng ghi chép chậm hơn giống với phương pháp thứ nhất.Với phương pháp này thì hiệu quả hơn cách làm trước ,vì thao tác đọc thì được thực hiện thường xuyên hơn ghi.

22.11.2 Sự nhân bản không đồng thờiĐiều quan trọng trong nhân bản không đồng thời là chi phí.Trước khi

một giao tác cập nhật hoàn tất,nó phải dành được quyền lock trên tất cả bản sao,ta sẽ dùng phương pháp read-any write-all cho dữ liệu đã sửa đổi.Giao tác có thể gửi đi yêu cầu lock đến những vị trí khác và đợi ban lệnh lock và trong thời gian này ,nó vẫn tiếp tục giữ các lệnh lock khác.Nếu vị trí hay đường

Page 24


truyền giao tiếp bị thất bại ,giao tác không thể hoàn tất cho đến khi tất cả vị trí mà ở đó các dữ liệu bị sửa đổi phục hồi lại được .Cuối cùng,thậm chí nếu như giành được lệnh lock và không có thất bại gì,một giao tác hoàn tất còn đòi hỏi phải có các thông báo thêm vào để gửi đi giống như một thành phần của một giao thức đã hoàn tất.

Vì những lý do này ,mà nhân bản đồng thời không được dùng thường .Nhân bản không đồng thời thì được dùng thường xuyên,mặc dù nó cho phép các bản sao khác nhau của cùng đối tượng được gán các giá trị khác nhau trong một thời gian ngắn.Với cách làm này làm vi phạm nguyên tắc của sự độc lập của dữ liệu phân tán;người dùng phải biết được bản sao nào mà mình muốn truy cập,và sẽ làm giảm đi mức độ nhất quán của dữ liệu.Tuy nhiên ,cách này vẫn chấp nhận được.

So sánh Primary Site và Peer-to-Peer Replication.

Trong nhân bản không đồng thời nơi trọng tâm,một bản sao của một quan hệ có thể được xác định là chính yếu.Những phân mãnh của quan hệ có thể được tạo ở những nơi khác,những bản sao này là bản sao thứ hay không giống như bản sao chính,chúng sẽ không được cập nhật.Để thiết lập bản sao chính và bản sao phụ,người dùng trước tiên phải đăng ký hay publish quan hệ ở nơi chính yếu và sau đó ,mô tả sự phân mãnh của quan hệ đã được đăng ký từ nơi khác.

Trong nhân bản không đồng thời ở nơi peer-to-peer, nhiều bản sao của một quan hệ có thể được xác định là chính yếu.Thêm vào đó là những thay đổi lan truyền,sự giải quyết xung đột được dùng để đối phó với những thay đổi xung đột ở nhiều nơi.Ví dụ,tuổi của Joe có thể thay đổi thành 35 tuổi ở nơi nào đó và 38 tuổi ở nơi khác.Vậy giá trị nào đúng?Nhiều loại xung đột khó thấy có thể xuất hiện trong nhân bản peer-to-peer.Trong những trường hợp đặc biệt này thì nhân bản peer-to-peer sẽ hạn chế những xung đột xuất hiện thường xuyên,trong tình huống này nhân bản peer-to-peer là tiện lợi nhất.

Sự thực thi Nhân bản không đồng thời ở vị trí chinh

Ý nghĩa của sự thực thi nhân bản không đồng thời ở vị trí chính là xác định cách thay đổi từ nhân bản chính truyền lại cho những nhân bản phụ.Những thay đổi này thì được truyền lại trong hai bước,gọi là Capture và Apply.

Capture:

Page 25


Bước capture được thực thi dùng 1 trong hai cách tiếp cận.Trong capture log-based,mục đích phục hồi được dùng để sinh ra những cập nhật của record.Về cơ bản ,khi phần cuối log được ghi chép vào bộ nhớ chính,tất cả record log cũng ảnh hưởng đến những quan hệ nhân bản cũng được ghi chép đến bảng dữ liệu thay đổi riêng lẻ.Khi giao tác phát sinh ra log recored cập nhật người dùng có thể vẫn còn hiệu lực khi record được ghi chép đến CDT,rồi sau đó bị abort.

Trong capture theo thủ tục,thủ tục được gọi lên một cách tự động bởi DBMS hay chương trình ứng dụng bắt đầu từ tiến trình Capture.Thủ tục được gọi lên một cách tự động bởi DBMS,giống như nó bắt đầu Capture,được gọi là một trigger.

Capture Log-based là tầng thấp hơn Capture theo thủ tục,lý do nó được tạo ra là do sự thay đổi của dữ liệu.dẫn đến kết quả làm chậm trễ giửa thời gian bản sao chính bị thay đổi và thời gian thay đổi truyền đi cho những bản sao phụ.Cụ thể là,chỉ có những thay đổi được truyền đi và những thay đổi có lien quan được truyền đi cho nhau.Sự bất lợi của việc thực hiện Capture log-based là đòi hỏi phải hiểu chi tiết của cấu trúc log.

Apply:

Bước Apply là đi lấy những thay đổi từ bước Capture,nó nằm trong bảng CDT hay snapshot,và truyền đi cho những bản sao phụ.Có thể làm được điều này bởi có vị trí chính gửi đi một cách lien tục cho CDT hay CDT yêu cầu thao định lỳ hay snapshot từ vị trí chính.Điển hình,mỗi vị trí phụ thực thi bảng sao của tiến trình ứng dụng và đẩy các thay đổi vào eDT từ vị trí chính.Khoảng cách giữa các yêu cầu có thể điều khiển bởi timer hay chương trình ứng dụng của người dùng.Một khi những thay đổi có sẵn ở vị trí phụ ,nó có thể được ứng dụng một cách trực tiếp đến nhân bản.

Capture lag-based kết hợp với Apply sẽ làm hạn chế mức độ trì hoãn những thay đổi được truyền đi.Đây là cách kết hợp tốt nhất trong trường hợp này cả những bản sao chính và phụ như là thành phần của hệ quản trị cơ sở dữ liệu và những nhân bản phải xảy ra đồng thời với bản sao chính . Log-based Capture kết hợp với Apply làm giảm được chi phí thay thế cho nhân bản đồng thời.

Sắp xếp dữ liệu:ví dụ của nhân bản.

Một câu truy vấn phức tạp :muốn truy xuất dữ liệu ở nhiều nơi là điều rất quan trọng.Có một cách sẽ giúp cho câu truy vấn phức tạp muốn lấy dữ liệu từ nhiều nguồn là tạo ra bản sao của tất cả dữ liệu ở cùng một nơi và sử dụng

Page 26


các bản sao này tốt hơn là truy xuất từ các nguồn khác nhau.Lúc này bản sao được truy xuất như là một dữ liệu.

Kho dữ liệu có thể được coi là một ví dụ của nhân bản không đồng thời.

22. 12 GIAO TÁC PHÂN TÁN:-Trong 1 hệ quản trị cơ sở dữ liệu phân tán, một giao tác xác định được đưa ra ở một nơi, nhưng nó có thể chấp nhận dữ liệu ở một nơi khác tốt. Hoạt động của giao tác ở một nơi xác định như là một giao tác thay thế. Khi một giao tác được đưa ra ở một số nơi, quản lý giao tác tại nơi đó làm gãy nó vào 1 bộ của một hoặc nhiều giao tác để thực thi ở một nơi khác, đưa chúng đến quản lý giao tác ở một nơi khác, và sắp xếp các hoạt động.

-Bề ngoài của điều khiển đồng thời và phục hồi đòi hỏi chú ý nhiều hơn bởi vì dữ liệu phân tán. Có nhiều nghi thức xử lý đồng thời như Strict 2PL với sự dò tìm deadlock được sử dụng. Chúng ta thảo luận 2 phần sau:

Distributed Concurency Control.

Distributed Recovery.

22.13 ĐIỀU KHIỂN ĐỒNG THỜI ĐƯỢC PHÂN TÁN

-Trong hệ thống cơ sở dữ liệu và xử lý giao dịch phân phối concurrency kiểm soát chủ yếu liên quan đến concurrency kiểm soát của một cơ sở dữ liệu phân tán. Nó cũng liên quan đến việc kiểm soát concurrency trong một môi trường multidatabase (cơ sở dữ liệu liên; xem concurrency kiểm soát toàn cầu). Một mục tiêu lớn cho concurrency phân phối kiểm soát được serializability (hoặc toàn cầu serializability cho multidatabase hệ thống). Concurrency đe phân phối kiểm soát đặc biệt tập trung một trong những thách thức ngoài, chủ yếu là do giao tiếp và máy vi tính trễ. Nó thường đòi hỏi kỹ thuật đặc biệt, như quản lý phân phối khóa máy tính nhanh hơn với các mạng lưới trễ thấp, như dệt may chuyển (ví dụ như, InfiniBand).

-Phổ biến nhất được phân phối concurrency mạnh là kỹ thuật kiểm soát nghiêm ngặt hai giai đoạn khóa (SS2PL, cũng được đặt tên rigorousness), đó cũng là một trung tâm phổ biến kỹ thuật kiểm soát concurrency. SS2PL cung cấp cho cả serializability, strictness, và cam kết tài sản sắp đặt. Strictness, một trường hợp đặc biệt recoverability, được sử dụng có hiệu quả để phục hồi từ thất bại, và cam kết sắp đặt cho phép tham gia vào một giải pháp chung cho toàn cầu serializability. Đối với quy mô lớn và phức tạp phân phối các giao dịch, phân phối khóa điển hình của hình phạt nặng hiệu quả (do sự chậm trễ, trễ) có thể được lưu lại bằng cách sử dụng các cam kết atomic thức (ví dụ như, 2PC, hoặc

Page 27


đơn giản là một trong một hệ thống đáng tin cậy) cùng với các cam kết của địa phương sắp đặt ( ví dụ như, địa phương SS2PL) thay vì phân phối khóa, để đạt được toàn cầu serializability trong toàn bộ hệ thống. Các kỹ thuật có thể được sử dụng cho một quy mô lớn song song cơ sở dữ liệu, nơi một cơ sở dữ liệu lớn, ở trên nhiều nodes phân phối và sử dụng một khóa quản lý, được thay thế bằng một (đồng nhất) multidatabase, bao gồm rất nhiều cơ sở dữ liệu tương đối nhỏ, lắp vào mỗi một node, cùng với một số đơn giản atomic cam kết giao thức (không có khóa bằng cách sử dụng phân phối quản lý).

- Trong phần 22.11.1, chúng ta đã mô tả kỹ thuật TWO cho công cụ đồng bộ mô hình, và trong 22.11.2, chúng ta thảo luận các kỹ thuật khác nhau cho công cụ đồng bộ mô hình. chọn kỹ thuật xác định các đối tượng đã bị khoá. Khi các

Page 28


khoá giành được để giải phóng được xác định bằng nghi thức kiểm soát trùng hợp. Chúng ta nghĩ lại cách yêu cầu khoá và mở khoá được đồng bộ trong điều kiện được phân bố theo kiểu nào đó.

-Quản lý các khoá có thể được phân bố theo các vị trí trong nhiều cách:

Chịu sự kiểm soát: một số các ví trí đơn giản phụ trách một handle yêu cầu khoá vá không khoá cho tất cả các đối tượng.

Primary Copy: là một loại sao chép mỗi đối tượng khác nhau được chỉ định là sao chép chính. Tất cả các yêu cầu để khoá hay mở khoá một lần sao chép của một đối tượng đó được xác định bởi người quản lý khoá ở các vị trí nơi sao chép khoá chính được lưu trữ, không chú ý tới vị trí sao chép chính nó được lưu trữ.

Phân phối toàn vẹn: Các yêu cầu mở hay đống khoá một sao chép của một đối tượng lưu trữ ở các vị trí được xác định bởi người quản lý khóa ở vị trí sao chép nơi mà việc sao chép được lưu trữ.

-Lược đồ tập trung là chổ dễ bị lỗi dẫn đến sai lệt ở các vị trí đơn giản đó là các khoá điều khiển. Việc sao chép chính lược đồ tránh xa vấn đề đó, nhưng tổng quát, việc đọc một đối tượng phụ thuộc sự truyền đạt thông tin với các vị trị TWO: Vị trí là nơi mà việc sao chép chính cư trú và vị trí là nơi mà việc sao chép để đọc các cư trú. Vấn đề nay được tránh trong phân phối toàn vẹn, bởi vì việc khoá đước làm ở các vị trí sao chép được đọc tập trung. Tuy nhiên, trong lúc đang viết, các khoá có thể được thiết lập ở tất cả các vị trí sao chép được xác định trong mô hình phân phối toàn vẹn, nơi mà các khoá cần được thiết lập duy nhất ở một vị trí trong mô hình khác hai.

-Rõ hơn, mô hình khoá phân phối toàn vẹn là mô hình 1110 thu hút nếu các việc đọc là nhiều hơn việc ghi, khi thường xảy ra.

22.13.1 Phân bố deadlock

-Một sự phát ra đó là các phụ thuộc đặc biệt khi việc dùng cả kỹ thuật sao chép chính hoặc việc phân bố khoá toàn vẹn bị nhận ra là deadlock. (tất nhiên, mô hình để ngăn deadlock có thể được sử dụng thay thế, tuy nhiên chúng ta tập chung ở các vị trí deadlock, được dùng nhiều.) Khi trong một DBMS tập trung, deadlock sẽ được xác định và giải quyết (bằng cách bỏ ngang một số transaction bế tắt).

-Mỗi vị trí duy trì một vùng chờ cho mạch, và một chu kỳ trong vùng mạch ra dấu một deadlock. Tuy nhiên, đó có thể là một trường hợp deadlock nếu không

Page 29


có vùng mạch chứa một chu kỳ. Ví dụ, giả sử có hai vị trí, A và B, cả hai chứa các sao chép đối tượng 01 và 02, và đó là tất cả kỷ thuật read-any write được dùng. T1 muốn đọc 01 và ghi 02, giành được một khoá S trên 01 và một khoá X trên 02 ở Site A, khi các yêu cầu khoá X trên 02 ở Site B. T2, muốn đọc 02 và ghi 01, trong lúc đó, yêu cầu khoá S trên 02 và một khoá X trên 01 ở Site B, khi yêu cầu một khoá X trên 01 ở Site A như hình 22.5, T2 đang chờ T1 ở Site A, và T1 đang chờ T2 ở Site B. Như vậy, chúng ta có một deadlock, trong cả hai site có thể xác định đơn giản chỉ có trên mỗi vị trí chờ cho một đồ thị.

-Để xác định vị trí deadlocks, một phân phối thuật toán xác định deadlock sẽ được dùng, chúng ta sẽ mô tả 3 thuật toán, thuật toán đầu tiên. với cách tập trung, gồm có việc gửi định kỳ 10-cal chờ các mạch để một site có nghĩa vụ cho việc xác định toàn bộ deadlock. Ở site đó, toàn bộ các mạch chờ được phát sinh bởi các cột của tất cả các mạch cục bộ; thiết lập các nút là sự kết hợp của các nút trong các mạch cục bộ, và đó là một cạnh từ một nút đến các nút khác nếu đó như là một cạnh trong một số các mạch cục bộ.

-Thuật toán thứ hai, là thứ bậc, gôm nhóm các site vào một thứ bậc. Ví dụ, các site bên phải được gôm bởi trạng thái, khi đó bởi vùng, và cuối cùng vào trong các nhóm riêng lẽ đó chứa tất cả các site. Với mỗi node trong thứ bậc này đặt một mạch chờ đó là để lộ ra deadlock gồm duy nhất các site chứa trong node. Tất cả các site một cách định kỳ (như mỗi 10 giây) gửi tới vùng các mạch chờ để site đặt một mạch chờ cho vùng đó. Các site đặt mạch chờ ở vùng mức định kỳ (mỗi lần 10 phút) gửi tới các vùng mạch chờ đến các site đặt chung các mạch chờ. Đó là lược đồ cơ bản theo sự quan sát đó là …. Deadlock là giống như từ vị trí close có liên quan site này đến vị trí không có liên quan của site khác, và nó đặt … cố gắng bên trong vị trí deadlock từ vị trí này đến vị trí khác

Page 30


trong các site. Tất cả deadlock là thực sự tìm thấy, nhưng một deadlock bao gồm 2vùng khác nhau có thể lấy trong khoảng thời gian dò tìm.

-Thuật toán thứ ba là đơng giản: nếu một transaction chờ lâu hơn khoảng thời gian, nó bị bỏ ngang. Thông qua thuật toán này có thể không cần thiết phải bắt đầu lại, ở trên của deadlock dò ra là chậm (rõ ràng), và trong một cơ sở dữ liệu phức tạp phân phối nếu các site tham gia không thể … đến phạm vị của việc chia sẽ các mạch chờ, nó có thể là cách đều chỉnh duy nhất. Một vị trí phức tạp đến các ghi chú với khía cạnh để phân phối các vị trí deadlock là việc từ chối trong thông tin chương trình vùng có thể là nguyên nhân xảy ra deadlock để không cần bỏ ngang. Cụ thể, chúng ta sẽ thảo luận thuật toán cụ thể này, thông qua thuật toán có thứ bâc này thông qua từ các vấn đề tương tự.

-Nghĩ về một nhận định của các ví dụ trước. Như trước, hai transaction chờ các transaction khác, phát sinh các vùng chờ thể hiện trong ảnh 22.5, và các vùng mạch chờ được gửi đến site các vùng deadlock chung. Tuy nhiên, T2 được bỏ ngang vì lý do deadlock. (ví dụ T2 cũng thực thi ở vùng site 3, nơi đó là read một giá trị dữ liệu đột ngột và quyết định để bỏ ngang.) ở vị trí này, vùng mạch chờ đã được thay đổi như là đó là không có chu kỳ trong một vùng mạch chờ toàn cục thực sự. Tuy nhiên, đặt các mạch chờ toàn cục sẽ chứa các chu kỳ, và T1 có thể lựa chọn như một nạn nhân!

22.14 KHÔI PHỤC LẠI DỮ LIỆU PHÂN TÁN -Việc khôi phục lại trong một DBMS được phân bố là phức tạp hơn trong một DBMS kiểm soát tập được do các lý do sau: những nhóm mới của cố gắng thất bại có thể phát sinh: Cố gắng thất bại của các link liên lạc và cố gắng thất bại của một site từ xa là cái mà một transaction bên dưới đang thực thị. Tất cả các transaction bên dưới của một transaction danh sách phạm vi hay không có, và đặc tính này sẽ là được đảm bảo dù truyền đạt các site và các liên kết cố gắng nhưng thất bại. Đấy là sự bảo đảm được kích hoạt sử dụng các phương thức an toàn.

-Trong khi một DBMS chính, thực hiên thao tác chính bị đem theo ra khi phần thực thi bình thường để cung cấp thông tin cần thiết để khôi phục từ các các sự không thực hiện. Một log là chứa các mỗi site chính, và thêm vào đó là các thông chính khác nhau trong một DBMS chính thực hiên lấy các phần của thao tác trao đổi cũng sẽ được log. Cách dùng phương thức này được gọi là TWO-PHASE COMMIT(2PC) . Một biến thể được gọi là 2PC với Presumed Abort, ta sẽ thảo luận ở phần sau.

-Trong phần này, chúng ta sẽ giới thiệu các bước thực hiện binh thường, Cố gắng theo phương thức commit, và thảo luận việc khôi phục lại một sự cố.

Page 31


22.14.1 Normal Execution and Commit Protocols-Trong lúc thực thi, mội một site chính, và các hành động của một transaction khá được ghi ở site nới đó nó thực thi. Bình thường ghi các phân phối hành động trong chương 18 được mang ra và, thêm vào đó, các phương thức commit được theo chắc chắn đó là tất cả các transaction bên dưới của một transaction được chuyển cho hoặc bỏ ngang giống nhau. Quản lý một transaction ở một site nới bắt đầu transaction được gọi là coordinator cho transaction; quản lý transaction ở các site nới mà các transaction khác được thực thi được gọi là subordinate

-Bây giờ chúng ta mô tả protocol Two-Phase Commit (2 PC), trong phạm vi các message được trao đổi và log record được ghi. Khi người dùng quyết định commit 1 transaction, lệnh commit sẽ được gửi tới coordinator . Điều này khởi động 2PC protocol:

1. Một coordinator gửi một thông điệp chuẩn bị đến mỗi thuộc cấp.

2. Khi một thuộc cấp có một thông điệp chuẩn bị, nhận nó ở các quyết định để bỏ ngang hoặc chuyển sang các transaction khac. Nó ghi mạnh hơn bỏ ngang hoặc chuẩn bị khôi phục lại đầu đọc. và khi gửi đến thông điệp no và yes đến coordinator. Ghi chú đó là một đầu đọc chuẩn bị khôi phục không được dùng trong DBMS chính; nó là duy nhất để phương thức phân phối trao đổi.

3. Nếu coordinator nhận thông điệp yes từ tất cả cấp dưới, nó force-writes một lỗi đọc và khi đó gửi đến một thông điệp đến tất cả các cấp dưới, nếu nó nhận được một sự kiện không phải là thông điệp hoặc nhận sự trả lời là no từ tất cả cấp dưới cho một khoảng thời gian chính xác, nó force-writes và abort đầu đọc đó, và khi đó sẽ gửi một thông điệp abort đến tất cả cấp dưới.

4. Khi một cấp dưới nhận một thông điệp abort, nó force-writes một abort đầu đọc, gửi một thông điệp yêu cầu từ coordinator, và abort một transaction ẩn. Khi một cấp dưới nhận thông điệp commit, nó force-writes commit một đầu đọc, gửi đến một thông điệp yêu cầu đến coordinator, và commit transaction đó

5. Sau khi coordinator đã nhận một thông điệp ask từ tất cả cấp dưới, nó sẽ ghi và kết thúc đầu đọc cho transaction.

-Tên two-phase commit phản chiếu sự kiện theo 2 vòng của thông điệp được thay đổi, đầu tiên là voting phase, khi …. Phase cả hai bắt đầu bởi coordinator. Nguồn gốc cơ bản là đa số các transaction thêm vào coordinator

Page 32


có thể đơn phương abort một transaction, ngược lại sẽ thông nhất để commit một transaction, khi một thông điệp trong 2PC, nó tín hiệu một quyết định bởi người gửi. Để chắc chắn quyết định đó tiếp tục một phá huỷ từ site của người gửi, đầu đọc sẽ mô tả quyết định là luôn luôn gượng ép để vững chắc trước khi gửi đi.

-Một transaction luôn được commit ở thời gian của một đầu đọc coordinator trong một kho vững chắc. Các thất bại xảy ra sau không thể ảnh hưởng đến các transaction sẽ đến, nó commit một đầu ghi để ghi một hành động commit chứa dạng đầu đọc, một id của transaction, và thông nhất của coordination, coordinator được commit hoặc abort đầu đọc cùng chứa nhận dạng của các cấp dưới.

22.14.2 Restart after a Failure-Khi một site khôi phục lại sau khi bị huỷ, chúng ta gọi một tiến trình khôi phục lại để đọc và xử lý tất cả các transaction phương thức commit tại thời điểm huỷ. người quản lý transaction ở site này sẽ được là coordinator cho Soule của các transaction và một cấp dười cho các transaction khác. Chúng ta sẽ làm theo trong tiến trình khôi phục:

Nếu chúng ta có một commit hoặc abort một đầu đọc cho transaction T, nó có dạng là xoá, chúng ta sẽ redo hoặc undo tách biệt T. Nếu site này là coordinator, nó có thể được xác định từ commit hoặc abort một đầu đọc, chúng ta sẽ định kỳ gửi lại bởi vì nó có thể là các liên kết khác hay các site failures trong một hệ thống một thông điệp commit hay abort đến cấp dưới trước đó chúng ta sẽ nhận một ack. Sauk hi chúng ta được nhận ack từ tất cả các cấp dưới, chúng tag hi một đầu đọc kết thúc cho T.

Nếu chúng ta có một đầu đọc chuẩn bị cho T nhưng không được commit hoặc abort một đầu đọc, đấy là site là một cấp dưới, và coordinator có thể xác định từ một đầu đọc, chúng ta sẽ lặp đi lặp lại liên tục một site coordinator để chuẩn bị tình trạng của T. Lần đầu coordinator trả lời commit hoặc abort, chúng ta ghi một đầu đọc tương tự, redo hoặc undo một transaction, và khi đó ghi một đầu đọc kết thúc T.

Nếu chúng ta không chuẩn bị đầu đọc commit hoặc abort cho transaction, phân chính của T có thể không được chọn để commit trước khi huỷ, vậy chúng ta có thể đơn phương abort và undo T và ghi một đầu đọc kết thúc. Trong trường hợp này, chúng ta không có cách để xác định được site hiện tại là coordinator hay một cấp dưới cho T. Tuy nhiên, nếu site này là coordinator, nó sẽ được gửi một thông điệp chuẩn bị ưu tiên cho việt huỷ, và nếu vậy, các site khác có thể được chọn yes,

Page 33


nếu như một site cấp dưới tiếp tục tiến trình khôi phục lại ở một luồn site chúng ta biết ngay đó là luồn của site là coordinator cho T, và cho đó là không commit hay abort, sự trả lời lại sẽ là để abort T.

-Quan sát nó, nếu site coordinator cho một transaction T lỗi, cấp dưới chọn yes không thể quyết định mặc dù commit hay abort T cho tới khi site coordinator khôi phục lại, chúng nói đó là T đang bị block. Nói chung, các hoạt động của site cấp dưới truyện đạt giữa các site, và tối thiểu một trong số chúng có chứa một đầu đọc commit hay abort T, trạng thái của nó chở thành cái gì đó chung ta biết. 1”0 truyền đạt giữa bản thân của chúng, tất cả cấp dưới sẽ được nói một cách đồng nhất của các cấp dưới khác ở tại một thời điểm chúng được gửi đến thông điệp chuẩn bị. Tuy nhiên, 2PC vẫn giữ chỗ nguy hiểm để coordinator failure trong thời gian khôi phục lại bởi sự kiện nếu tất cả các cấp dưới bỏ phiếu yes, coordinator (người cũng có một phiếu) có thể được quyết định để abort T và quyết định này có lẽ không được xác định cho tới khi coordinator site khôi phục.

-Chúntg ta kín đáo bằng cách khôi phục một site bị huỷ, nhưng cái đó sẽ là một site được đòi hỏi phương thức commit để nếu một site truyền với các fail nếu site hiện tại là coordinator, nó sẽ abort transaction, nếu site hiện tại là một cấp dưới và nó chưa trả lời đến coordinator một thông điệp chuẩn bị nó có thể abort transaction đó, nếu nó là một cấp dưới và được bỏ phiếu yes khi đó nó không thể đơn phương huỷ transaction, vá nó đồng thời cũng không được commit, nó bị block, nó sẽ liên tục một cách định kỳ coordinator cho tới khi nó nhận một trả lời.

-Failures của các liên kết được nhìn thấy bởi các hoạt đông của các site như failure của các site khác đó là chúng được truyền đạt, và bởi vậy các giải phát sẽ được ứng dụng một cách tốt.

22.14.3 Two-Phase Commit Revisited-Bây giờ chúng ta hãy khảo sát một khôi phục một site từ một failure, và nhìn sự ảnh hưỡng lẫn nhau của phương thức 2PC và quá trình khôi phục, nó là để dạy cho cách thức của 2PC có thể được chọn lọc. Trong cách này, chúng ta tới tại một phiên bản tốt hơn 2PC, nhưng có lẽ giống về tầm quan trọng, chúng ta hiểu vai trò của của các bước khác nhau của 2PC. Hay theo dõi ba bước cơ bản:

1. Thông điệp ack trong 2PC được dùng để xác định khi nào là coordinator (hay một quá trình khôi phục một coordinator sau khi huỷ) có thể ‘forget’ chung quanh một transction T. Cho tới khi coordinator

Page 34


biết đó là tấp cả cấp dưới là biết được là commit hay quyết định abort cho T. nó sẽ giữ thông tin về T trong bảng transaction.

2. Nếu một site coordinator fail sau khi gửi thông điệp chuẩn bị nhưng trước khi ghi một commit hay abort, khi đó nó sẽ quay lại cái thông tin quan trọng commit của transaction khi đó đến việc huỷ, tuy nhiên nó được giữ free cho tới khi transaction đơn phương (bởi vì nó đã không được ghi một record commit, nó có thể giữ và không bỏ phiếu cho chính bản thân.) Nếu các site khác hỏi về tình trạng của transaction, quá trình khôi phục, khi chúng ta đã thấy, trả lời với một thông điệp abort. Bởi vậy, trong phần nào đó của thông tin, một transaction được cho là đã được abort.

3. Nếu một cấp dưới không thay đổi nó không thay đổi cả redo hay undo: Trong các từ khác nó sẽ có trạng thai commit hay abort là không hợp lệ.

-Đầu tiên có hai yêu cầu theo dõi phương pháp khác nhau:

Khi một coordination abort một transaction T nó có thể undo T và khôi phục nó từ bảng transaction. Sau đó tất cả những gì remove T từ bảng không có trạng thái kết quả trong thông tin với sự đồi hỏi từ T và mặt định của câu đáp lại (để một câu hỏi về T) trong trạng thái này nó bị abort, là câu trả lời đúng cho việc abort transaction.

Bằng các làm tương tự nếu một cấp dưới nhận một thông điệp abort, nó không cần gửi một thông điệp ack, coordinator không phải chờ để nghe từ một cấp dưới sau khi gửi thông điệp abort! nếu cho một lý do một cấp dưới đó là nhận một thông điệp chuẩn bị (và bỏ phiếu yes) không nhận thông điệp abort hay commit tại một thời điểm chính xác, nó liên kết với coordinator một lần nữa. Nếu coordinator quyết định abort, nó có thể không phải là một nội dung trong bản transaction cho transaction này. nhưng cấp dưới dận được một thông điệp mặc định là abort, nó là câu trả lời đúng.

Bởi vì coordinator không chờ để nghe từ cấp dưới sau khi quyết định abort một transaction, tên của các cấp dưới không cần là mẫu tin trong đầu đọc abort cho coordinator.

Tất cả các đầu đọc abort (cho coordinator giống như cấp dưới) có thể một cách dễ dàng được gắn vào đuôi của đầu đọc, thay vì làm một force-write. Sau tất cả, nếu nó không được ghi vào trong một kho chắc chắn trước khi huỷ, mặc định quyết định là abort transaction.

Page 35


-Thứ ba quan sát yêu cầu cơ bản phương pháp thêm vào:

Nếu một cấp dưới không thay đổi (cái đó có thể dễ dàng xác định bằng các giữ một biến điếm của đầu đọc update,) cấp dưới có thể trả lời đến một thông điệp chuẩn bị từ coordinator với thông điếp reader, thay cho yes hay no. Cấp dưới ghi một đầu đọc no trong trường hợp này.

Khi một coordinator nhận một thông điệp reader, nó đối xử với thông điệp như là bỏ một phiếu yes, nhưng với cấp dưới đó là không gửi bắt kỳ một thông điệp nào đến cấp dưới khác, bởi vì trạng thại commit hay abort của cấp dưới là không hợp lệ.

Nếu tất cả cấp dưới, thêm vào cấp dưới khác ở một coordinator site gửi một thông điệp reader, chúng ta không cần tới bước tiếp theo của phương thức commit. Thực vậy, chúng ta có thể dễ dàng remove transaction từ bảng transaction bỏ qua việc ghi các đầu đọc tại các site này cho transaction này.

-Phương thức two-phase commit với phương pháp thảo luận trong các phần trên gọi là two-phase commit với việc khôi phục abort.

22.14.4 Three Phase Commit-Phương thức commit gọi là three-phase commit (3PC) có thể tránh việc block nếu coordinator site bị lỗi trong thời gian khôi phục. Ý tưởng cơ bản của nó là khi một coordinator gửi một thông điệp chuẩn bị và nhận một phiếu yes từ tất cả các cấp dưới gửi đến site một thông điệp precommit, hơn thế nữa thông điệp commit, khi đủ khả năng tại một thời điểm chúnh xác hơn của coordination failure đó sẽ là handled của ack đã được nhận, coordinator force-writes một đầu đọc commit và gửi thông điệp commit đến tất cả các cấp dưới. Trong 3Pc coordinator thực tế trì hoãn quyết định commit cho tới khi nó chắc rằng các site đủ biết về quyết định commit, nếu cấp dưới của coordinator lỗi, đó lá các site có thể đựoc commit trong trường hợp với mỗi cái khác và xác định đó là transaction sẽ được commit ngược lại abort nếu không chúng được nhận một thông điệp precommit bỏ qua việc chờ coordinator khôi phục.

-Phương thứ 3PC trì hoãn một các chính sát việc cố gắng thêm trong thời gian thực hiện và yêu cầu đó truyền các liên kết failure không buộc các phân quyền mạng (nơi đó ltrong một số site không thể vi phạm đến các phần của các site khác) để chắc chắn quyền tự do từ việc blocking. Vì lý do nào đó, nó không được dùng trong thực tế.

Page 36

Documents

Parallel and Distributed Databases- Full Version