elasesearch vs MongoDB для фільтрації додатків [закрито]

Це питання стосується того, щоб зробити архітектурний вибір перед тим, як заглиблюватися в деталі експерименту та реалізації. Йдеться про придатність, з точки зору масштабності та продуктивності, еластичного пошуку проти MongoDB для дещо конкретної мети.

Гіпотетично обидва зберігають об'єкти даних, у яких є поля та значення, і дозволяють проводити запит до цього об’єкта. Отже, імовірно, фільтрування підмножини об'єктів відповідно до вибраних спеціальних полів є чимось придатним для обох.

Моя програма буде обертатися навколо вибору об'єктів за критеріями. Він вибирав би об'єкти, фільтруючи одночасно більш ніж одне поле, інакше кажучи, його критерії фільтрації запитів, як правило, містять місця від 1 до 5 полів, можливо, в деяких випадках більше. Тоді як поля, вибрані як фільтри, будуть підмножиною значно більшої кількості полів. Позначте 20 існуючих імен полів, і кожен запит - це спроба відфільтрувати об'єкти за кількома полями із цих 20-ти полів (Це може бути менше або більше 20 загальних імен полів, я просто використав це число, щоб продемонструвати співвідношення поля для полів, які використовуються як фільтри у кожному дискретному запиті). Фільтрація може відбуватися за наявністю вибраних полів, а також за значеннями полів, наприклад, фільтруванням об'єктів, у яких є поле A, а їхнє поле B знаходиться між x і y,

Моя програма буде постійно проводити подібну фільтрацію, тоді як не буде нічого або дуже мало постійної точки зору, які поля використовуються для фільтрації в будь-який момент. Можливо, в індексах еластичного пошуку потрібно визначити, але, можливо, навіть без індексів швидкість знаходиться на рівні з швидкістю MongoDB.

Відповідно до даних, що потрапляють у магазин, особливих деталей щодо цього немає, об'єкти майже ніколи не будуть змінені після вставки. Можливо, старі об'єкти потрібно буде скинути, я б припустив, що обидва сховища даних закінчуються, видаляючи дані всередині або шляхом запиту, зробленого додатком. (Рідше об’єкти, які відповідають певному запиту, також повинні бути відкинуті).

Що ти думаєш? І чи експериментували ви з цим аспектом?

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

Дякую!

По-перше, тут слід зробити важливу відмінність: MongoDB - це база даних загального призначення, Elasticsearch - пошукова система з розповсюдженим текстом, підтримувана Lucene. Люди говорили про використання Elasticsearch як базу даних загального призначення, але знають, що це був не його "оригінальний дизайн". Я думаю, що бази даних та пошукові системи NoSQL загального призначення спрямовуються на консолідацію, але, як це є, вони походять з двох дуже різних таборів.

У моїй компанії ми використовуємо і MongoDB, і Elasticsearch. Ми зберігаємо наші дані в MongoDB і використовуємо Elasticsearch виключно для його повнотекстового пошуку. Ми надсилаємо лише підмножину полів даних монго, які нам потрібні для запиту. Наш випадок використання відрізняється від вашого тим, що наші дані Mongo постійно змінюються: запис або підмножина полів запису можна оновлювати кілька разів на день, і це може зажадати повторної індексації цього запису до еластичного. З цієї причини, використання еластичного як єдиного сховища даних не є для нас хорошим варіантом, оскільки ми не можемо оновити вибрані поля; нам знадобиться переіндексувати документ у повному обсязі. Це не еластичне обмеження, саме так працює Lucene - основна пошукова система, що стоїть за пружною. У вашому випадку факт перемоги рекордів " t що змінюється, коли зберігається, позбавляє вас від необхідності робити такий вибір. Сказавши, що, якщо безпека даних викликає занепокоєння, я б подумав двічі про використання Elasticsearch як єдиного механізму зберігання даних. Це може потрапити в якийсь момент, але я не впевнений, що він ще є.

Що стосується швидкості, то не тільки еластичність / люцена нарівні зі швидкістю запиту Монго, у вашому випадку, коли є "дуже мала константа в плані того, які поля використовуються для фільтрації в будь-який момент", це може бути замовленням на швидкість, тим більше, що набори даних збільшуються. Різниця полягає в реалізації основних запитів:

• Еластичні / люценові використовують векторну космічну модель та інвертовані індекси для пошуку інформації , які є високоефективними способами порівняння подібності записів із запитом. Коли ви запитуєте Elastic / Lucene, він вже знає відповідь; більша частина його роботи полягає в ранжуванні результатів для вас за найбільш ймовірними, що відповідають вашим умовам запиту. Це важливий момент: пошукові системи, на відміну від баз даних, не можуть гарантувати точні результати; вони ранжують результати за тим, наскільки вони наближені до вашого запиту. Так буває, що більшість випадків результати близькі до точних.
• Підхід Монго полягає у більш загальному сховищі даних; він порівнює документи JSON один проти одного. Ви можете досягти великої продуктивності від нього будь-якими способами, але вам потрібно ретельно скласти свої індекси, щоб відповідати запитам, які ви будете виконувати. Зокрема, якщо у вас є кілька полів, за якими ви будете здійснювати запит, вам потрібно ретельно скласти складені ключіщоб вони зменшили набір даних, які будуть запитуватися якомога швидше. Наприклад, ваш перший ключ повинен відфільтрувати більшість вашого набору даних, другий повинен додатково відфільтрувати те, що залишилося, і так далі, і так далі. Якщо ваші запити не відповідають клавішам і порядок цих ключів у визначених індексах, продуктивність буде досить скоротитися. З іншого боку, Монго - це справжня база даних, тому якщо точність - те, що вам потрібно, відповіді, які вона дасть, будуть помітні.

Для закінчення старих записів Elastic має вбудовану функцію TTL. Монго щойно представив його як версію 2.2.

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