Tìm kiếm đàn hồi, nhân sư, Lucene, Solr, Xapian. Mà phù hợp cho việc sử dụng? [đóng cửa]

Tôi hiện đang xem xét các phương pháp tìm kiếm khác thay vì có một truy vấn SQL lớn. Tôi đã thấy elaticsearch gần đây và chơi với whoosh (một triển khai Python của công cụ tìm kiếm).

Bạn có thể đưa ra lý do cho sự lựa chọn của bạn?

Là người tạo ra ElasticSearch, có lẽ tôi có thể cung cấp cho bạn một số lý do tại sao tôi lại tiếp tục và tạo nó ở vị trí đầu tiên :).

Sử dụng Lucene nguyên chất là một thách thức. Có rất nhiều điều bạn cần quan tâm nếu bạn muốn nó thực sự hoạt động tốt, và đó cũng là một thư viện, vì vậy không có hỗ trợ phân tán, đó chỉ là một thư viện Java nhúng mà bạn cần duy trì.

Về khả năng sử dụng Lucene, trở lại khi (gần 6 năm nay), tôi đã tạo ra La bàn. Mục đích của nó là đơn giản hóa việc sử dụng Lucene và làm cho Lucene đơn giản hơn mỗi ngày. Điều tôi tình cờ gặp lại là yêu cầu để có thể phân phối La bàn. Tôi bắt đầu làm việc với nó từ bên trong La bàn, bằng cách tích hợp với các giải pháp lưới dữ liệu như GigaSpaces, Coherence và Terracotta, nhưng điều đó là không đủ.

Tại cốt lõi của nó, một giải pháp Lucene phân tán cần phải được loại bỏ. Ngoài ra, với sự tiến bộ của HTTP và JSON là các API phổ biến, điều đó có nghĩa là một giải pháp mà nhiều hệ thống khác nhau với các ngôn ngữ khác nhau có thể dễ dàng được sử dụng.

Đây là lý do tại sao tôi đã tiếp tục và tạo ra Tìm kiếm đàn hồi. Nó có một mô hình phân tán rất tiên tiến, nói JSON nguyên bản và hiển thị nhiều tính năng tìm kiếm nâng cao, tất cả được thể hiện liền mạch thông qua JSON DSL.

Solr cũng là một giải pháp để hiển thị máy chủ lập chỉ mục / tìm kiếm qua HTTP, nhưng tôi cho rằng ElasticSearch cung cấp một mô hình phân tán vượt trội và dễ sử dụng (mặc dù hiện tại thiếu một số tính năng tìm kiếm, nhưng không lâu, và trong bất kỳ trong trường hợp, kế hoạch là đưa tất cả các tính năng La bàn vào ElasticSearch). Tất nhiên, tôi thiên vị, vì tôi đã tạo ElasticSearch, vì vậy bạn có thể cần phải tự kiểm tra.

Đối với Nhân sư, tôi chưa sử dụng nó, vì vậy tôi không thể bình luận. Những gì tôi có thể giới thiệu cho bạn là chủ đề này tại diễn đàn Sphinx mà tôi nghĩ đã chứng minh mô hình phân tán vượt trội của ElasticSearch.

Tất nhiên, ElasticSearch có nhiều tính năng hơn là chỉ được phân phối. Nó thực sự được xây dựng với một đám mây trong tâm trí. Bạn có thể kiểm tra danh sách tính năng trên trang web.

Tôi đã sử dụng Sphinx, Solr và Elaticsearch. Solr / Elaticsearch được xây dựng trên đỉnh Lucene. Nó bổ sung nhiều chức năng phổ biến: api máy chủ web, faceting, bộ nhớ đệm, v.v.

Nếu bạn muốn có một thiết lập tìm kiếm toàn văn đơn giản, Sphinx là một lựa chọn tốt hơn.

Nếu bạn muốn tùy chỉnh tìm kiếm của mình, Elaticsearch và Solr là những lựa chọn tốt hơn. Chúng rất mở rộng: bạn có thể viết các plugin của riêng mình để điều chỉnh kết quả tính điểm.

Một số ví dụ sử dụng:

• Nhân sư: craigslist.org
• Solr: Cnet, Netflix, digg.com
• Elaticsearch: Foursquare, Github

Chúng tôi sử dụng Lucene thường xuyên để lập chỉ mục và tìm kiếm hàng chục triệu tài liệu. Tìm kiếm đủ nhanh và chúng tôi sử dụng các cập nhật gia tăng mà không mất nhiều thời gian. Chúng tôi đã mất một thời gian để đến đây. Điểm mạnh của Lucene là khả năng mở rộng, nhiều tính năng và cộng đồng các nhà phát triển tích cực. Sử dụng Lucene trần đòi hỏi phải lập trình trong Java.

Nếu bạn đang bắt đầu từ đầu, công cụ dành cho bạn trong gia đình Lucene là Solr , dễ cài đặt hơn nhiều so với Lucene trần và có gần như toàn bộ sức mạnh của Lucene. Nó có thể nhập tài liệu cơ sở dữ liệu dễ dàng. Solr được viết bằng Java, vì vậy mọi sửa đổi của Solr đều cần có kiến ​​thức về Java, nhưng bạn có thể làm được rất nhiều chỉ bằng cách điều chỉnh các tệp cấu hình.

Tôi cũng đã nghe những điều tốt về Sphinx, đặc biệt là kết hợp với cơ sở dữ liệu MySQL. Chưa sử dụng nó, mặc dù.

IMO, bạn nên chọn theo:

