2011-01-14 30 views
5

Tôi đang sử dụng Lucene 3.0.3. Tôi đã tạo một bean Spring nhằm đóng gói tất cả các hoạt động trên cùng một chỉ mục.Cam kết thay đổi hiển thị trong Lucene. Các phương pháp hay nhất

public class IndexOperations { 

    private IndexWriter writer; 
    private IndexReader reader; 
    private IndexSearcher searcher; 

    public void init() {...} 
    public void destroy() {...} 

    public void save(Document d) {...} 
    public void delete(Document d) {...} 
    public List<Document> list() {...} 

} 

Để cho phép thay đổi nhanh chóng và tìm kiếm, tôi cho rằng việc viết, đọc và tìm kiếm mở có thể là một ý tưởng hay. Nhưng vấn đề là những thay đổi cam kết về nhà văn không thể được nhìn thấy bởi độc giả cho đến khi mở lại. Và hoạt động này có thể tốn kém, vì vậy có thể không phải là một ý tưởng hay cho các tìm kiếm nhanh.

Cách tiếp cận tốt nhất cho trường hợp điển hình này là gì?

Trả lời

4

Bạn nên giữ cho người viết luôn mở, nhưng không tiếp tục đọc/tìm kiếm. Khi bạn cần một người tìm kiếm chỉ cần làm IndexSearcher srch = new IndexSearcher(writer.getReader()); Bằng cách này, người tìm kiếm sẽ nhận được những thay đổi gần đây nhất, ngay cả khi họ chưa được chuyển sang đĩa chưa (cung cấp cho bạn tốt nhất của cả hai thế giới).

+0

@ Xoradap: Ý tưởng hay, tôi không nghĩ về nó. Nhưng điều này sẽ không tốn kém khi chỉ số lớn? – sinuhepop

+0

@Sinuhe: Không, đây là cách được khuyến nghị để thực hiện. Các nhà văn sẽ tuôn ra đĩa như là cần thiết. – Xodarap

+0

@Xoradap: sau nhiều lần kiểm tra, phương pháp của bạn rất tuyệt! Cảm ơn. – sinuhepop

2

Đối với loại trường hợp sử dụng này, tôi rất khuyên bạn nên Compass, đây là một sự trừu tượng cấp cao hơn xung quanh Lucene. Cụ thể cho câu hỏi của bạn, nó cung cấp kiểm soát đồng thời tốt hơn, cộng với các giao dịch, làm giảm sự cần thiết phải tự kiểm soát người đọc/nhà văn/người tìm kiếm vấn đề mà bạn có. Đó là công cụ khá thông minh, và thành thật mà nói nó có thể là khá baroque, nhưng đó là một giải pháp tốt cho vấn đề. Mặt khác, nó dựa trên Lucene 2.9 chứ không phải 3.0, vì vậy nó không nhanh như 3.0 có thể được, và nó không còn được duy trì tích cực, nhưng nó ổn định, khá tài liệu và dễ sử dụng hơn nhiều so với raw Lucene.

+1

Tôi đã đọc về La bàn và Solr. Tôi nghĩ chúng không cần thiết cho những trường hợp sử dụng rất đơn giản này, và có lẽ chúng đang mở và đóng những vật thể này giống như cách tôi sẽ làm. Về Compass, tôi hơi chán nản vì những lý do bạn nói, nhưng có lẽ tôi sẽ thử một lần nữa. Cảm ơn. – sinuhepop

+0

@Sinuhe: Chắc chắn, không cần thiết. Nó sẽ làm cho công việc của bạn dễ dàng hơn, mặc dù. – skaffman

+0

chỉ là một lưu ý phụ: elasticsearch là la bàn 3.0 :) thử nó. nó sử dụng một lucene gần đây hơn so với solr nào vv – Karussell

Các vấn đề liên quan