2.5.1 Khoảng trống miễn cƣỡng trong bộ nén delta
Như đã mô tả trong phần 2.2, thuật toán tham lam của Tichy đã đạt được kết quả trong một tập tuỳ ý nào đó của khối di chuyển. Cách di chuyển của các khối xác định
cách mã hoá trong sự thực thị Trong phần 2.3, chúng ta đã bàn về một sự thi hành dựa trên khung LZ77. Tuy nhiên, các thuật toán này có thể cho một sự thi hành nghèo nàn hơn khi gặp phải giới hạn về bộ nhớ trong các bộ xử lý nén và giải nén. Đầu tiên, chúng ta thực hiện phép nén delta trong giới hạn về không gian và thời gian, điều này sẽ bị ảnh hưởng khi file fold và fnew có kích thước lớn. Một giải pháp đơn giản trong trường hợp này là có thể giới hạn sự tìm kiếm đối với các tiền tố dài nhất trong fold, các tiền tố này đứng trước các điểm kết thúc của các xâu đã được mã hoá. Tuy nhiên, các kết quả này sẽ không đạt được mức ý nghĩa đó khi các xâu con xuất hiện không cùng thứ tự trong cả fold và fnew.
Để giải quyết vấn đề đó, người ta đưa ra một thuật toán là thuật toán chỉnh sửa một bước. Thuật toán sử dụng một buffer chứa tất cả các bản sao của yêu cầu, và thực hiện sự chỉnh sửa trên các yêu cầu này sau khi sự phù hợp tốt nhất được tìm thấỵ Có 2 loại chỉnh sửa có thể làm. Chỉnh sửa đuôi (tail correction) được thực hiện sau khi insert 1 bản copy yêu cầu từ một phần chưa mã hoá trước đó của fold. Thuật toán cố gắng để mở rộng xâu phù hợp về phía sau trong cả fold và fnew . Nếu sự phù hợp như vậy được tìm thấy theo hướng giật lùi, có một khả năng cho việc thay thế lệnh copy trước đó bằng cách tích hợp chúng vào lệnh copy hiện thờị Loại chỉnh sửa thứ 2 là chỉnh sửa chung, có thể thực hiện khi 1 xâu con phù hợp M được tìm thấy trong phần đã mã hoá của fnew. Trong trường hợp này, thuật toán sẽ cố gắng để xác định xem đoạn mã hoá trước đó của M có thể đã được nén rồi hay chưa và vì thế M có thể được mã hoá bởi một lệnh copy đơn. Hơn nữa, để giới hạn tiêu tốn không gian chứa các xâu con, chúng ta sử dụng một kỹ thuật gọi là kiểm tra điểm. Kỹ thuật này sẽ đảm bảo một xâu con đã được insert vào bảng băm sao cho vùng vị trí nhỏ nhưng việc lựa chọn số phải thật cẩn thận. Kết quả của sự mở rộng này là kỹ thuật nén delta đảm bảo được cả các yêu cầu về không gian và thời gian, có thể làm việc với kích thước file bất kỳ.
2.5.2 Chọn file tham chiếu
Trong một vài ứng dụng, sự thi hành của nén delta phụ thuộc lớn vào việc lựa chọn file tham chiếu phù hợp. Chẳng hạn, để nén một tập các file liên quan, chúng ta cần chọn cho mỗi file một hoặc nhiều file tham chiếu có sự giống nhau với nó; mỗi file tham chiếu tự nó cũng có thể nén theo cách nàỵ Trong trường hợp có 1 file tham chiếu cho mỗi file nén, vấn đề này trở thành tìm một nhánh tốt hơn trong đồ thị tương ứng trực tiếp, trong đó, mỗi cạnh (i,j) có trọng số bằng kích thước của delta với i tương ứng với file tham chiếu j. Trong một số tài liệu, vấn đề này có thể giải quyết theo hướng bình phương của thời gian, tuy nhiên lại mắc phải 2 hạn chế: Đầu tiên,
giải pháp có thể chứa một chuỗi các tài liệu rất dài cần phải truy nhập nếu muốn giải nén một file cụ thể nào đó. Thứ hai, với một bộ sưu tập lớn, bình phương thời gian trở thành khó chấp nhận, nhất là vấn đề giá trong việc tính trọng số thích hợp của đồ thị trực tiếp.
Nếu chúng ta áp độ dài cao hơn đối với chuỗi tham chiếu, sau đó tìm giải pháp tốt hơn thì sẽ trở thành thuật toán NP Completẹ Nếu chúng ta cho phép mỗi file được nén sử dụng hơn 1 file tham chiếu, thì vấn đề này có thể được giảm tới 1 nhánh đồ thị tối ưu, như được chỉ ra trong thuật toán NP Complete thậm chí không có giới hạn độ dài của xâụ
Một ví dụ của chuỗi tham chiếu dài là khi giải quyết với các phiên bản khác nhau của cùng 1 file, như một hệ thống điều khiển xem xét lại chẳng hạn. Trong trường hợp này, việc lựa chọn file tham chiếu nhằm cực tiểu hoá dữ liệu là hiển nhiên, nhưng sự lựa chọn này có thể phải yêu cầu đến những phiên bản rất cũ và do đó sẽ khá đắt. Rất nhiều kỹ thuật đã được đề xuất để giải quyết vấn đề này bằng cách tạo ra một số giới hạn các short cut tới các phiên bản cũ hơn.
2.5.3 Đồng bộ các file từ xa
Trong phần này, chúng ta tập trung vào vấn đề đồng bộ các file ở xa, trong trường hợp khi server không có quyền truy nhập tới file tham chiếụ Những thuật toán đã biết đối với vấn đề này có khác biệt so với bộ nén deltạ Chúng ta sẽ bàn về 2 hướng nghiên cứu chính: (1) hướng nghiên cứu dựa trên chuỗi dấu vân tay được thực hiện theo thuật toán rsync tuy nó không đạt được giới hạn tối ưu nào, và (2) dựa trên việc tô màu đồ thị, hướng này đạt được sự thi hành tối ưu dưới các mô hình hiện thời cho khoảng cách file, nhưng dường như nó không phù hợp trong thực tế. Chúng ta cũng sẽ bàn về các vấn đề liên quan trong việc đánh giá sự tương đồng của file và cách điều hoà tập các bản ghi trong một databasẹ
2.5.3.1 Thuật toán rsync
Chúng ta sẽ mô tả về thuật toán đồng bộ file được triển khai rộng rãi rsync của Tridgell và MacKerras. Một hướng nghiên cứu tương tự cũng được thực hiện bởi Pyne[7].
Giả sử ta có 1 cuộc giao tiếp giữa 2 bên thông qua điện thoại, mỗi bên có 1 bản copy của một cuốn sách. Bây giờ, giả sử 2 bản copy có thể khác nhau ở một vài chỗ nào đó. Bằng cách nào chúng ta có thể tìm ra 2 cuốn sách có giống nhau hay không, và nếu không thì chúng khác nhau ở chỗ nào và khác nhau như thế nào, mà không cần đọc hết toàn bộ cuốn sách qua điện thoạỉ Câu trả lời của câu hỏi đầu tiên rất đơn giản, bằng cách dùng hàm checksum (MD5 chẳng hạn) và so sánh checksum của 2
cuốn sách, như thế nó sẽ xác định được 2 cuốn sách có giống nhau hay không. Câu trả lời cho câu hỏi thứ 2 thì khó hơn một chút. Một hướng nghiên cứu ban đầu là người ta chia cuốn sách thành 2 nửa, nửa đầu và nửa cuối, sau đó sẽ thực hiện checksum trên mỗi nửa, cho tới khi vị trí khác nhau được tìm rạ Tuy nhiên, hướng nghiên cứu này sẽ bị sai trong một trường hợp hết sức đơn giản, khi một cuốn sách chứa thêm một số từ vào đầụ Do đó, một hướng nghiên cứu khác, mạnh hơn là cần thiết mặc dù ý tưởng cơ bản vẫn là sử dụng checksum trên các khốị
Chúng ta sẽ mô tả và chọn lọc thuật toán rsync. Ý tưởng cơ bản là giải quyết vấn đề về sự sắp xếp thẳng hàng bằng cách tính checksum khối cho file tham chiếu, và so sánh các checksum này với các checksum khối tương ứng của file hiện thời, và với checksum của tất cả các vị trí có thể của các khối trong file hiện thờị Kết quả là, server biết được đoạn nào của file hiện thời đã tồn tại trong file tham chiếu, và phần nào mới cần giao tiếp với client. Để đạt được hiệu quả, 2 checksum khác nhau sẽ được truyền thông tới server, tuy nhanh nhưng không đáng tin cậy, muốn đạt được sự tin cậy hơn thì cần đắt hơn nhiềụ
1. Tại client:
(a) Phần fold trong các khối Bi = fold [ib,(i+1)b-1] của kích thước b được xác định sau
(b) Với mỗi khối Bi, tính 2 checksum, ui = hu (Bi) và ri = hr (Bi) và truyền chúng tới server. Ở đây, hu là hàm checksum không đáng tin cậy nhưng nhanh, và hr thì đáng tin cậy nhưng đắt.
2. Tại server:
(a) Với mỗi cặp checksum nhận được (ui,ri), thêm một thực thể (ui,ri,i) vào cấu trúc dữ liệu từ điển, sử dụng ui như một giá trị khoá.
(b) Thực hiện một bước trong fnew, bắt đầu tại vị trí j=0, và liên quan tới các bước sau:
(i) Tính hàm checksum không đáng tin cậy hu(fnew [j, j+b-1]) trên khối bắt đầu tại j.
(ii) Kiểm tra từ điển xem có khối nào có checksum không tin cậy phù hợp không
(iii) Nếu tìm thấy, và nếu có checksum đáng tin cậy cũng phù hợp, truyền một con trỏ tới chỉ số của khối phù hợp trong fold tới client, j tiến tới vị trí b, và tiếp tục.
(iv) Nếu không tìm thấy, hoặc nếu checksum tin cậy không phù hợp, truyền ký tự fnew[j] tới client, tăng j thêm 2 và tiếp tục.
Tại client:
Checksum nhanh và không tin cậy được sử dụng để tìm ra sự phù hợp, và các checksum tin cậy sau đó được dùng để xác nhận sự phù hợp đó. Checksum phù hợp được thi hành bằng cách sử dụng MD4 (128 bit). Checksum không tin cậy có 32bit, nó cho phép chuyển một cách hiệu quả các đường bao khối bởi 1 ký tự, chẳng hạn, checksum cho f[j+1,j+b] có thể được tính trong thời gian không đổi từ f[j,j+b-1].
Rõ ràng, việc lựa chọn một kích thước khối tốt là tiêu chuẩn để thực hiện thuật toán. Sự lựa chọn tốt nhất lại phụ thuộc lớn vào sự giống nhau giữa 2 file – các file càng giống nhau thì chúng ta càng có thể chọn kích thước khối lớn. Hơn nữa, vị trí của các thay đổi trong file thì cũng rất quan trọng. Nếu một ký tự đơn được thay đổi trong mỗi khối của fold, thì không có sự phù hợp nào sẽ được tìm thấy tại server và rsync sẽ không thể hoàn thành một cách hiệu quả được; mặt khác, nếu tất cả các thay đổi được phân thành một vài vùng trên file, rsync sẽ làm rất tốt thậm chí với một kích thước khối lớn. Tuy nhiên, rsync không có sự thi hành tốt với không gian khoảng cách filẹ
Tất nhiên, thông thường kích thước khối thậm chí có thể thay đổi trong một filẹ Trong thực hành, rsync bắt đầu với một kích thước khối hàng trăm byte, và sử dụng các phép heuristic để chỉnh sửa sau đó.
2.5.3.2 Các kết quả thực nghiệm của rsync
Bây giờ, chúng ta sẽ đưa ra một vài kết quả về sự thi hành của rsync so với nén deltạ Các kết quả sử dụng tập dữ liệu gcc và emacs. Chúng ta tổng kết 5 con số cho rsync: số lượng dữ liệu được gửi từ client tới server (request), số lượng dữ liệu được gửi từ server tới client (reply), số lượng dữ liệu được gửi từ server tới client với tuỳ chọn nén đã bật (reply compressed), và tổng số cho cả 2 hướng trong trường hợp không nén (total) và đã nén (total compressed).
Gcc Emacs Uncompressed 27288 27326 Gzip 7479 8191 Xdelta 461 2131 Vcdiff 289 1821 Zdelta 250 1465 Rsync request 180 227 Rsyn reply 2445 12528
Rsync total 2626 12756
Rsync total compressed 876 4428
Bảng 2.2: Các kết quả nén cho tập dữ liệu gcc và emacs (KB)
700 500 300 200 100 80
Rsync request 227 301 472 686 1328 1679
Rsync reply 12528 11673 10504 9603 8433 8161 Rsync reply compressed 4201 3939 3580 3283 2842 2711 Rsync total 12756 11974 10976 10290 9762 9810 Rsync total compressed 4429 4241 4053 3970 4170 4360
Bảng 2.3: Các kết quả nén cho emacs với các tập dữ liệu khác nhau (KB)
2.5.3.3 Các ứng dụng
Các ứng dụng cho đồng bộ file cũng tương tự như đối với thuật toán nén deltạ Đồng bộ file thì phổ biến hơn, trong đó nó không yêu cầu các kiến thức về file tham chiếu; mặt khác, nén delta hướng tới thi hành sự đồng bộ một cách tốt hơn theo khía cạnh tỷ lệ nén. Có rất nhiều lý do tại sao server có thể không chứa các file tham chiếu, chẳng hạn do không gian bộ nhớ, do các phiên bản trước đó của file tham chiếu đã được cập nhật lên các phiên bản mới hơn… Dưới đây là một vài ví dụ:
- Đồng bộ cho các file người dùng: Có một số gói phần mềm như rsync, Microsoft‟s ActiveSync, Puma Technologies‟ IntelliSync hay Palm‟s HotSync cho phép đồng bộ giữa desktop, thiết bị mobile hay các tài khoản cá nhân có thể truy cập web. Trong phần này, các file hay các bản ghi có thể được update bởi rất nhiều phần khác nhau, và nhãn thời gian có thể được dùng để xác định phiên bản gần nhất.
Chúng ta cần chú ý rằng có rất nhiều gợi ý cho các công cụ nàỵ Với dữ liệu dạng file, chúng ta có thể đồng bộ các file từ xa, tránh được việc phải truyền toàn bộ filẹ Với dữ liệu tồn tại dưới dạng các tập lớn của các bản ghi nhỏ, chẳng hạn như danh sách các địa chỉ hay các cuộc hẹn trong các thiết bị cầm tay, vấn đề là làm thế nào để phân biệt các bản ghi này có thay đổi mà không cần gửi một dấu hiệu riêng hay các nhãn thời gian cho mỗi bản ghị Vấn đề này, được mô hình hoá thành một tập hoà giảị Có rất nhiều các gói chương trình thực hiện truyền toàn bộ thực thể nếu có thay đổi nào xảy ra, thường thấy tại các tập dữ liệu dựa trên bản ghi nhỏ, không dùng cho các file lớn. Thêm vào đó, cũng có những vấn đề về việc định nghĩa về ngữ nghĩa thích hợp trong hệ thống đồng bộ filẹ
- Lưu trữ từ xa các tập dữ liệu khổng lồ: Việc đồng bộ có thể được sử dụng để lưu trữ từ xa các tập dữ liệu mà chỉ có thay đổi một chút giữa các lần cập nhật. Trong trường hợp này, việc giữ các phiên bản cũ tại server có giá đắt làm cho kỹ thuật nén delta trở lên không hiệu quả.
- Truy cập web: Đồng bộ file cũng được dùng cho việc truyền HTTP giữa các client với một server hoặc proxỵ Lợi ích của nó là server không cần phải giữ dấu vết của các phiên bản cũ được giữ tại client, và cũng không cần phải tìm lại các phiên bản ấy từ đĩạ Tuy nhiên, như chỉ ra trong phần trên, kỹ thuật đồng bộ file có tỷ lệ nén tồi hơn nén delta, và vì thế nó không chỉ đem lại những lợi ích cho các file tương tự nhaụ
- Hệ thống phân tán ngang hàng: Đồng bộ cũng được dùng cho việc cập nhật các cấu trúc dữ liệu phân tán cao như: routing table, name services, indexes, hay replication tables.
CHƢƠNG 3 - ỨNG DỤNG THUẬT TOÁN NÉN DELTA TRONG VIỆC CẬP NHẬT CÁC PHẦN MỀM NGHIỆP VỤ TẠI NGÂN HÀNG CÔNG THƢƠNG
VIỆT NAM
3.1 Mô hình hệ thống công nghệ thông tin trong ngân hàng Công Thƣơng Việt Nam
Dưới đây là mô hình của hệ thống công nghệ thông tin trong ngân hàng.
HQ Server
North Server Miđle Server South Server
Branch Server Branch Server Branch Server
Client PC Client PC Client PC
upload upload upload upload upload upload update update update
Hình 3.1: Mô hình hệ thống công nghệ thông tin tại NHCTVN
Toàn hệ thống ngân hàng bao gồm rất nhiều chi nhánh trên khắp các tỉnh thành của cả nước. Mỗi chi nhánh lại bao gồm nhiều điểm giao dịch, phòng giao dịch. Tại mỗi điểm giao dịch, có thể có nhiều máy tính Client PC chứa các phần mềm nghiệp vụ giúp các giao dịch viên làm việc với khách hàng. Tại mỗi chi nhánh, có một máy chủ Branch Server nhằm quản lý dữ liệu tập trung của toàn bộ chi nhánh. Các máy chủ chi nhánh này lại được quản lý bởi một máy chủ Server vùng. Có ba máy chủ Server vùng là North Server, Miđle Server và South Server tương ứng với ba vùng bắc, trung, nam. Các máy chủ Server vùng lại được quản lý bởi một máy chủ Server của toàn hệ thống, gọi là HQ Server.
3.2 Quy trình cập nhật các phần mềm nghiệp vụ trong ngân hàng Công Thƣơng Việt Nam
Khi có một nghiệp vụ mới, hoặc khi cần thay đổi các tham số cho một vài nghiệp vụ đang tồn tại,… các phần mềm nghiệp vụ cần được cập nhật tới tất cả các máy tính trong toàn hệ thống. Vậy, bài toán đặt ra là làm thế nào để các phần mềm này được