Lưu trữ văn bản (Text repository) thường là công việc cuối cùng của crawler: gom các trang tìm nạp được vào một nơi lưu trữ. Các thông tin liên quan tới các trang được lưu thành hai phần: Metadata và nội dung trang. Metadata bao gồm các trường như: kiểu nội dung, ngày thay đổi cuối cùng, độ dài nội dung, mã trạng thái HTTP…, thường được quản lý bởi các phần mềm tùy chọn để tránh chi phí cho các hệ quản trị cơ sở dữ liệu quan hệ.
Một trang HTML thông thường 10KB được lưu trữ ạ d ng nén thành 2-4KB (sử dụng zlib), trong khi hầu hết các hệ thống file có kích thước 4-8KB file block size, nên việc lưu trữ ỗ m i file cho mỗi trang được crawled về là không khả thi vì xảy raphân m nh trong ả nhóm file (file block fragmentation). Do đó, lưu trữ trang thường được chuyển thành h ệthống lưu trữtùy chọn, được thiết lập sao cho có thểcung cấp các phương thức truy cập đơn giản cho crawler có th thêm vào các trangể , và cho các chương trình thực thi sau đó (thí dụ ộ đị: b nh ch m c) có th tìm l i ỉ ụ ể ạ được tài li u. ệ Ở các hệ thống kích thước nhỏ, việc lưu trữđược gi i h n bên trong ớ ạ các đĩa của m t ộ máy, có thể ử ụ s d ng trình quản lý lưu trữthông dụng như Berkeley DB, giúp quản lý cơ sở ữ ệ d li u n i trong m t file. N u trang Web mu n truy cộ ộ ế ố ập theo khóa như URL của chúng, cơ sở ữ ệ d li u có thể được cấu hình như là bảng băm ho c ặ cây nhị phân, giúp xử lý tu n t viầ ự ệc truy cập một trang. Nếu như trình xử lý trang sau đó có thể ử x lý các trang theo b t kấ ỳ thứ ự t nào, như trong trường hợp m c cchỉ ụ ủa công c tìm kiụ ếm (search engine indexing), thì cơ sở ữ ệ d li u có thể ấ c u hình như là log tuần tự các bản ghi trang.
Ở các h th ng l n, b ệ ố ớ ộ lưu trữ được phân b trên ổ một số máy chủ lưu trữ ế ố ớ, k t n i t i crawler thông qua mạng cục bộ tốc độ cao (thí dụ: Ethernet gigabit). Crawler có th ể hash mỗi URL ứng với máy chủ lưu trữ ụ c thể và gửi tới URL và nội dung trang.
Để đạt đượ thông lược ng m ng t ng th 40GB trong m t gi hay ạ ổ ể ộ ờ 100Mb trên giây (10 tri u trang trong m t giệ ộ ờ, tương đương với 200 gi cho toàn bờ ộ Web), c n cầ ỡ hai đường leased line m c T3. ứ
- 66 -
Các crawler cỡ ớn thườ l ng sử ụ d ng nhi u ISP và m t ngân ề ộ hàng các máy chủ lưu tr ữ để lưu các trang crawl về được.
2.4.3.11 Làm tươi các trang đã được crawled về
Ch s ỉ ố máy tìm kiếm nên được làm mới, để phản ánh được phiên bản mới nh t cấ ủa tất cả các trang được crawled về. Trong thực tế, các crawler Web không bao giờ
“hoàn thành công vi” ệc của nó, mà chỉ ừng khi đã tậ d p hợp được “ ” đủ các trang.
Các trang có tốc độ thay đổ ội n i dung r t khác nhau. ấ
Hình 2.4 chỉ ra cách sử ụ d ng giao thức Http kiểm tra “If-modified-since” xem một trang có thay đổ ể ừ ời điểm nào đó hay i k t th không, n u có thì tìm nế ạp trang đó, nếu không thì máy chủ ẽ ử s g i mã phản hồi là không thay đổi và không gửi trang đó nữa.
Với một trình duyệt (browser) thì x ử lý đó có thể ữu ích, nhưng vớ h i một crawler thì không giúp được gì, vì vi c giệ ải địa ch máy ch , r i k t n i m t socket TCP t i ỉ ủ ồ ế ố ộ ớ máy chủ ẽ ấ s m t m t kho ng th i gian, là lộ ả ờ ớn đố ới v i vi c crawl. ệ
Hình 2.4: Sử ụ d ng truy vấn header “If-modified-since” kiđể ểm tra xem một trang có c n crawled l i ầ ạ hay không. Trong trường h p c th này thì không c n. ợ ụ ể ầ
Khi một vòng crawling m i bớ ắt đầu, th t rõ ràng n u bi t rậ ế ế ằng trang nào đã được thay đổ ể ừ ầi k t l n crawl cu i cùng, và ch tìm n p nhố ỉ ạ ững trang đó. Điều này là kh ả
- 67 -
thi trong một số ít trường h p: sợ ử ụng tiêu đề d ph n hả ồi Http Expires, như trong hình bcd:
Hình 2.5 M: ột số site với các thông tin nhanh v thề ời gian gửi một thuộc tính Expires trong tiêu đề ph n h i Http. ả ồ
Với các trang không có thông tin về expiration date, ta cần dự đoán xem việc thăm l i ạ có thể thấy được phiên bản mới hay không. Một crawler có thể truy cập một số thông tin kiểu như điểm ph n ánh khả ả năng một trang có thay đổi hay không, từ đó, nó sẽ tìm nạp các URL theo thứ ự ả t gi m dần của các giá trị điểm đó. Vi c xây dệ ựng ước lượng có th d a trên gi thuyể ự ả ết: “quá kh có th d ứ ể ự đoán tương lai” (recent past predicts the future).
Việc ước lượng tốc đ thay đổ ủa trang đượộ i c c Brewington và Cybenko & Cho đưa ra: Thuật toán nhằm duy trì một crawl trong đó hầu hết các trang là mới hơn so với một thời điểm cụ th . ể Điều kiện tiên quyếtlà khoảng trung bình giữa các lần kiểm tra của crawler thay đổi nhỏ hơn kho ng ả thời gian ữ gi a các l n ầ trang đó thay đổi.
Hầu hết các công cụ tìm kiếm không c g ng cho vi c craw toàn b r i m i c p ố ắ ệ ộ ồ ớ ậ nhật các chỉ ố ủ s c a nó. Giữa hai lần crawling toàn bộ, các crawler với kích thước nh ỏ hơn được thực thi để theo dõi các site có tốc đ thay đổi nhanh, như là các ộ
- 68 -
trang tin t c, th i tiứ ờ ết… và các kết quả ừ t các ch s ỉ ố này có thể được gắn thêm vào chỉ ố ổ s t ng th ể(master index).
2.4.4 Tập h p l i thành mợ ạ ột Crawler
T ổ chức World Wide Web Consortium (www.w3c.org/) đã công bố thực thi tham kh o ả của giao thức HTTP clienttrong gói w3c-libwww, gói này được viết trên C và có th th c thi h u hể ự ở ầ ết các hệ điều hành.
Việc xây dựng crawler bắt đầu với một thành phần nhân - thực hiện sao chép các byte từ socket mạng vào bộ lưu trữ, đó là lớp Crawler. L p Crawler ớ có các phương thức sau đây để chỉ rõ giao ước của crawler với người dùng: nh p ậ một URL để tìm nạp vào crawler (fetchPush); trình x lý k t thúc callback (fetchDone) s ử ế ẽ được g i ọ với cùng URL đókèm theo các tham số hương thức (bắt đầu), khởi động vòng lặp ; p sự kiện (event loop) của crawler. Thực thi của lớp Crawler còn cầ hai lớp hỗ trợ là n DNS và Fetch.
2.4.5 Tóm lược
Việc crawling ở ứ m c độWeb là một vấn đềthu hút nhiều người sử ụng và các nhà d nghiên cứu, tuy nhiên, đó cũng là bí mật công ngh tài sệ - ản c a các công ty lủ ớn về Web hiện nay. Kích thước của Web cũng là một con s rố ất khó xác định, vì độ ớ l n thực và cả ự tăng trưở s ng liên tục của Web. Hiện nay, có nhiều gói mã mở, phục vụ cho vi c crawling theo các mệ ục đích khác nhau, thí dụ w3c-libwww - đã được phổ bi n, và có th dùng cho các ng d ng t m trung. ế ể ứ ụ ầ