Nhƣ đã đề cập ở trên, công nghệ máy tìm kiếm gồm ba thành phần chính, tuy nhiên trong báo cáo luận văn tập trung chủ yếu là thành phần đầu tiên của máy tìm kiếm là quá trình thu thập thông tin hay quá trình khảo duyệt web. Trong phần này, báo cáo luận văn đề cập đến yêu cầu thiết kế chung đối với một hệ thống khảo duyệt web. Sau đó đề cập đến việc thực hiện trên dựa trên DHT và bộ lọc bloom, và cách áp dụng với kiến trúc đã đƣa ra.
2.3.1 Thiết kế hệ thống khảo duyệt web
Trong phần này, báo cáo luận văn đề cập đến các thành phần thiết kế cơ bản của bộ thu thập thông tin và các nguyên tắc thiết kế quan trọng dùng để xem xét
việc khảo duyệt phân phối và phi tập trung. Một bộ thu thập thông tin web điển hình gồm ba thành phần chính nhƣ sau:
- Bộ tải dữ liệu: thành phần này đọc danh sách các địa chỉ URL và tạo các yêu cầu HTTP để tải các trang web này.
- Bộ chiết xuất URL (URL Extractor): thành phần này chịu trách nhiệm chiết xuất các địa chỉ URL từ trang web đã download về, sau đó đƣa URL vào trong danh sách sẽ đƣợc khảo duyệt
- Bộ kiểm tra trùng lặp: thành phần này chịu trách nhiệm kiểm tra URL và nội dung có bị trùng lặp không.
Để khảo duyệt, bộ thu thập thông tin cần duy trì kho dữ liệu sau: - Crawl-Job: là danh sách URL cần khảo duyệt
- Seen-URL: là danh sách URL đã đƣợc khảo duyệt.
- Seen-Content: là danh sách fingerprints (chữ ký băm/checksum) của trang web đã đƣợc khảo duyệt.
Bộ tải dữ liệu chọn URL từ kho dữ liệu của Crawl-Job và tải trang này. Nó kiểm tra tính trùng lặp nội dung. Nếu kết quả kiểm tra thấy có trùng lặp thì nó sẽ bỏ qua URL này. Nếu kết quả là một trang mới, fingerprint đƣợc bổ sung vào kho dữ liệu See-Content. Sau đó thành phần bộ chiết xuất URL xử lý trang web này chiết xuất ra nhiều địa chỉ URL tức nó lần ra các mối liên kết tới những trang khác bên trong trang đó và chuẩn hoá lại chúng. Các địa chỉ URL sau đó đƣợc kiểm tra tính trùng lặp và nếu tìm thấy có địa chỉ mới, chúng sẽ đƣợc bổ sung vào danh sách Crawl-Job. Đồng thời, các địa chỉ URL cũng đƣợc bổ sung vào danh sách See- URL. Cả hai quá trình kiểm tra trùng lặp đều khá quan trọng.
Tình huống trùng lặp URL trên thực tế là khá phổ biến, do tính thông dụng về nội dung và một trang website thƣờng có header và footer chung cho tất các trang con của mình. Các trang trùng lặp xảy ra do việc nhân bản các site và cũng có khi là do các liên kết tƣợng trƣng tại phía máy chủ web, ví dụ cả trang home.html và index.html đều là trỏ đến cùng một trang trên nhiều máy chủ web. Theo kinh nghiệm của Mercator [6], có khoảng 8.5% các trang bị trùng lặp.
Đối với bộ thu thập thông tin phân tán, các quyết định phải đƣợc thực hiện từ việc lựa chọn bộ thu thập thông tin nào khảo duyệt từ một URL cụ thể. Điều có thể là khá đơn giản nhƣ việc chọn các URL từ Crawl-Job tuần tự và chuyển đến bộ thu
thập thông tin trong robin fashion hoặc có thể dựa trên chính sách lựa chọn phức tạp. Ví dụ, Google [5] sử dụng nhiều máy trong một vòng robin manner, còn Internet Archive phân tán chúng dựa trên những tên miền đang đƣợc khảo duyệt. Tuy nhiên, thiết kế bộ thu thập thông tin phân tán có một số khó khăn sau:
Phân chia công việc: vấn đề này đóng vai trò quan trọng đối với bộ thu thập thông tin phi tập trung hơn là mô hình tập trung. Vấn đề đặt ra là cần sử dụng các bộ thu thập thông tin phân tán để thu thập thông tin các phần riêng biệt trên web tại mọi thời điểm. Cũng có một số phƣơng pháp tối ƣu tiềm năng dựa trên đặc điểm phân tán địa lý của các bộ thu thập thông tin trên toàn cầu. Trong phần tiếp theo sẽ mô tả cách thức khai thác dữ liệu toàn cầu trên các nút trong hệ thống Apoidea.
Kiểm tra tính trùng lặp: thậm chí giả sử rằng mỗi nút thu thập một phần riêng biệt của trang web, các thông tin thu đƣợc vẫn có thể bị trùng lặp về các URL và nội dung. Vì không có kho dữ liệu Seen-URL và Seen-Content duy nhất, nên các nút phải kết nối với nhau và quyết định thông tin nào URL là mới hoặc trang nào là trang mới. Và đó là một điểm vô cùng quan trọng để giữ chi phí kết nối là nhỏ nhất vì có thể có tới hàng ngàn kết nối từ các nút thu thập thông tin trang web toàn trên toàn cầu với tốc độ rất nhanh. Sử dụng giao thức dựa trên DHT giúp thời gian tìm kiếm đạt đƣợc giá trị O(logn), trong đó n là tổng số nút.
Điều quan trọng cần chú ý ở đây là hai thành phần trên là hai thành phần không đƣợc tách rời nhau. Nếu có lƣợc đồ phân chia công việc tốt, thì có thể giúp giải quyết các vấn đề về trùng lặp.
2.3.2 Khảo duyệt web dựa trên mạng ngang hàng
Trong những năm gần đây, hầu hết các nghiên cứu về hệ thống mạng ngang hàng đều nhằm mục tiêu cải thiện hiệu năng tìm kiếm. Đi đầu trong hệ thống ngang hàng là giao thức Chord, CAN, Pastry and Tapestry. Các giao thức này về cơ bản dựa trên DHT, nhƣng khác nhau về thuật toán và chi tiết thực hiện. Tất cả các giao thức này đều lƣu trữ việc ánh xạ giữa khóa với giá trị đƣợc phân phối trên mạng hơn là lƣu trữ chúng tại các nút đơn lẻ giống nhƣ bảng băm thông thƣờng. Điều này đạt đƣợc do duy trì bảng định tuyến nhỏ tại mỗi nút. Ngoài ra, với một khóa biết trƣớc, các giao thức này đảm bảo tính cục bộ giá trị khóa theo số lƣợng các hop đã đƣợc giới hạn trong mạng. Để đạt đƣợc điều này, mỗi nút đƣợc gán một số định danh và chịu trách nhiệm đối với một tập các khóa. Việc gán này đƣợc thực hiện bằng việc chuẩn hóa khóa và định danh của nút để chỉ cách nhau bởi một dấu cách thông thƣờng (giống nhƣ băm chúng sử dụng cùng một hàm băm) và có chính sách
dựa trên mức độ tin cậy hoặc khoảng cách gần nhau giữa hai định danh nút, để xác định khu vực nào là do nút nào chịu trách nhiệm.
Ví dụ, xét ứng dụng chia sẻ file, khóa có thể là tên file và định danh có thể là địa chỉ IP của các nút tham gia. Tất cả địa chỉ IP của các nút tham gia đƣợc băm bằng việc sử dụng hàm băm và kết quả đƣợc lƣu trong bảng định tuyến nhỏ (ví dụ, đối với giao thức Chord, bảng định tuyến chỉ có m thực thể cho hàm băm m bit nhƣ đƣợc mô tả tại chƣơng 2) để định vị các nút. Giờ đây, để định định vị một file cụ thể, tên file đƣợc băm ra sử dụng cùng hàm băm và phụ thuộc vào chính sách trên, các nút chịu trách nhiệm đối với file mà mình thu đƣợc. Thao tác xác định vị trí nút phù hợp đƣợc gọi là thao tác tìm kiếm (lookup).
Một hệ thống ngang hàng dựa trên DHT sẽ cần đảm bảo các yếu tố sau: - Hoạt động tìm kiếm một khóa k bất kỳ đƣợc đảm bảo tìm kiếm thành công
khi và chỉ khi dữ liệu tƣơng ứng với khóa k có trong hệ thống.
- Hoạt động tìm kiếm đƣợc đảm bảo kết thúc trong một số lần nhỏ và hữu hạn các bƣớc nhảy (hop).
- Không gian định danh khóa đƣợc phân chia đồng nhất giữa tất cả các nút đang hoạt động.
- Hệ thống có khả năng quản lý động việc gia nhập và rời khỏi hệ thống của các nút.
Apoidea sử dụng giao thức gần giống với giao thức Chord [3], vì tính đơn giản trong quá trình thực hiện. Trong giao thức Apoidea, chúng ta có hai loại khóa là các địa chỉ URL và nội dung trang (page content). Thuật ngữ nút chịu trách đối với một địa chỉ URL cụ thể, có nghĩa là URL có thể đƣợc khảo duyệt bởi nút và
thuật ngữ nút chịu trách nhiệm đối với nội dung trang là nút chịu trách nhiệm khảo duyệt nội dung trang web đó, điều này cũng đồng nghĩa với việc nút đó có thông tin về trang web đó cho dù nội dung trang web đã đƣợc tải về bởi một nút khác (có thể đã có trong quá trình khảo duyệt một trang web nhân bản khác đã có một nút tải nội dung trang web này về, lúc này nút chịu trách nhiệm nội dung sẽ lƣu thông tin nút đã tải nội dung mà không thực hiện tải lại trang này).
Quá trình thực hiện tìm kiếm URL thuộc nút nào chịu trách nhiệm đƣợc thực hiện theo các bƣớc sau. Ðầu tiên, thực hiện băm tên miền (domain) của URL. Thực hiện tìm kiếm theo giá trị băm của tên miền trên và kết quả trả về là địa chỉ IP của nút chịu trách nhiệm đối với URL này. Lƣu ý rằng lựa chọn này sẽ cho kết quả tên miền trên đƣợc khảo duyệt chỉ bởi một nút trong hệ thống. Theo cách thiết kế này,
nút sử dụng tham số connection-alive của giao thức HTTP và sử dụng socket TCP/IP trong lúc tải nhiều trang từ một tên miền cụ thể. Điều này giúp việc khảo duyệt web nhanh lên đáng kể do tiết kiệm chi phí thiết lập kết nối TCP/IP tới tên miền, mỗi khi khảo duyệt URL chỉ thực hiện trên giá trị băm URL và tìm kiếm trên giá trị băm đó.
Nội dung trang web đƣợc sử dụng làm khoá khi cần kiểm tra tính trùng lặp của các trang tải về. Đối với trƣờng hợp này, nội dung trang đƣợc băm ra và tìm kiếm ngay từ đầu để lấy đƣợc nút nào chịu trách nhiệm về nội dung trang web này. Lƣu ý rằng, trang web có thể (và trong hầu hết các trƣờng hợp khác) đƣợc tải xuống bởi một nút khác (vì điều này dựa trên việc tìm kiếm theo tên miền của URL). Nút chịu trách nhiệm nội dung của trang web nào thì chỉ duy trì thông tin mà không lƣu trữ toàn bộ trang đó. Điều này đồng nghĩa với nút chịu trách nhiệm nội dung của trang có thể không tải trang web về khi đã có nút khác đã thực hiện tải trang web mà chỉ lƣu trữ thông tin nội dung trang web đó đã đƣợc nút nào tải xuống. (adsbygoogle = window.adsbygoogle || []).push({});
Ngoài ra, do bản chất của mạng ngang hàng, giao thức cần quản lý các nút động tham gia và rời khỏi hệ thống. Bất cứ khi nào một nút mới gia nhập vào hệ thống, nó cần đăng ký chịu trách nhiệm đối với một phần nhất định trong không gian khoá. Trong trƣờng hợp khảo duyệt web, nút mới đƣợc gán với những tên miền mà băm vào không gian khoá. Các nút phải chịu trách nhiệm đối với những tên miền mà đã đƣợc yêu cầu gửi thông tin về danh sách các URL đã đƣợc khảo duyệt trong danh sách tên miền sang nút vừa mới gia nhập. Một kỹ thuật tƣơng tự đƣợc sử dụng để phát hành lại thông tin chữ ký của trang.
Khi một nút P muốn rời khỏi mạng, nó sẽ gửi toàn bộ URL và thông tin về nội dung trang hiện tại cho các nút khác. Tuy nhiên, nếu nút P bị lỗi thì nó không thể gửi đƣợc bất kỳ thông tin nào cho các nút khác; tức là thông tin về các khoá mà nút P nắm giữ tạm thời bị mất. Vấn đề này đƣợc xử lý bằng việc sao chép lại thông tin. Mọi tên miền D đƣợc ánh xạ với nhiều khoá (k1, k2,..., kr), các khoá này đƣợc quản lý bởi nhiều nút riêng biệt. Tuy nhiên chỉ có nút nào chịu trách nhiệm với khoá k1 (bản sao chính) thì sẽ thực hiện khảo duyệt tên miền D. Các nút khác chịu trách nhiệm đối với khoá sao phụ (các khoá k2, k3..., kr) sẽ đơn giản thực hiện lƣu trữ thông tin nhƣ URL nào thuộc tên miền nào đã đƣợc khảo duyệt hay chƣa. Tuy nhiên, nếu nút chịu trách nhiệm với bản sao chính bị ngừng hoạt động, thông tin liên quan đến nút đó nắm giữ vẫn có thể khôi phục lại đƣợc bằng việc sử dụng một trong các bản sao phụ của nó. Vì mục đích là tính đơn giản, giả thiết rằng chỉ có một khoá cho một tên miền trong phần còn lại của bài báo.
2.3.3 Xử lý trùng lặp URL bằng bộ lọc Bloom
Các bộ lọc bloom là tiện ích dùng hỗ trợ cho việc truy vấn các thành phần khoá K = {k1, k2,..., kn}. Ý tƣởng chính của bộ lọc là sử dụng vector m bit, có giá trị khởi tạo ban đầu là 0 và chọn l hàm băm độc lập H1, H2, ..., H l thuộc khoảng {0, 1,..., m-1}. Đối với bất kỳ giá trị k K, toạ độ bit H1(k), H2(k), ..., Hl(k) đƣợc thiết lập bằng một. Lƣu ý rằng tọa độ bit có thể đƣợc đặt về 1 hoặc nhiều 1 khoá. Giờ đây, việc kiểm tra một thành viên đƣợc thực hiện theo các bƣớc sau. Với khoá
k biết trƣớc, chúng ta có thể kiểm tra các bit ở tọa độ H1(k), H2(k),..., Hl(k) trên vector m. Nếu bất một trong các giá trị trên bằng 0, thì giá trị k K.
Ví dụ minh họa trong hình vẽ 9 về bộ lọc Bloom có m = 18, k = 3. Tập khóa
K = {k1, k2, k3}, các khóa này đƣợc băm và có giá trị là các màu xanh, đỏ, tím tƣơng ứng với giá trị 1 trong mảng bit. Khóa k4không thuộc trong tập K, vì giá trị băm trong mảng có giá trị bằng 0.
Hình 9. Bộ lọc bloom với k = 3
Nhƣng trong một số trƣờng hợp, khoá k cho trƣớc k K, nhƣng qua bộ lọc bloom sẽ cho kết quả sai tức k K. Điều này đƣợc gọi là giả thiết sai.
Tính năng nổi trội của bộ lọc bloom trên thực tế là cân bằng đƣợc không gian (trade off space) đối với cả xác suất xảy ra là trƣờng hợp giả thiết sai. Trong bài báo [7] nếu sử dụng số hàm băm khác nhau là l = ln2*(m/n) với m là kích thƣớc bộ lọc Bloom và n là số lƣợng tài liệu, giúp giảm xác suất giả thiết sai xuống (0.6185)m/n
. Chúng ta có thể đạt đƣợc xác suất giả thiết sai xuống thấp bằng 0.001 với l = 5 hàm băm độc lập khác nhau và m/n = 10.
Áp dụng vào trong vấn đề khảo duyệt web, có thể sử dụng bộ lọc bloom để duy trì thông tin về URL đã đƣợc thu thập hoặc chƣa đƣợc thu thập. Toàn bộ URL đã đƣợc khảo duyệt tạo thành tập K. Giờ đây, để kiểm tra một URL là địa chỉ mới,
chúng ta băm giá trị k và sau đó kiểm tra k có thuộc K không. Việc này sẽ đƣợc thực hiện dù URL đã đƣợc khảo duyệt rồi hay chƣa. Giả sử rằng WWW có tới 4 tỷ trang và thiết lập giá trị m/n = 10 kích thƣớc bộ lọc sẽ bằng 4*230
*10 bit tức 5 GB. Lƣu ý rằng bất kỳ việc thực hiện nào trên bộ lọc cần xử lý quá trình lọc trong bộ nhớ chính. Do đó, sẽ không thể để bộ lọc bloom đáp ứng phạm vi WWW trên một máy tính duy nhất. Trong thiết kế của tác giả [3], tác giả chia các URL trên WWW trên nhiều các nút cộng tác với nhau. Giả sử rằng chúng ta có 1000 nút tham gia ở các vị trí địa lý khác nhau thì mỗi nhóm nút xử lý khoảng 4 triệu trang web, nhƣ vậy bộ lọc bloom cần có kích thƣớc là 5 MB. Với công nghệ ngày này, mỗi nút có đủ khả năng để duy trì bộ lọc bloom 5 MB trong bộ nhớ chính của mình.
2.3. Kiến trúc khảo duyệt Apoidea 2.3.1 Kiến trúc hệ thống Apoidea