Hình 2 .2 Bộ nén Delta
Hình 2.4 Sự đối lập giữa thời gian thực hiện và sự giống nhau của các file
Với tập dữ liệu gcc và emacs, các số khơng thể nén và gzip ở phiên bản mới hơn. Chúng ta cĩ thể thấy rằng nén delta cĩ những cải thiện rõ ràng hơn gzip trên các file này, đặc biệt là với các file tương tự gcc. Trong số các bộ nén delta, zdelta nhận được tỉ lệ nén tốt nhất, chủ yếu là do việc sử dụng Huffman thay vì các mã dựa trên bytẹ Bộ nén xdelta thi hành tồi nhất trong các thí nghiệm nàỵ Xdelta tập trung vào mục đích phân tách và nén, và do đĩ, một bộ nén chuẩn như gzip cĩ thể được áp dụng đối với output của xdeltạ Tuy nhiên, trong các thí nghiệm của chúng ta, các ứng dụng gzip khơng cĩ kết quả cải thiện tốt nào trong các tập dữ liệu nàỵ
Về thời gian chạy, tất cả 3 bộ nén delta đều chậm hơn gzip, xdelta thì xong sớm nhất. Chú ý rằng, với cả gzip và zdelta, chúng ta sẽ tổng kết 2 con số khác nhau thể hiện tác động của phương pháp input/output trong sự thi hành. Đầu tiên, các số thấp hơn truy nhập file trực tiếp, trong khi các số thứ hai được đo lường bằng các chuẩn I/Ọ Số cho vcdiff được đo lường bằng các chuẩn I/O, trong khi xdelta sử dụng truy nhập file trực tiếp. Đưa các sự khác nhau này vào tính tốn, tất cả các bộ nén delta chỉ chiếm 20% so với gzip, thậm chí chúng cĩ thể xử lý 2 tập file trong khi gzip chỉ xử lý được một.
Nhìn vào phần đồ thị về sự giống nhau giữa các file, chúng ta sẽ thấy cùng một thứ tự. Khi các file càng khác nhau nhiều, file nén delta cĩ kích thước càng lớn, nhưng vẫn là tốt nhất trong các phép nén, trong khi đĩ, khi các file gần như là giống nhau thì các phương pháp đều hoạt động tốt. Tuy nhiên, chúng ta thấy rằng, vcdiff và zdelta cĩ tác dụng ngay cả khi các file chỉ khác nhau một chút, trong khi đĩ, xdelta khơng cải thiện hơn so với gzip. ( Chú ý rằng gzip tự nĩ khơng cung cấp 1 ích lợi nào với các file khơng thể nén được). Chúng ta cũng thấy rằng thời gian chạy của bộ nén delta giảm khi sự giống nhau giữa các file tăng lên, điều này là do độ dài của sự phù hợp được tìm thấy trong file tham chiếu tăng lên (do đĩ làm giảm số lần tìm kiếm trong bảng băm). Sự ảnh hưởng lớn này giải thích tại sao bộ nén delta hầu như chạy nhanh bằng gzip đối với các file giống nhau nhiều như gcc và emacs; với các file cĩ độ giống nhau là thấp, 3 bộ nén delta sẽ dài hơn khoảng 60% hoặc 100% so với gzip.
2.5 Các vấn đề liên quan
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 tố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ã hố 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 tố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ã hố. 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 tốn là thuật tốn chỉnh sửa một bước. Thuật tố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ã hố trước đĩ của fold. Thuật tố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ã hố của fnew. Trong trường hợp này, thuật tốn sẽ cố gắng để xác định xem đoạn mã hố trước đĩ của M cĩ thể đã được nén rồi hay chưa và vì thế M cĩ thể được mã hố 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 tố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 tố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 hố 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 tố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 tố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 hồ tập các bản ghi trong một databasẹ
2.5.3.1 Thuật tốn rsync
Chúng ta sẽ mơ tả về thuật tố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 tồ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 tố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ị khố.
(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 tố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ể hồ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 tố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 tồ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 hố thành một tập hồ giảị Cĩ rất nhiều các gĩi chương trình thực hiện truyền tồ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 để