NoSQL (MongoDB) vs Lucene (lub Solr) jako baza danych

Ponieważ ruch NoSQL rośnie w oparciu o bazy danych oparte na dokumentach, ostatnio patrzyłem na MongoDB. Zauważyłem uderzające podobieństwo do traktowania przedmiotów jako „Dokumentów”, podobnie jak Lucene (i użytkownicy Solr).

Pytanie: dlaczego miałbyś używać NoSQL (MongoDB, Cassandra, CouchDB itp.) Nad Lucene (lub Solr) jako „bazy danych”?

To, czego szukam (i jestem pewien, że inni) w odpowiedzi, to ich głębokie porównania. Pomińmy razem dyskusje o relacyjnych bazach danych, ponieważ służą one innym celom.

Lucene ma kilka poważnych zalet, takich jak potężne systemy wyszukiwania i wagi. Nie wspominając już o aspektach w Solr (które Solr zostanie wkrótce zintegrowany z Lucene, tak!). Możesz używać dokumentów Lucene do przechowywania identyfikatorów i uzyskiwać dostęp do dokumentów jako takich, jak MongoDB. Wymieszaj go z Solr, a otrzymasz rozwiązanie oparte na WebService, z równoważeniem obciążenia.

Możesz nawet dodać porównanie dostawców pamięci podręcznej poza procesem, takich jak Velocity lub MemCached, mówiąc o podobnym przechowywaniu danych i skalowalności MongoDB.

Ograniczenia dotyczące MongoDB przypominają mi o korzystaniu z MemCached, ale mogę korzystać z Velocity Microsoftu i mieć większą moc grupowania i zbierania list nad MongoDB (tak myślę). Nie może być szybszy ani skalowalny niż buforowanie danych w pamięci. Nawet Lucene ma dostawcę pamięci.

MongoDB (i inne) mają pewne zalety, takie jak łatwość użycia ich API. Utwórz nowy dokument, utwórz identyfikator i zapisz go. Gotowe. Miło i łatwo.

To świetne pytanie, nad czym dość długo się zastanawiałem. Podsumuję wyciągnięte wnioski:

1. Możesz łatwo użyć Lucene / Solr zamiast MongoDB w prawie wszystkich sytuacjach, ale nie odwrotnie. Podsumowanie postu Granta Ingersolla znajduje się tutaj.

2. MongoDB itp. Wydają się służyć celowi, w którym nie ma wymogu wyszukiwania i / lub facetingu. Wydaje się, że jest to łatwiejsze i prawdopodobnie łatwiejsze przejście dla programistów odtruwających ze świata RDBMS. Chyba że ktoś się do tego przyzwyczaił, Lucene i Solr mają bardziej stromą krzywą uczenia się.

3. Nie ma wielu przykładów użycia Lucene / Solr jako magazynu danych, ale Guardian poczynił pewne postępy i podsumował to w doskonałej zjeżdżalni , ale oni również nie są zobowiązani do całkowitego skakania na wózku Solr i „badania” łączenia Solr z CouchDB.

4. Na koniec przedstawię nasze doświadczenie, niestety nie mogę wiele powiedzieć na temat uzasadnienia biznesowego. Pracujemy w skali kilku TB danych, aplikacja prawie w czasie rzeczywistym. Po zbadaniu różnych kombinacji postanowiłem trzymać się Solr. Jak dotąd nie żałuję (6 miesięcy i wciąż rośnie) i nie widzę powodu, aby przejść na inne.

Podsumowanie: jeśli nie masz wymogu wyszukiwania, Mongo oferuje proste i skuteczne podejście. Jeśli jednak wyszukiwanie ma kluczowe znaczenie dla Twojej oferty, prawdopodobnie lepiej jest trzymać się jednej technologii (Solr / Lucene) i optymalizować ją - mniej ruchomych części.

Moje 2 centy, mam nadzieję, że to pomogło.

Nie można częściowo zaktualizować dokumentu w solr. Musisz ponownie opublikować wszystkie pola, aby zaktualizować dokument.

A wydajność ma znaczenie. Jeśli tego nie zrobisz, zmiana na solr nie będzie obowiązywać, jeśli dokonujesz tego za każdym razem, wydajność spada.

W solr nie ma transakcji.

Ponieważ solr ma te wady, czasami nosql jest lepszym wyborem.

Używamy MongoDB i Solr razem i działają one dobrze. Mój post na blogu możesz znaleźć tutaj, w którym opisałem, jak wspólnie korzystamy z tych technologii. Oto fragment:

[...] Obserwujemy jednak, że wydajność zapytania Solr spada wraz ze wzrostem wielkości indeksu. Uświadomiliśmy sobie, że najlepszym rozwiązaniem jest jednoczesne użycie zarówno Solr, jak i Mongo DB. Następnie integrujemy Solr z MongoDB, przechowując zawartość w MongoDB i tworząc indeks za pomocą Solr do wyszukiwania pełnotekstowego. Przechowujemy tylko unikalny identyfikator dla każdego dokumentu w indeksie Solr i pobieramy rzeczywistą zawartość z MongoDB po wyszukiwaniu w Solr. Pobieranie dokumentów z MongoDB jest szybsze niż Solr, ponieważ nie ma analizatorów, oceniania itp. [...]

