ElasticSearch, Sphinx, Lucene, Solr, Xapian. Що підходить для якого використання? [зачинено]

Зараз я розглядаю інші методи пошуку, а не величезний SQL-запит. Нещодавно я бачив еластичний пошук і грав з whoosh (реалізацією пошукової системи Python).

Чи можете ви навести причини свого вибору?

Як творець ElasticSearch, можливо, я можу дати вам кілька міркувань, чому я пішов уперед і створив це в першу чергу :).

Використання чистого луцену є складним завданням. Є багато речей, над якими потрібно подбати, якщо ви хочете, щоб він справді працював добре, а також його бібліотека, тому немає розподіленої підтримки, це просто вбудована бібліотека Java, яку потрібно підтримувати.

З точки зору зручності використання люцена, я повернувся назад, коли (майже 6 років) я створив компас. Її метою було спростити використання люцена та зробити щоденний люцен простішим. Що я знову і знову стикався - це вимога мати можливість поширювати компас. Я почав працювати над цим із Compass, інтегруючись з такими рішеннями, як GigaSpaces, Coherence та Terracotta, але цього недостатньо.

По суті, розподілений луценовий розчин потрібно подрібнити. Крім того, з просуванням HTTP та JSON як всюдисущих API, це означає, що рішення, що багато різних систем з різними мовами можна легко використовувати.

Ось чому я пішов вперед і створив ElasticSearch. Він має дуже вдосконалену модель розподілення, розмовляє JSON рідно та відкриває безліч розширених функцій пошуку, які все чітко виражені через JSON DSL.

Solr також є рішенням для відкриття сервера індексації / пошуку через HTTP, але я стверджую, що ElasticSearch забезпечує значно покращену розподілену модель і простоту використання (хоча в даний час не вистачає деяких функцій пошуку, але не надовго, а в будь-якій У випадку, план полягає в тому, щоб отримати весь Компас функції перейти в ElasticSearch. Звичайно, я упереджений, оскільки створив ElasticSearch, тому вам, можливо, доведеться перевірити себе.

Щодо Сфінкса, я не користувався ним, тому не можу коментувати. Те, що я можу посилатись на вас, - це ця тема на форумі Sphinx, що, на мою думку, підтверджує чудову модель розподілу ElasticSearch.

Звичайно, ElasticSearch має набагато більше можливостей, ніж просто розповсюдження. Він фактично побудований з врахуванням хмари. Ви можете перевірити список функцій на сайті.

Я використовував Сфінкса, Солра та Еластичного дослідження. Solr / Elasticsearch побудовані на вершині Луцена. Це додає багато загальних функціональних можливостей: api веб-сервера, облицювання, кешування тощо.

Якщо ви хочете просто встановити повний повний текст пошуку, Sphinx - кращий вибір.

Якщо ви хочете взагалі налаштувати свій пошук, кращий вибір - Elasticsearch та Solr. Вони дуже розширювані: ви можете написати власні плагіни, щоб налаштувати підрахунок результатів.

Деякі приклади звичаїв:

• Сфінкс: craigslist.org
• Solr: Cnet, Netflix, digg.com
• Еластичний пошук: Четвертий, Гітхуб

Ми регулярно використовуємо Lucene для індексації та пошуку десятків мільйонів документів. Пошуки проходять досить швидко, і ми використовуємо додаткові оновлення, які не потребують тривалого часу. Нам знадобилося певний час, щоб потрапити сюди. Сильні моменти Lucene - його масштабованість, великий спектр можливостей та активна спільнота розробників. Використання голого луцену вимагає програмування на Java.

Якщо ви починаєте заново, інструментом для вас в родині люценів є Солр , який налаштовувати набагато простіше, ніж оголений лучен, і має майже всю силу люцена. Він може легко імпортувати документи бази даних. Solr написані на Java, тому будь-яка модифікація Solr вимагає знань Java, але ви можете багато зробити, лише налаштувавши конфігураційні файли.

Я також чув хороші речі про Sphinx, особливо у поєднанні з базою даних MySQL. Не використовували, хоча.

ІМО, ви повинні вибрати відповідно до:

• Необхідна функціональність - наприклад, вам потрібен французький стоммер? У Люцена і Солра є одне, про інших я не знаю.
• Володіння мовою реалізації - Не торкайтесь Java Lucene, якщо ви не знаєте Java. Можливо, вам знадобиться C ++, щоб робити речі зі Сфінксом. Луцен також переноситься на інші мови . Це головне важливо, якщо ви хочете розширити пошукову систему.
• Простота експериментів - я вважаю, що Солр найкращий у цьому аспекті.
• Взаємодія з іншим програмним забезпеченням - Sphinx має хороший інтерфейс з MySQL. Solr підтримує інтерфейси ruby, XML та JSON як сервер RESTful. Lucene надає вам лише програмний доступ через Java. Компас і сплячий пошук - це обгортки люцена, які інтегрують його у більші рамки.

Ми використовуємо Sphinx у проекті вертикального пошуку з 10.000.000 + записів MySql та 10+ різними базами даних. Він отримав дуже чудову підтримку MySQL та високу продуктивність щодо індексації, дослідження проходять швидко, але, можливо, трохи менше, ніж Lucene. Однак це правильний вибір, якщо вам потрібно швидко індексувати кожен день і використовувати db MySQL.

Експеримент для порівняння ElasticSearch та Solr

Мій сфінкс.конф

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
}

Тестовий сценарій:

<?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");
?>

Зразок результату:

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

Час запиту сфінкса:

0.001 sec.

Час запиту сфінкса (одночасний 1 к):

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

Час запиту MySQL:

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

Час запиту MySQL (однокімнатний одночасний):

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

Єдине порівняння продуктивності порівняно з solr, яке мені вдалося знайти досі, є тут:

Солр проти еластичного пошуку Deathmatch!

Lucene приємний і всі, але їх набір зупинок слово жахливий. Мені довелося вручну додати тонку стоп-слів до StopAnalyzer.ENGLISH_STOP_WORDS_SET лише для того, щоб дістати її де завгодно поблизу.

Я не використовував Сфінкса, але знаю, що люди клянуться його швидкістю і майже магічним співвідношенням «простота налаштування до дивовижності».

Спробуйте indextank.

Що стосується еластичного пошуку, його було задумано набагато простіше, ніж люцен / соль. Сюди також входить дуже гнучка система підрахунку балів, яку можна налаштувати без повторного встановлення.