hơn và ít phải dồn. Đầu tiên cũng thực hiện tìm kiếm bản ghi cần xoá, nếu không thấy thì dừng. Nếu thấy thì thực hiện thay thế nó bởi bản ghi có khoá nhỏ nhất còn lớn hơn khoá đó. Việc tìm kiếm bản ghi để thay thế được thực hiện bằng thao tác từ vị trí bản ghi cần xoá, chuyển sang node con phải của nó rồi thực hiện chuyển sang node con trái cho tới khi tới node lá. Sau khi thay thế thì thực hiện dồn lại node lá vừa cho node thay thế.
Hình 19: Phương pháp tìm phần tử thay thế
3.2.4. Một số đặc điểm
MWBT là cấu trúc tìm kiếm phù hợp cho lưu trữ và tìm kiếm nhanh nhưng lượng bộ nhớ trong đòi hỏi thấp trong khi số lần phải truy xuất ra bộ nhớ ngoài thường chỉ cần một lần với thao tác tìm kiếm. Khi làm việc, sẽ lưu node gốc và các node con của node gốc vào bộ nhớ trong nếu có thể, kích thước bộ nhớ trong đòi hỏi chiếm một tỉ lệ rất nhỏ so với kích thước cả cây.
Khi thực hiện thao tác tìm kiếm là thoa tác quan trọng nhất của MWBT, thì trung bình cần: ) ( log * ) 2 ) 1 (( ) 1 ( 3 ) 1 ( 2 1 2 2 2 N N N N N N + + + + + + +
lần so sánh cho cây có chiều cao bằng 3. MWBT bị giới hạn trên về lưu trữ, như đã nói số lượng bản ghi mà MWBT quản lý được bị xác định từ khi thiết kế file chứa cây MWBT, việc tăng kích thước quản lí của cây là rất khó trừ khi tạo mới một file chứa MWBT rồi thực hiện copy các bản ghi sang, sẽ rất lâu nếu kích thước lớn.
Như đã nói ở trên , khi cây đã gần đầy thì việc cập nhật có thể gây mất thông tin.
Từ những ưu nhược nói trên của MWBT tôi đề nghị cải tiến MWBT như
sau, MWBT cải tiến được trình bày dưới đây.
3.2.5. Cây cân bằng nhiều đường cải tiến
3.2.5.1. Giới thiệu
MWBT cải tiến là sản phẩm của sự kết hợp giữa tư tưởng của MWBT và tư tưởng lập chỉ mục. ý tưởng chính là sự tách rời node gốc và N+1 node con của nó ra một file riêng, còn toàn bộ các bản ghi sẽ được lưu trữ tuần tự tăng dần tại một file khác.
Hình 20: Cấu trúc của MWBT cải tiến
File dữ liệu sẽ chứa tất cả các bản ghi, file dữ liệu này sẽ được tổ chức thành các block có kích thước bằng nhau và chứa được một số nguyên các bản ghi (N), mỗi bản ghi ban giờ cũng có một trường Key có tính so sánh được. Các bản ghi dược lưu trữ tăng dần theo Key trong một Block, bản ghi đầu tiên
của Blocki sẽ có Key lớn hơn Key của bản ghi cuối cùng thuộc Blocki-1 . Như
vậy nhìn chung trong toàn bộ file dữ liệu, các Key có khuynh hướng tăng dần. Ngoài ra, khi lưu trữ vào các Block thì không nên ghi đầy, mà chỉ nên ghi đầy bao nhiêu % rồi chuyển sang ghi vào Block kế tiếp, như vậy nếu cần cập nhật vào Block sẽ không phải thực hiện dồn cả file để lấy vị trí trống mà chỉ thực hiện dồn trong một Block.
File chỉ mục tạm sẽ thuần tuý chỉ là file tuần tự liên tục chứa các Key của
các bản ghi đầu tiên của Blocki (i≥2) thuộc file dữ liệu. Sở dĩ gọi là file chỉ
mục tạm bởi khi hoạt động MWBT cải tiến, file chỉ mục tạm sẽ được ánh xạ
chỉ mục tạm không quá lớn thì chỉ cần ánh xạ trực tiếp vào bộ nhớ trong và tìm kiếm theo thuật toán nhị phân bởi khi này sẽ không có sự chênh lệch mấy giữa tốc độ tìm kiếm trên mảng tuần tự và MWBT chiều cao 2).
3.2.5.2. Các thao tác trên MWBT cải tiến
Nói chung, do dựa trên tư tưởng của MWBT, những thao tác trên MWBT
cải tiến có rất nhiều điểm giống với MWBT nhưng có phần còn đơn giản hơn.
3.2.5.2.1. Tìm kiếm
Thao tác tìm kiếm nói chung cũng chỉ mất tối đa một lần truy xuất bộ nhớ ngoài, với bất kì một Key nào, khi duyệt trên file chỉ mục tạm sẽ cho phép xác định chính xác Offset của Block cần tìm thuộc file dữ liệu.
Thuật toán tìm kiếm như sau:
1. Thực hiện tìm kiếm nhị phân trên file chỉ mục tạm, nếu:
a. Kcur bằng Ki thì Offset = SizeOfBlock*i;
b. Ki < Kcur < Ki+1 thì Offset = SizeOfBlock*i;
2. Tìm kiếm trên Block có Offset như trên theo thuật toán tìm kiếm
nhị phân, kết quả trả về sẽ là tìm thấy hay không tìm thấy, và trả lại vị trí tìm cuối cùng (Pos).
Thuật toán trên giả thiết file chỉ mục tạm được ánh xạ không thay đổi thứ tự từng phần tử vào bộ nhớ trong, trong trường hợp là ánh xạ thành một MWBT chiều cao 2 thì giải thuật cũng không phức tạp hơn bao nhiêu.
3.2.5.2.2. Cập nhật
Thao tác cập nhật trên MWBT cải tiến đơn giản hơn rất nhiều so với thao
tác này trên MWBT, và đồng thời không bao giờ bị mất thông tin cũ. Dưới đây là thuật toán cập nhật:
1. Thực hiện tìm kiếm trên MWBT, kết quả trả về vị trí cần cập
nhật (Pos).
2. Nếu Pos không rỗng và Kcur = Ki thì thay đổi nội dung nếu cần
nhưng không được thay đổi khoá.
3. Nếu Pos không rỗng và Ki< Kcur < Ki+1 thì thực hiện dồn trên một
Block tính từ vị trí Ki+1, nếu Block đó đã đầy thì sẽ dồn sang Block liền sau…
cho đến khi dồn được, kế cả có thể tạo ra một Block mới. Chú ý khi dồn mà tạo Block mới hay thay đổi bản ghi đầu tiên của mỗi Block thì cần cập nhật lại cho đúng file chỉ mục tạm.
Nhận thấy rằng sau khi cập nhật, xoá nhiều lần thì có thể file dữ liệu không đồng đều, tức có nhiều Block đầy trong khi lại có nhiều Block rỗng hoặc ít dữ liệu thì thực hiện san bằng file dữ liệu. Việc thực hiện san bằng là đơn giản hơn rất nhiều so với cân đối lại MWBT thường ở trên, thậm trí không cần quan tâm tới file chỉ mục tạm, sẽ tạo mới lại file chỉ mục tạm sau khi dồn xong, thậm trí có thể định nghĩa lại kích thước một Block nếu muốn.
3.2.5.2.3. Xoá
Thao tác xoá rất đơn giản, chỉ thực hiện tìm kiếm, nếu thấy thì xoá đi và dồn lại trong một Block, phải thay đổi file chỉ mục tạm nếu xoá bản ghi đầu Block.
3.2.5.3. So sánh với MWBT thường
Cả hai câu trúc này đều là cấu trúc phục vụ lưu trữ và tìm kiếm ở tốc độ cao cho lượng dữ liệu lớn nhưng chỉ cần tối đa một lần truy xuất ra bộ nhớ ngoài.
Số phép so sánh phải thực hiện trung bình của hai cấu trúc là hầu như
xấp xỉ nhau, mặc dù số phép so sánh đối với MWBT cải tiến nhiều hơn một
chút nhưng bù lại nó có thể tối ưu hoá kích thước một Block tuỳ theo lượng dữ
liệu đang lưu trữ nên vẫn có thể nói tìm kiếm trên MWBT cải tiến nói chung
nhanh hơn. Tìm kiếm trên MWBT chỉ nhanh hơn MWBT cải tiến một chút khi lượng bản ghi rỗng trên kích thước toàn cây là nhỏ, điều này khó xảy ra nếu cấu trúc này thường xuyên được cập nhật, cần phải dự trữ chỗ trống để cập nhật.
Một số Key của các bản ghi đầu mỗi Block phải lưu trữ hai lần nên tổng
kích thước lưu trữ của MWBT cải tiến có nhiều hơn một chút nhưng hiệu quả
sử dụng bộ nhớ trong có thể coi là như nhau bởi kích thước file chỉ mục tạm là bé hơn kích thước node gốc cộng với N+1 node con của nó xét trên cùng một tập lưu trữ.
Các thao tác trên MWBT cải tiến đơn giản hơn rất nhiều và không có
trường hợp làm mất thông tin cũ.
MWBT cải tiến có thể thay đổi kích thước một Block tuỳ vào lượng bản ghi đang lưu giữ trong khi MWBT đã bị cố định ngay từ thiết kế đầu tiên.
Việc áp dụng kĩ thuật Cache cho MWBT cải tiến là đơn giản hơn nhiều.
Từ một nhận xét trên cho thấy rằng MWBT thường trong tìm kiếm sẽ nhanh hơn một chút so với MWBT cải tiến nếu tỉ lệ bản ghi rỗng thấp. Nếu trong một mô hình đòi hỏi tốc độ tìm kiếm tốc độ cao mà việc cập nhật chỉ thực hiện theo lô, và định kì cập nhật hàng tháng hoặc hơn, dữ liệu lưu trữ không quá lớn và thao tác cập nhật chỉ chạy nền thì ta có thể áp dụng một cải tiến cho MWBT thường.
Ý tưởng chính là sử dụng MWBT cải tiến như là một khâu trung gian trong cập nhật.
MWBT cai tien MWBT thuong
Data Converting
Xoa
Tim kiem Cap nhat
Hình 21: Mô tả hoạt động của MWBT tối ưu tìm kiếm
Tồn tại song song một MWBT cải tiến và một MWBT thường để tận dung được ưu điểm của cả hai cấu trúc, ở đây cần phải có một thuật toán biến đổi từ MWBT cải tiến sang MWBT thường sao cho tỉ lệ rỗng trong MWBT thường là rất thấp xấp xỉ 0, và việc tìm kiếm thực hiện hoàn toàn trên MWBT thường, mỗi khi đến kì cập nhật sẽ thực hiện cập nhật thì sẽ thực hiện cập nhật vào MWBT cải tiến rồi sau đó sẽ thực hiện biến đổi và tạo mới MWBT thường khác.
Nói chung thuật toán biến đổi từ MWBT cải tiến sang MWBT thường không khó lắm. Đâu tiên cần xác định số lượng bản ghi có trong MWBT cải tiến là No. Sau đó giải phương trình sau để tìm N là kích thước mỗi Block của MWBT thường:
((N+1)2 + N + 2)*N = No
Sau khi tìm được N thì xây dựng một file MWBT thường và sẽ chuyển dữ liệu sang theo lô.
Như vậy phương pháp này có thể tận dụng tối đa ưu điểm về tốc độ tìm kiếm nhưng việc cập nhật thực sự rất phiền toái đòi hỏi chi phí cao, chỉ có thể dùng trong trường hợp đặc biệt như đã nói.
3.2.5.5. Lí do lựa chọn và mục đích sử dụng
Dưới đây sẽ phân tích những ưu nhược của một số câu trúc lưu trữ và tìm kiếm phổ biến so với MWBT thường:
• Mảng tuần tự: tốc độ tìm kiếm chậm hơn, không phù hợp đối với
dữ liệu cần lưu trữ lớn, số lần phải truy xuất bộ nhớ ngoài trung bình lớn hơn 1 khá nhiều và tuỳ thuộc kích thước dữ liệu đang lưu trữ, khó cập nhật cũng như xoá bỏ khi số lượng phần tử lớn.
• Cây đỏ đen, cây cân bằng: cũng có những nhược điểm tương tự
mảng tuần tự, không phù hợp khi số lượng phần tử lớn. Ngoài ra cấu trúc vật lí của cây khi lưu trữ ra file cũng phức tạp một cách không cần thiết do khó loại bỏ biến con trỏ.
• Bảng băm: đây là một câu trúc tìm kiếm tốc độ cao, phù hợp với
số lượng phần tử lớn, thiết kế vật lí của bảng băm được trình bày trong mục bảng băm dưới đây cũng cho phép giảm thiểu số lần vào ra bộ nhớ ngoài nhưng đáng tiếc bảng băm không phù hợp trong trường hợp Key là những đoạn text hay là nhưũng con số ngẫu nhiên, sẽ xảy ra xung đột nhiều làm giảm hiệu quả của bảng băm trong tìm kiếm cũng như trong cập nhật đồng thời sẽ giảm rất nhiều hiệu quả sử dụng bộ nhớ trong.
Như vậy, chúng ta đã thấy lí do tại sao mà MWBT được dùng rất phổ biến trong các hệ trích chọn thông tin. Và như đã phân tích so sánh giữa MWBT cải tiến và MWBT thường, tôi quyết định chọn MWBT cải tiến cho
thiết kế ‘Từ điển’ và ‘Kho chứa Web’. Tuy nhiên, khi áp dụng để có tối ưu cần
có những thay đổi đặc thù cho từng trường hợp.
3.2.5.6. Một số thay đổi đặc thù cho từng trường hợp
3.2.5.6.1. Từ điển
Từ hoạt động của từ điển có thể thấy những mong muốn đối với thiết kế từ điển gồm:
• Yêu cầu bộ nhớ trong và ngoài thấp.
• Khả năng lưu trữ không hạn chế.
• Không hạn chế độ dài term lưu giữ.
• Khả năng cập nhật dễ dàng.
Như vậy còn một mục tiêu mà chúng ta chưa phân tích là làm thế nào để chúng ta có thể lưu giữ được những Term có độ dài không hạn chế mà không ảnh hưởng tới hiệu quả sử dụng bộ nhớ cũng như tốc độ tìm kiếm. Việc đặt mục tiêu không hạn chế là không cần thiết bởi, qua tìm hiểu tôi không tìm thấy được một ngữ nào có độ dài quá 40 kí tự, bởi vậy mục tiêu là làm thế nào để lưu trữ được những Term có độ dài nhỏ hơn 40 kí tự mà không lãng phí.
Một nhận xét sau khi tìm hiểu thêm trong những từ điển tiếng Việt về độ dài ngữ, hoặc ngữ trong tiếng Việt.
• Các thành ngữ hay những ngữ thông dụng trong tiếng Việt có độ
dài quá 20 ký tự đều được tổ hợp từ những từ thuần Việt do đó có thể được mã hoá từ tiếng Việt đã được trình bày ở trên.
• Ngữ dài nhất trong tiếng Việt được tìm thấy gồm 10 từ đơn nếu
mã hoá chỉ cần 20 byte.
• Ngữ dài nhất chứa từ không thuần Việt được tìm thấy trong từ
điển chỉ gồm 12 ký tự tuy nhiên trên thực tế tôi đã thấy những tên thuốc có độ dài gần 20 kí tự. Mặc dù những tên thuốc không thể coi là từ tiếng Việt nhưng cũng rất cần cho vào từ điển, thậm trí cả những từ tiếng Anh nào cần thiết cũng có thể cập nhật vào từ điển. Bởi vậy giới hạn lớn nhất một từ, ngữ không thuần Việt có thể coi là 25 ký tự.
Để giúp tiết kiệm không gian nhớ do phải cấp cho mỗi Term một mảng đủ để chứa Term, tôi chọn ra một phương án sau:
• Với Term thuần Việt, tức tất các các từ đơn của nó đều là từ
thuần Việt sẽ sử dụng hai MWBT cải tiến tách rời lưu trữ. Một có độ dài max 8byte để lưu những Term cấu tạo gồm 4 từ đơn trở xuống. Và một có độ dài max 20 byte để lưu tất cả những Term có cấu tạo trên 4 từ đơn và dưới 10 từ đơn.
• Với Term không thuần Việt cũng tương tự sử dụng hai MWBT
cải tiến riêng biệt, một chứa những Term dưới 10 ký tự, một chứa Term trên 10 ký tự và dưới 25 ký tự.
Một điểm đáng chú ý khi tách từ điển ra nhiều file độc lập sẽ làm khó khăn trong việc quản lý GroupId, mặc dù các file MWBT cải tiến độc lập với nhau nhưng cần quản lý như một hệ thống nhất. Khi cấp phát một GroupId thì cần chắc rằng những file kia chưa sử dụng.
Một đặc điểm rất thú vị là đối với từ điển phục vụ hệ trích chọn thông tin thì hầu như chỉ có thao tác thêm từ mới, việc xoá một từ đã được cập nhật là rất hiếm. Từ nhận xét trên, tôi đưa ra một giải pháp có thể quản lý GroupId là luôn cấp phát GroupId mới một cách tuần tự đồng thời quản lý chặt chẽ mỗi khi có thao tác xoá Term khỏi từ điển thì sẽ lưu lại GroupId của Term đó để rồi sau đó sẽ kiểm tra sự tồn tại của GroupId đó còn trong từ điển không (phải duyệt toàn bộ từ điển) nếu không sẽ được lưu ra một kho riêng để rồi cấp phát cho lần sau.
Phương pháp quản lý trên sẽ đảm bảo các GroupId tăng dần, rất hữu ích cho thiết kế bảng băm dưới đây.
3.2.5.6.2. Kho chứa
Đây là kho chứa phần text của các trang Web hoặc một mô tả về nội dung trang Web(đã được nén) để bổ xung thêm một phần thông tin về trang Web trong kết quả trả về. Hoạt động cơ bản của kho chứa Web như sau :
Repository
DocID & GroupID Ket qua tra ve
Hình 22: Mô tả hoạt động cơ bản của Respository
Cấu trúc cần lưu tương ứng với từng trang Web gồm: