2015-11-20 2 views
2

Мы сравнивали эти поисковые решения и начали задаваться вопросом, почему нужна схема, а другая нет. Что такое компромиссы? Это потому, что одно похоже на SQL, а другое похоже на NoSQL в смысле конфигурации схемы?Почему у SOLR есть схема, а ElasticSearch - нет?

+0

Я просто хочу указать, что оба используют Lucene для индексирования документов. Не должно быть никакой разницы в том, как они хранятся. Вы получили свой ответ уже, но, возможно, эта информация помогает в сравнении. – Slomo

ответ

2

У ES есть схема, обозначенная как templates и mappings. Вам не обязательно использовать его, но на практике вы это сделаете. Схема на самом деле хорошая вещь, и если вы заметите, что база данных, претендующая на чистую схему, будет иметь последствия для производительности.

Схема является компромиссом между легкостью разработки и принятия против производительности. Его легко читать/записывать в базу данных schemaless, но он будет менее результативным, особенно для любого нетривиального запроса.

2

У Elasticsearch определенно есть схема. Если вы считаете, что это не так, попробуйте индексировать дату в поле, а затем int в одно и то же поле. Или даже в разные типы с тем же именем (я думаю, ES 2.0 запрещает это сейчас).

Что делает Elasticsearch, упрощает автосоздание схемы. У этого есть компромиссы, такие как возможное неправильное обнаружение типа, поля, которые являются однозначными или многозначными в результате вывода на основе количества элементов, которые они содержат (они всегда многозначны под обложками) и т. Д. У Elasticsearch есть несколько способов обойти это, главным образом, путем определения некоторых элементов схемы и явного сопоставления схем, как писал Oleksii.

Solr также имеет режим схемы, который точно соответствует режиму Elasticsearch, вплоть до хранения всего JSON в качестве одного поля. И когда вы включите его, вы получите как аналогичные преимущества, так и аналогичные недостатки Elasticsearch. Кроме того, в Solr вы можете изменять такие вещи, как порядок стратегий автоматического отображения и сопоставление типов полей. В Elasticsearch (по крайней мере, 1.x) он был жестко закодирован. Вы можете видеть - слегка устаревшее - сравнение в my presentation from 2014.

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

+0

Есть еще одна вещь: я просматривал исходный код и для ES - он просто чист, с новыми технологиями, лучшей поддержкой кластеризации на AWS и других провайдерах облачных вычислений и т. Д. –

+0

Ну, конечно, вы видят дилемму Новатора в действии. ES появилась позже и реализовала небольшое подмножество функций Solr, основанное на последней Lucene. Если вам нужны только то, что предлагает ES, пойдите для этого. Просто убедитесь, что вы читаете спецификации 2.0, поскольку вещи были сброшены. Что касается масштабирования, Solr - это то, что работает Apple CloudSearch и Bloomberg. –

Смежные вопросы