Чому я використовую ElasticSearch, якщо я вже використовую базу даних графіків?

Я не знаходжу в Інтернеті жодного глибокого пояснення щодо порівняння ElasticSearch та баз даних графіків.

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

Чому я використовую ElasticSearch, якщо я вже використовую базу даних графіків?

У моєму випадку я використовую Neo4j для створення соціальної мережі.
Яку реальну користь може принести ElasticSearch?

ОНОВЛЕННЯ ----------

Я щойно знайшов цей параграф:

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

• Пошук у великій кількості описів продуктів для найкращої відповідності конкретній фразі (скажімо, «кухарський ніж») та повернення найкращих результатів
• З огляду на попередній приклад, розбивши різні відділи, де з’являється «кухарський ніж» (див. Граніт пізніше в цій книзі)
• Пошук тексту за словами, які звучать як "сезон"
• Автоматичне заповнення вікна пошуку на основі частково набраних слів на основі раніше виданих пошукових запитів, враховуючи неправильні написання
• Зберігання великої кількості напівструктурованих (JSON) даних розподіленим способом із заданим рівнем надмірності в кластері машин

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

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

Чи можу я стверджувати, що якщо мені не потрібні приблизні відповіді, то ElasticSearch виявиться марним у порівнянні з уже використаною базою даних графіків?

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

Я бачу, де можна їх заплутати. Вони насправді можуть відповідати одній і тій же потребі, але не завжди. ElasticSearch робить саме те, що звучить, як пошук . База даних графіків не визначає відносини чи індекси, як це робить ElasticSearch. Тож принципово вони працюють зовсім інакше. ElasticSearch аналізує документи за допомогою, наприклад, англійського аналізатора. Для цього потрібно слова та проаналізувати різні варіанти цього слова чи навіть синоніми. Наприклад, digбуде аналогізовано як dig,digs,dug,digging,digger .... Коли ви запускаєте запит на еластичному дослідженні, ваші запити також можуть бути проаналізовані, тоді ці слова запитуються і можуть бути оцінені за релевантністю.

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

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

Питання полягає в тому, наскільки надійним ви хочете бути вашим пошуком? Якщо у вас є потреба зробити дуже дрібний пошук (повний текст), я б скористався гумовим пошуком. Інакше пошук завжди можна відносно легко здійснити на базі графіків. Після того, як ви здійснили пошук, неможливо перейти до еластичного пошуку, якщо пізніше вам знадобиться більш міцна пошукова система, просто здійсніть пошук із цим.

Обидві ці бази даних мають свою специфічну потребу вирішувати конкретну проблему на певному рівні вимог програми. Хоча ми не використовували графічну базу даних. Але ми використовуємо еластичний пошук з MySQL в одному з наших проектів за останні 5 років. Цей проект має величезну кількість даних, яку можна шукати через 6 мільйонів документів, і має масивні відносини між цими організаціями (10-мільйонні документи відносин).

Випадок використання: як і пошук по готелях, які сподобалися моїм друзям, і сортуйте всі готелі за кількістю лайків, які вони мають. І якщо ви це бачите пильно. у цій справі були пов'язані 2 відносини (Друг, подобається). Тож мені потрібно шукати корабель "Like Relations" між Готелями та "Моїми друзями", а потім готелі слід сортувати за загальною кількістю лайків, які вони мають. Тож для таких пошуків хороша база даних графіків.

Elasticsearch робить велику роботу для повного тестового пошуку документів, але коли мова йде про пошук таких відносин, як вище, це не так добре. Перелічіть документи (сутності), які є моїми шанувальниками, і відсортуйте їх за їх кількістю. Але це один рівень глибокий, і коли мова йде про пошук більш глибоких. Еластичний пошук недостатньо хороший.

Тож зрозумійте свою вимогу до програми та перейдіть до бази даних. Можливо, вам доведеться мати і те, і інше.