NoSQL (MongoDB) vs Lucene (lub Solr) jako baza danych
Wraz z rosnącym ruchem NoSQL opartym na bazach danych opartych na dokumentach, spojrzałem ostatnio na MongoDB. Zauważyłem uderzające podobieństwo do tego, jak traktować przedmioty jako "dokumenty", tak jak robi to Lucene (i użytkownicy Solr).
Więc pytanie: Dlaczego chcesz używać NoSQL (MongoDB, Cassandra, CouchDB, etc) zamiast Lucene (lub Solr) jako swojej "bazy danych"?
To ,co ja (i jestem pewien, że inni) szukają w odpowiedzi, to jakieś głębokie porównania ich. Let ' s pomiń wszystkie dyskusje dotyczące relacyjnych baz danych, ponieważ służą one innym celom.
Lucene daje kilka poważnych zalet, takich jak potężne systemy wyszukiwania i wagi. Nie wspominając już o aspektach w Solr (które Solr wkrótce zostanie zintegrowane z Lucene, yay!). Możesz użyć dokumentów Lucene do przechowywania identyfikatorów i uzyskać dostęp do dokumentów jako takich, tak jak MongoDB. Połącz go z Solr, a otrzymasz rozwiązanie oparte na WebService, zrównoważone pod względem obciążenia.
Można nawet dorzucić porównanie poza proc dostawców pamięci podręcznej, takich jak Velocity lub MemCached, gdy mówimy o podobnym przechowywaniu danych i skalowalności MongoDB.
Ograniczenia wokół MongoDB przypominają mi używanie MemCached, ale mogę używać prędkości Microsoftu i mieć większą moc grupowania i zbierania list niż MongoDB(myślę). Nie można uzyskać szybszego lub skalowalnego niż buforowanie danych w pamięci. Nawet Lucene ma dostawcę pamięci.
MongoDB (i inne) mają pewne zalety, takie jak łatwość obsługi ich API. Nowy dokument, Utwórz identyfikator i zapisz go. Załatwione. Spokojnie.
10 answers
To jest świetne pytanie, nad którym sporo się zastanawiałam. Podsumuję moje wyciągnięte wnioski:
Możesz łatwo używać Lucene / Solr zamiast MongoDB w praktycznie wszystkich sytuacjach, ale nie odwrotnie. Tutaj podsumowuje Post Granta Ingersolla.
MongoDB itp. wydaje się służyć celowi, w którym nie ma wymogu poszukiwania i / lub fasetowania. Wydaje się być prostszym i prawdopodobnie łatwiejszym przejściem dla programistów od RDBMS world. Chyba, że ktoś jest do tego przyzwyczajony Lucene i Solr mają bardziej stromą krzywą uczenia się.
Nie ma zbyt wielu przykładów użycia Lucene / Solr jako magazynu danych, ale Guardian poczynił pewne postępy i podsumował to w doskonałym slide-deck, ale oni też nie są zobowiązani do całkowitego skakania na Solr bandwagon i "badania" łączenia Solr z CouchDB.
Na koniec przedstawię nasze doświadczenie, niestety nie mogę wiele zdradzić na temat sprawy biznesowej. My praca na skalę kilku TB danych, aplikacja prawie w czasie rzeczywistym. Po zbadaniu różnych kombinacji, postanowił pozostać przy Solr. Do tej pory nie żałuję (6 miesięcy i liczenie) i nie widzę powodu, aby przejść na inne.
Podsumowanie: jeśli nie masz wymogu wyszukiwania, Mongo oferuje proste i potężne podejście. Jeśli jednak wyszukiwanie jest kluczowe dla Twojej oferty, prawdopodobnie lepiej będzie trzymać się jednej technologii (Solr / Lucene) i optymalizować ją do cholery - mniej ruchu części.
Moje 2 centy, mam nadzieję, że to pomogło.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-02-25 16:33:53
Nie można częściowo zaktualizować dokumentu w solr. Aby zaktualizować dokument, musisz ponownie opublikować wszystkie pola.
I wydajność ma znaczenie. Jeśli nie zatwierdzisz, twoja zmiana w solr nie wejdzie w życie, jeśli zatwierdzisz ją za każdym razem, wydajność spadnie.
W solr nie ma żadnej transakcji.
Ponieważ solr ma te wady, czasami nosql jest lepszym wyborem.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-07-25 10:33:02
Należy również pamiętać, że niektórzy ludzie zintegrowali Solr / Lucene z Mongo poprzez przechowywanie wszystkich indeksów w Solr, a także monitorowanie operacji oplog i kaskadowanie odpowiednich aktualizacji do Solr.
Dzięki temu hybrydowemu podejściu możesz naprawdę mieć najlepsze z obu światów z możliwościami takimi jak wyszukiwanie pełnotekstowe i szybkie odczyty z niezawodnym magazynem danych, który może również mieć niesamowitą prędkość zapisu.
Jest to trochę techniczne do konfiguracji, ale jest wiele tailerów oplog, które mogą integracja z solr. Sprawdź, co rangespan zrobił w tym artykule.
Http://denormalised.com/home/mongodb-pub-sub-using-the-replication-oplog.html
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-05-09 18:12:08
Używamy MongoDB i Solr razem i działają dobrze. Mój wpis na blogu znajduje się tutaj , gdzie opisałem, jak wykorzystujemy te technologie razem. Oto fragment:
[...] Jednak obserwujemy, że wydajność zapytań Solr maleje, gdy indeks rozmiar wzrasta. Zdaliśmy sobie sprawę, że najlepszym rozwiązaniem jest użycie zarówno Solr i Mongo DB razem. Następnie integrujemy Solr z MongoDB, przechowując zawartość do MongoDB i tworzenie indeksu za pomocą Solr dla pełnotekstowego Szukaj. Przechowujemy tylko unikalny identyfikator każdego dokumentu w indeksie Solr i pobrać aktualną zawartość z MongoDB po przeszukaniu w Solr. Pobieranie dokumentów z MongoDB jest szybsze niż Solr, ponieważ nie ma analizatory, punktacja itp. [...]
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-07-02 22:00:05
Ponieważ nikt inny o tym nie wspomniał, dodam, że MongoDB jest bez schematu, podczas gdy Solr wymusza schemat. Jeśli więc pola twoich dokumentów mogą ulec zmianie, Jest to jeden z powodów, dla których warto wybrać MongoDB zamiast Solr.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-10-04 06:44:34
Z mojego doświadczenia z obu, Mongo jest świetny do prostego, prostego użytkowania. Główną wadą Mongo, którą ponieśliśmy, jest słaba wydajność na nieoczekiwanych zapytaniach(nie możesz utworzyć indeksów mongo dla wszystkich możliwych kombinacji filtrów/sortowania, po prostu nie możesz).
I tutaj, gdzie przeważa Lucene/Solr, szczególnie z buforowaniem FilterQuery, wydajność jest wyjątkowa.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-04-15 07:40:48
@mauricio-scheffer wspomniał o Solr 4 - dla zainteresowanych LucidWorks opisuje Solr 4 jako "serwer wyszukiwania NoSQL" i jest film na http://www.lucidworks.com/webinar-solr-4-the-nosql-search-server / gdzie wnikają w szczegóły funkcji NoSQL (ish). (The-ish jest dla ich wersji schemaless faktycznie jest dynamiczny schemat.)
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-10-01 21:51:50
Jeśli chcesz tylko przechowywać dane w formacie klucz-wartość, Lucene nie jest zalecany, ponieważ jego odwrócony indeks marnuje zbyt dużo miejsca na dysku. A przy zapisywaniu danych na dysku jego wydajność jest znacznie wolniejsza niż baz 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 zapytania rozmyte mogą być obsługiwane.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2016-12-05 11:26:18
Rozwiązania stron trzecich, jak ogon Mongo op-log są atrakcyjne. Pozostają pewne przemyślenia lub pytania na temat tego, czy rozwiązania mogą być ściśle zintegrowane, zakładając perspektywę rozwoju/architektury. Nie spodziewam się, że zobaczę ściśle zintegrowane rozwiązanie dla tych funkcji z kilku powodów (nieco spekulatywne i podlegające wyjaśnieniu, a nie aktualne w wysiłkach programistycznych): {]}
- mongo to c++, lucene / solr to java
- Może lucene przyda się trochę mongo libs
- może mongo mógłby przepisać jakieś algorytmy lucene, Zobacz też:
- mongo koncentruje się na JSON (BSON)
- aktualizacje pojedynczych pól są problemem, jeśli są dostępne
- lucene ma opcje przechowywania pól w dokumentach, ale to nie to samo
- solr dostarcza agregację / statystyki i zapytania SQL/graph
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-05-22 17:02:15
NoSQL działa jako wielowątkowe bazy danych, które oferują doskonałe funkcje skalowalności. Obecnie wiele baz danych NoSQL obsługuje partycjonowanie danych w różnych węzłach, co pomaga skalować duże zbiory danych przy jednoczesnym ograniczeniu niepotrzebnego powielania.Skuteczność aplikacji, która ma być budowana, zależy nie tylko od modeli danych, ale także od tego, jak wydajne jest wypełnianie nowych funkcji. Modele danych działają jako pomost między zagadnieniami świata rzeczywistego a oprogramowaniem. rozwiązania bazodanowe NoSQL rozwiń nowoczesne aplikacje.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-12-03 06:43:25