Należy również pamiętać, że niektóre osoby zintegrowały Solr / Lucene z Mongo, przechowując wszystkie indeksy w Solr, a także monitorując operacje oplogu i przenosząc odpowiednie aktualizacje do Solr.

Dzięki takiemu podejściu hybrydowemu możesz naprawdę mieć to, co najlepsze z obu światów, dzięki takim funkcjom, jak wyszukiwanie pełnotekstowe i szybkie odczytywanie z niezawodnym magazynem danych, który może mieć także niesamowitą prędkość zapisu.

Konfiguracja jest nieco techniczna, ale istnieje wiele programów dostosowujących oplog, które można zintegrować z solr. Sprawdź, co zrobił rangespan w tym artykule.

http://denormalised.com/home/mongodb-pub-sub-using-the-replication-oplog.html

Z mojego doświadczenia z obydwoma, Mongo jest świetny do prostego, prostego użytkowania. Główną wadą Mongo, którą odczuliśmy, jest niska wydajność nieprzewidzianych zapytań (nie można tworzyć indeksów mongo dla wszystkich możliwych kombinacji filtrów / sortowania, po prostu nie można).

A tutaj, gdzie Lucene / Solr panuje przez długi czas, szczególnie w przypadku buforowania FilterQuery, wydajność jest wyjątkowa.

Ponieważ nikt o tym nie wspominał, dodam, że MongoDB nie zawiera schematu, podczas gdy Solr wymusza schemat. Tak więc, jeśli pola twoich dokumentów prawdopodobnie się zmienią, to jeden z powodów, aby wybrać MongoDB zamiast Solr.

@ Mauricio-Scheffer wspomniał o Solr 4 - dla zainteresowanych tym LucidWorks opisuje Solr 4 jako „serwer wyszukiwania NoSQL”, a film jest dostępny na stronie http://www.lucidworks.com/webinar-solr-4-the-nosql -search-server / gdzie szczegółowo omawiają funkcje NoSQL (ish). (Opcja -ish dotyczy ich wersji schematów, która w rzeczywistości jest schematem dynamicznym).

Jeśli chcesz tylko przechowywać dane w formacie klucz-wartość, Lucene nie jest zalecana, ponieważ jej odwrócony indeks marnuje zbyt dużo miejsca na dysku. Dzięki oszczędności danych na dysku jego wydajność jest znacznie mniejsza niż w bazach danych NoSQL, takich jak redis, ponieważ redis zapisuje dane w pamięci RAM. Największą zaletą Lucene jest to, że obsługuje wiele zapytań, więc można obsługiwać zapytania rozmyte.

Rozwiązania innych firm, takie jak mongo op-log tail, są atrakcyjne. Pozostaje kilka przemyśleń lub pytań dotyczących tego, czy rozwiązania mogłyby być ściśle zintegrowane, przy założeniu perspektywy rozwoju / architektury. Nie oczekuję, że zobaczę ściśle zintegrowane rozwiązanie dla tych funkcji z kilku powodów (nieco spekulacyjnych i podlegających wyjaśnieniu i nie na bieżąco z pracami rozwojowymi):

• mongo to c ++, lucene / solr są java
  • być może Lucen przydałby się w niektórych bibliotekach mangowych
  • może mongo może przepisać niektóre algorytmy Lucene, patrz także:
    • http://clucene.sourceforge.net/
    • http://lucy.apache.org/
• Lucene obsługuje różne formaty dokumentów
  • mongo koncentruje się na JSON (BSON)
• Lucene używa niezmiennych dokumentów
  • aktualizacje pojedynczego pola stanowią problem, jeśli są dostępne
• indeksy lucenu są niezmienne przy złożonych operacjach scalania
• zapytania mongo są javascript
• mongo nie ma analizatorów / tokenizatorów tekstu (AFAIK)
• rozmiary dokumentów mongo są ograniczone, co może być sprzeczne z ziarnem dla lucenu
• operacje mongo agregacji mogą nie mieć miejsca w lucenie
  • Lucene ma opcje przechowywania pól między dokumentami, ale to nie to samo
  • solr w jakiś sposób zapewnia agregację / statystyki i zapytania SQL / wykres

MongoDB Atlas wkrótce będzie miał wyszukiwarkę opartą na lucenie. Duże ogłoszenie zostało ogłoszone na konferencji MongoDB World 2019 w tym tygodniu. Jest to świetny sposób, aby zachęcić do większego wykorzystania ich produktu MongoDB Atlas o wysokich dochodach.

Miałem nadzieję, że zobaczę go w wersji 4.2 MongoDB Enterprise, ale nie było żadnych wieści o wprowadzeniu go do swojej linii produktów przedpremierowych.

Więcej informacji tutaj: https://www.mongodb.com/atlas/full-text-search