Flexiblesearch vs MongoDB do filtrowania aplikacji [zamknięte]

To pytanie dotyczy dokonania wyboru architektonicznego przed zagłębieniem się w szczegóły eksperymentów i implementacji. Chodzi o przydatność, pod względem skalowalności i wydajności, elastycznego wyszukiwania w porównaniu z MongoDB, w nieco określonym celu.

Hipotetycznie zarówno przechowują obiekty danych, które mają pola i wartości, jak i umożliwiają wykonywanie zapytań dotyczących tego ciała obiektów. Zatem przypuszczalnie odfiltrowywanie podzbiorów obiektów według pól wybranych ad-hoc jest czymś odpowiednim dla obu.

Moja aplikacja będzie się obracać wokół wybierania obiektów według kryteriów. Wybierałby obiekty, filtrując jednocześnie przez więcej niż jedno pole, inaczej mówiąc, jego kryteria filtrowania zapytań zwykle obejmowałyby od 1 do 5 pól, może w niektórych przypadkach więcej. Natomiast pola wybrane jako filtry byłyby podzbiorem znacznie większej liczby pól. Wyobraź sobie około 20 istniejących nazw pól, a każde zapytanie jest próbą odfiltrowania obiektów według kilku pól spośród tych wszystkich 20 pól (może to być mniej lub więcej niż 20 istniejących nazw pól, właśnie użyłem tej liczby, aby zademonstrować stosunek pola na pola używane jako filtry w każdym zapytaniu dyskretnym). Filtrowanie może odbywać się na podstawie istnienia wybranych pól, a także wartości pól, np. Odfiltrowywanie obiektów, które mają pole A, a ich pole B znajduje się między x a y,

Moja aplikacja będzie nieustannie przeprowadzać tego rodzaju filtrowanie, podczas gdy w dowolnym momencie nie będzie nic lub będzie bardzo mało stałej w zakresie tego, które pola są używane do filtrowania. Być może w elasticsearch indeksy muszą zostać zdefiniowane, ale może nawet bez indeksów szybkość jest taka sama jak w MongoDB.

Jeśli chodzi o dane, które trafiają do sklepu, nie ma specjalnych szczegółów na ten temat ... obiekty prawie nigdy nie byłyby zmieniane po wstawieniu. Być może należałoby porzucić stare obiekty, chciałbym założyć, że obsługa obu magazynów danych wygasa, usuwając elementy wewnętrznie lub przez zapytanie wysłane przez aplikację. (Rzadziej obiekty, które pasują do określonego zapytania, również musiałyby zostać usunięte).

Co myślisz? Czy eksperymentowałeś z tym aspektem?

Interesuje mnie wydajność i skalowalność każdego z dwóch magazynów danych do tego rodzaju zadań. Jest to rodzaj pytania o projekt architektoniczny, a szczegóły dotyczące opcji specyficznych dla sklepu lub podstaw zapytania, które powinny sprawić, że będzie dobrze zaprojektowany, są mile widziane jako demonstracja w pełni przemyślanej sugestii.

Dzięki!

Po pierwsze, należy tu dokonać ważnego rozróżnienia: MongoDB to baza danych ogólnego przeznaczenia, Elasticsearch to rozproszona wyszukiwarka tekstu wspierana przez Lucene. Ludzie mówią o używaniu Elasticsearch jako bazy danych ogólnego przeznaczenia, ale wiedzą, że nie był to jej oryginalny projekt. Myślę, że bazy danych NoSQL i wyszukiwarki ogólnego przeznaczenia zmierza do konsolidacji, ale w obecnym kształcie oba pochodzą z dwóch bardzo różnych obozów.

W mojej firmie używamy zarówno MongoDB, jak i Elasticsearch. Przechowujemy nasze dane w MongoDB i używamy Elasticsearch wyłącznie do wyszukiwania pełnotekstowego. Wysyłamy tylko podzbiór pól danych mongo, które musimy zapytać o elastyczność. Nasz przypadek użycia różni się od twojego tym, że nasze dane Mongo zmieniają się cały czas: rekord lub podzbiór pól rekordu może być aktualizowany kilka razy dziennie, co może wymagać ponownego indeksowania tego rekordu do elastycznego. Tylko z tego powodu używanie elastycznego jako jedynego magazynu danych nie jest dla nas dobrym rozwiązaniem, ponieważ nie możemy aktualizować wybranych pól; musielibyśmy ponownie zindeksować dokument w całości. To nie jest elastyczne ograniczenie, tak działa Lucene, podstawowa wyszukiwarka za elastyczną. W twoim przypadku fakt, że rekordy wygrały Zmiana po zapisaniu pozwala uniknąć konieczności dokonywania tego wyboru. Powiedziawszy to, jeśli chodzi o bezpieczeństwo danych, dwa razy zastanowiłbym się nad użyciem Elasticsearch jako jedynego mechanizmu przechowywania danych. W pewnym momencie może się tam dostać, ale nie jestem pewien, czy tam jest.

Jeśli chodzi o szybkość, nie tylko Elastic / Lucene jest na równi z szybkością zapytań Mongo, w Twoim przypadku, gdy istnieje „bardzo mała stała pod względem tego, które pola są używane do filtrowania w dowolnym momencie”, mogą to być rzędy rzędu wielkość szybciej, zwłaszcza gdy zbiory danych stają się większe. Różnica polega na podstawowych implementacjach zapytań:

• Elastic / Lucene używa modelu przestrzeni wektorowej i odwróconych indeksów do wyszukiwania informacji , które są bardzo wydajnymi sposobami porównywania podobieństwa rekordów z zapytaniem. Kiedy odpytujesz Elastic / Lucene, to już zna odpowiedź; większość jego pracy polega na uszeregowaniu wyników według tych, które najbardziej pasują do wyszukiwanych haseł. To ważna kwestia: wyszukiwarki, w przeciwieństwie do baz danych, nie mogą zagwarantować dokładnych wyników; klasyfikują wyniki według tego, jak blisko znajdują się od zapytania. Tak się składa, że ​​w większości przypadków wyniki są bliskie dokładności.
• Podejście Mongo to bardziej uniwersalny magazyn danych; porównuje ze sobą dokumenty JSON. Możesz uzyskać z tego doskonałą wydajność wszelkimi sposobami, ale musisz starannie opracować indeksy, aby pasowały do ​​zapytań, które będziesz uruchamiać. W szczególności, jeśli masz wiele pól, za pomocą których będziesz wykonywać zapytania, musisz starannie opracować klucze złożonetak, aby jak najszybciej zredukowały zbiór danych, które będą odpytywane. Np. Twój pierwszy klucz powinien odfiltrować większość zbioru danych, drugi powinien dalej filtrować to, co zostało, i tak dalej, i tak dalej. Jeśli Twoje zapytania nie pasują do kluczy i kolejności tych kluczy w zdefiniowanych indeksach, wydajność znacznie spadnie. Z drugiej strony Mongo to prawdziwa baza danych, więc jeśli dokładność jest tym, czego potrzebujesz, odpowiedzi, które udzieli, będą na miejscu.

W przypadku wygasających starych rekordów Elastic ma wbudowaną funkcję TTL. Wydaje mi się, że Mongo właśnie wprowadziło go w wersji 2.2.

Ponieważ nie znam Twoich innych wymagań, takich jak oczekiwany rozmiar danych, transakcje, dokładność lub wygląd filtrów, trudno jest sformułować konkretne zalecenia. Miejmy nadzieję, że jest tu wystarczająco dużo, aby zacząć.