Зачем мне использовать ElasticSearch, если я уже использую базу данных графа?

В Интернете я не нашел глубокого объяснения о сравнении ElasticSearch и графических баз данных.

Оба оптимизированы для прохождения данных.
ElasticSearch, похоже, оптимизирован для аналитики.
Однако Neo4j также основан на Lucene для управления индексами и некоторыми полнотекстовыми функциями.

Зачем мне использовать ElasticSearch, если я уже использую базу данных графа?

В моем случае я использую Neo4j для создания социальной сети.
Какую реальную выгоду может принести ElasticSearch?

ОБНОВИТЬ ----------

Я только что нашел этот абзац:

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

• Поиск большого количества описаний продуктов для лучшего соответствия конкретной фразе (скажем, «нож шеф-повара») и возвращение лучших результатов
• Учитывая предыдущий пример, разбиваем различные отделы, где появляется «нож шеф-повара» (см. «Гранение» далее в этой книге)
• Поиск текста по словам, которые звучат как «сезон»
• Автоматическое заполнение поля поиска на основе частично набранных слов на основе ранее выполненных поисков с учетом неправильного написания
• Хранение большого количества полуструктурированных (JSON) данных в распределенном режиме с заданным уровнем избыточности на кластере машин

Следует, однако, отметить, что, несмотря на то, чтоasticsearch хорош в решении вышеупомянутых проблем, он не является лучшим выбором для других. Это особенно плохо при решении задач, для которых оптимизированы реляционные базы данных. Проблемы, такие как перечисленные ниже.

• Подсчет, сколько предметов осталось в инвентаре
• Вычисление суммы всех позиций по всем счетам, отправленным за данный месяц
• Выполнение двух операций транзакционно с поддержкой отката
• Создание записей, которые гарантированно будут уникальными для нескольких заданных терминов, например номер телефона и добавочный номер
• Elasticsearch, как правило, отлично подходит для предоставления приблизительных ответов на основе данных, таких как оценка результатов по качеству. В то время как эластичный поиск может выполнять точные сопоставления и статистические вычисления, его основная задача поиска является по своей природе приблизительной задачей.
• Поиск приблизительных ответов - это свойство, которое отделяет эластичный поиск от более традиционных баз данных. При этом традиционные реляционные базы данных превосходны по точности и целостности данных, для чего у эластичного поиска и Lucene мало положений.

Могу ли я утверждать, что если мне не нужны приблизительные ответы, то ElasticSearch будет бесполезен по сравнению с уже используемой базой данных графиков?

Я не решаюсь назвать ElasticSearch базой данных. Это не замена базы данных, но хорошее дополнение для добавления функциональности, в частности расширенного текстового поиска, наряду с существующей базой данных.

Я вижу, где вы можете запутать их. Они могут действительно соответствовать той же потребности, но не всегда. ElasticSearch делает именно то, на что это похоже, ищет . Графическая база данных не определяет отношения или индексы, где это делает ElasticSearch. Так что принципиально они работают совсем по-другому. ElasticSearch анализирует документы, например, с помощью английского анализатора. Для этого потребуются слова и анализируются различные варианты этого слова или даже синонимы. Например, digбудет проанализировано как dig,digs,dug,digging,digger .... Когда вы запускаете запрос наasticsearch, ваши запросы также могут анализироваться, тогда эти слова запрашиваются и могут быть оценены по релевантности.

ElasticSearch - отличный инструмент, потому что он действительно гибкий. Вы можете найти широкий диапазон относительного содержания, или вы можете найти иголку в стоге сена, и это относительно просто.

Граф базы данных тоже имеют свои преимущества. Поиск релевантности / отношений между вещами, такими как, например, хеш-теги, или вещами со многими изменчивыми отношениями. Это отличные и интересные технологии, однако я должен сказать, что он не такой мощный, как ElasticSearch. Главным образом потому, что ElasticSearch ориентирован на подобные вещи и выполняет анализ для вас, чтобы вы могли выполнять полнотекстовый поиск. Однако, если вы хотите использовать систему, более похожую на поиск в Твиттере, основанную на предопределенных тегах / ключевых словах, то вам лучше использовать базу данных графиков, которую вы уже используете.

Вопрос в том, насколько надежным должен быть ваш поиск? Если вам нужен действительно точный поиск (полный текст), я бы использовал эластичный поиск. В противном случае вы всегда можете относительно легко реализовать поиск в графовой базе данных. После того, как вы запустили поиск, вы не сможете перейти наasticsearch, если позже вам понадобится более надежная поисковая система, просто выполните поиск с учетом этого.

Обе эти базы данных имеют свои конкретные потребности для решения конкретной проблемы на определенном уровне требований приложения. Хотя мы не использовали базу данных Graph. Но мы используем эластичный поиск с MySQL в одном из наших проектов за последние 5 лет. Этот проект содержит массивные данные для поиска в 6 млн документов и имеет массивные отношения между этими объектами (10 млн документов отношений).

Вариант использования: например, поиск по отелям, которые понравились моим друзьям, и сортировка всех отелей по количеству лайков. И если вы видите это внимательно. В этом случае задействовано 2 отношения (Friend, Like). Так что мне нужно поискать через лайк отношений между Отелями и Моими Друзьями, а затем отели должны быть отсортированы по общему количеству лайков, которые у них есть. Так что для таких поисков, база данных графа хороша.

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

Итак, поймите требования вашего приложения, а затем перейдите к базе данных. Возможно, вам нужно иметь оба.