• Các chức năng cần thiết - ví dụ: bạn có cần một thân cây Pháp không? Lucene và Solr có một, tôi không biết về những người khác.
• Thành thạo ngôn ngữ triển khai - Không chạm vào Java Lucene nếu bạn không biết Java. Bạn có thể cần C ++ để làm công việc với Sphinx. Lucene cũng đã được chuyển sang các ngôn ngữ khác . Điều này chủ yếu là quan trọng nếu bạn muốn mở rộng công cụ tìm kiếm.
• Dễ thử nghiệm - Tôi tin rằng Solr là tốt nhất trong khía cạnh này.
• Giao diện với các phần mềm khác - Sphinx có giao diện tốt với MySQL. Solr hỗ trợ các giao diện ruby, XML và JSON như một máy chủ RESTful. Lucene chỉ cung cấp cho bạn quyền truy cập theo chương trình thông qua Java. La bàn và Hibernate Search là các hàm bao của Lucene tích hợp nó vào các khung lớn hơn.

Chúng tôi sử dụng Sphinx trong dự án Tìm kiếm dọc với 10.000.000 bản ghi MySql và hơn 10 cơ sở dữ liệu khác nhau. Nó đã nhận được sự hỗ trợ rất tuyệt vời cho MySQL và hiệu suất cao về lập chỉ mục, nghiên cứu nhanh nhưng có thể ít hơn một chút so với Lucene. Tuy nhiên, đó là lựa chọn đúng đắn nếu bạn cần lập chỉ mục nhanh chóng mỗi ngày và sử dụng db MySQL.

Một thử nghiệm để so sánh ElasticSearch và Solr

Nhân sư của tôi

source post_source 
{
    type = mysql

    sql_host = localhost
    sql_user = ***
    sql_pass = ***
    sql_db =   ***
    sql_port = 3306

    sql_query_pre = SET NAMES utf8
    # query before fetching rows to index

    sql_query = SELECT *, id AS pid, CRC32(safetag) as safetag_crc32 FROM hb_posts


    sql_attr_uint = pid  
    # pid (as 'sql_attr_uint') is necessary for sphinx
    # this field must be unique

    # that is why I like sphinx
    # you can store custom string fields into indexes (memory) as well
    sql_field_string = title
    sql_field_string = slug
    sql_field_string = content
    sql_field_string = tags

    sql_attr_uint = category
    # integer fields must be defined as sql_attr_uint

    sql_attr_timestamp = date
    # timestamp fields must be defined as sql_attr_timestamp

    sql_query_info_pre = SET NAMES utf8
    # if you need unicode support for sql_field_string, you need to patch the source
    # this param. is not supported natively

    sql_query_info = SELECT * FROM my_posts WHERE id = $id
}

index posts 
{
    source = post_source
    # source above

    path = /var/data/posts
    # index location

    charset_type = utf-8
}

Kịch bản thử nghiệm:

<?php

    require "sphinxapi.php";

    $safetag = $_GET["my_post_slug"];
//  $safetag = preg_replace("/[^a-z0-9\-_]/i", "", $safetag);

    $conf = getMyConf();

    $cl = New SphinxClient();

    $cl->SetServer($conf["server"], $conf["port"]);
    $cl->SetConnectTimeout($conf["timeout"]);
    $cl->setMaxQueryTime($conf["max"]);

    # set search params
    $cl->SetMatchMode(SPH_MATCH_FULLSCAN);
    $cl->SetArrayResult(TRUE);

    $cl->setLimits(0, 1, 1); 
    # looking for the post (not searching a keyword)

    $cl->SetFilter("safetag_crc32", array(crc32($safetag)));

    # fetch results
    $post = $cl->Query(null, "post_1");

    echo "<pre>";
    var_dump($post);
    echo "</pre>";
    exit("done");
?>

Kết quả mẫu:

[array] => 
  "id" => 123,
  "title" => "My post title.",
  "content" => "My <p>post</p> content.",
   ...
   [ and other fields ]

Thời gian truy vấn nhân sư:

0.001 sec.

Thời gian truy vấn nhân sư (đồng thời 1k):

=> 0.346 sec. (average)
=> 0.340 sec. (average of last 10 query)

Thời gian truy vấn MySQL:

"SELECT * FROM hb_posts WHERE id = 123;"
=> 0.001 sec.

Thời gian truy vấn MySQL (đồng thời 1k):

"SELECT * FROM my_posts WHERE id = 123;" 
=> 1.612 sec. (average)
=> 1.920 sec. (average of last 10 query)

Sự so sánh hiệu suất duy nhất giữa elearchearch và solr mà tôi có thể tìm thấy cho đến nay là ở đây:

Solr vs elaticsearch Deathmatch!

Lucene là tốt đẹp và tất cả, nhưng bộ từ dừng của họ là khủng khiếp. Tôi đã phải tự thêm một tấn từ dừng vào StopAnalyzer.ENG setup_STOP_WORDS_SET chỉ để có được nó ở bất cứ đâu gần có thể sử dụng được.

Tôi chưa sử dụng Sphinx nhưng tôi biết mọi người chửi thề bởi tốc độ và tỷ lệ "dễ thiết lập đến kỳ diệu" của nó.

Hãy thử indextank.

Như trường hợp tìm kiếm đàn hồi, nó được cho là dễ sử dụng hơn nhiều so với lucene / solr. Nó cũng bao gồm hệ thống tính điểm rất linh hoạt có thể được điều chỉnh mà không cần reindexing.