Chương 3: Nutch - Ứng dụng Search Engine phân tán trên nền tảng Hadoop
3.5.3 Áp dụng tính toán phân tán cho Searcher
Một hướng tự nhiên mà ai cũng nghĩ tới là chúng ta cũng sẽ sử dụng MapReduce để tìm kiếm phân tán trên tập index lưu trữ trên HDFS. Tuy nhiên, điều này mang lại một số bất lợi mà ta sẽ cùng khảo sát dưới sây. Sau đó, chúng tôi sẽ giới thiệu một giải pháp thật sự cho vấn đề tìm kiếm phân tán.
3.5.3.1 Hạn chế của việc sử dụng MapReduce để tìm kiếm chỉ mục trên HDFS
Việc sử dụng MapReduce để tìm kiếm tập chỉ mục trên HDFS sẽ diễn ra theo mô hình sau:
Đầu tiên, một trình Search Font-End nào đó sẽ nhận truy vấn từ người dùng và khởi tạo một MapReduce Job (xem lại phần 2.3.2.2.2. , cơ chế hoạt động MapReduce Engine) để gửi đến JobTracker thực thi. JobTracker sẽ phân Job này ra thành nhiều Map task và một Reduce task. Các task này sẽ được phân công cho các TaskTracker, TaskTracker sẽ khởi tạo và thực thi các task này.
Mỗi Map Task này sẽ thực hiện tìm kiếm trên 1 phần split tập chỉ mục, dò tìm trên phần split này các khớp với query tìm kiếm. Nhờ cơ chế locality nên thông thường phần split này sẽ nằm cùng máy vật lý với Task thực thi.
Reduce Task duy nhất sẽ thực hiện tổng hợp kết quả và ghi ra một file output trên HDFS.
Quá trình trên vấp phải một số bất tiện sau:
Việc xử lý một MapReduce Job đi theo quá trình sau: JobTracker nhận MapReduce job từ client (ở đây là các yêu cầu truy vấn) Search Font-End và đưa vào một hàng đợi các job để chờ thực thi. Tới lượt thực thi, JobTracker sẽ phân Job này ra các task và giao cho các TaskTracker xử lý. TaskTracker sẽ khởi tạo và thực thi các
82
task. Quá trình này sẽ tạo ra một độ trễ do thời gian chờ job nằm trong hàng đợi, thời gian khởi tạo các task. Độ trễ này tuỳ theo phần cứng cụ thể mà mất khoảng vài giây hoặc lâu hơn. Độ trễ này không có nhiều ý nghĩa với các MapReduce job thông thường (là các job mà thời gian xử lý lên đến hàng giờ, hàng ngày, hàng tuần).Tuy nhiên, chúng ta đều biết thời gian thực thi truy vấn với Search Eninge có ý nghĩa tới từng giây. Độ trễ này sẽ ảnh hưởng nghiêm trọng tới thời gian thực thi truy vấn và làm cho thời gian đáp ứng của truy vấn không còn chấp nhận được nữa.
Hình 3-8: Quá trình truy vấn chỉ mục bằng MapReduce
Thứ hai, trên hệ thống, crawler luôn chạy. Và lúc đó, việc chạy Searher bằng MapReduce trên cùng cluster với crawler sẽ gây ra tình trạng tranh giành tài nguyên:
tài nguyên băng thông khi các task truy vấn và các task cho quá trình crawl cùng thực hiện. Tài nguyên RAM và CPU trên các TaskTracker khi TaskTracker phải thực hiện
83
nhiều task cùng một lúc. Đương nhiên điều này sẽ làm giảm đi thời gian thực thi của cả task thực hiện tìm kiếm và task thực hiện query.
Với những bất tiện kể trên, thì Nutch đã không khuyến kích việc tìm kiếm phân tán tập index bằng MapReduce trên HDFS. Thực chất, Nutch không đã cài đặt chức năng này. Thay vào đó, Nutch đưa ra một giải pháp tiềm kiếm phân tán khác. Đó là các Search server.
3.5.3.2 Search server
Với giải pháp này, tập chỉ mục trên HDFS sẽ được bổ ra thành nhiều phần nhỏ, mỗi phần sẽ lưu trữ trên một server chuyên phục vụ tìm kiếm: Search server. Các Search server này sẽ không nằm trong Hadoop cluster mà sẽ chạy độc lập. Các Search server lưu trữ phần index của nó trên hệ thống tập tin cục bộ của nó. Với ưu điểm của hệ thống file cục bộ là độ trễ (latency) thấp, các Search server sẽ đáp ứng yêu cầu tìm kiếm rất nhanh. Khi một trình Search Font-End nhận được truy vấn từ người dùng, nó sẽ gửi truy vấn này đến tất cả các search server, nhận kết quả trả về từ các Search server và tổng hợp kết quả để hiển thị cho người dùng.
84
Query
Hình 3-9 Search servers