it-swarm.com.de

Warum werden Dokumentenspeicher wie Lucene/Solr nicht in NoSQL-Konversationen einbezogen?

Wir alle sind in letzter Zeit auf den Hype der No-SQL-Lösungen gestoßen. MongoDB, CouchDB, BigTable, Cassandra und andere wurden als No-SQL-Optionen aufgeführt. Hier ist ein Beispiel:

http://architects.dzone.com/articles/what-nosql-store-should-i-use

Vor drei Jahren verwendeten ein Kollege und ich jedoch Lucene.NET als das, was zur Beschreibung von No-SQL zu passen scheint. Wir haben es nicht nur für benutzerdefinierte Suchanfragen verwendet. Wir haben es verwendet, um einige neu indizierte RDBMS-Tabellendaten extrem performant zu machen. Wir haben unseren eigenen .NET-Dienst implementiert, um diese Indizes zu verwalten und aufrufbar zu machen. Als ich das Unternehmen verließ, wechselte das Team zu Solr. (Für Unbekannte ist Solr ein Webdienst, der Lucene mit REST-aufrufbaren Abfragen und Index-Dumps umschließt.)

Was ich nicht verstehe ist, warum wird Solr nicht in den typischen Listen der No-SQL-Lösungsoptionen gezählt? Vermisse ich hier etwas? Ich gehe davon aus, dass es technische Gründe gibt, warum Solr nicht mit CouchDB usw. vergleichbar ist, und ich verstehe sogar, dass CouchDB Lucene als Datenspeicher verwendet (ja?), Aber was disqualifiziert Solr?

Ich frage nicht als eine Art Solr-Fan oder so, ich verstehe nur nicht, warum Solr und dergleichen nicht zur Definition von No-SQL passen, und wenn Solr technisch zur Definition passt, was macht es dann wahrscheinlich Leute puh-puh das? Ich frage, weil ich Schwierigkeiten habe, festzustellen, ob ich Lucene-basierte Lösungen (wie Solr) für von mir erstellte Lösungen weiter verwenden oder ob ich mit diesen anderen Optionen wirklich mehr Nachforschungen anstellen sollte.

62
Jon Davis

Ich habe mir einmal ein Interview mit der Autorin Ursula K. LeGuin über Belletristik angehört. Die Interviewerin fragte sie nach Autoren, die in verschiedenen Schriftgenres arbeiten. Was macht einen Autor zu einem Romanautor und einen anderen zu einem Mystery-Schriftsteller und einen anderen zu einem Science-Fiction-Schriftsteller? LeGuin antwortete mit folgenden Erklärungen:

Beim Genre geht es um Marketing, nicht um Inhalt.

Es war eine aufschlussreiche Aussage.

Ich denke, dasselbe gilt für Technologielösungen. Die NoSQL-Bewegung zieht Aufmerksamkeit auf sich, weil sie momentan voller Marketing-Energie steckt. NoSQL-Datenspeicher wie Hadoop, CouchDB und MongoDB werden von kommerziellen Unternehmen unterstützt, die ihre Lösungen als neu, innovativ und aufregend präsentieren, damit sie ihr Geschäft ausweiten können. Der Begriff "NoSQL" ist eine Marketing-Marke, die ihnen hilft, ihren Wert zu erklären.

Sie haben Recht, dass Lucene/Solr einem NoSQL-Dokumentenspeicher technisch sehr ähnlich ist: Es handelt sich um eine denormalisierte Dokumententasche (ihr Begriff) mit Feldern, die nicht unbedingt für die gesamte Dokumentensammlung konsistent sind. Es ist auf raffinierte Weise indiziert, damit Sie in allen Feldern oder nach bestimmten Feldern suchen können.

Aber das ist nicht das Genre, mit dem Lucene seinen Wert erklärt. Sie haben nicht die gleiche Mission, einen Markt und ein Geschäft aufzubauen, da sie von der Apache Foundation verwaltet werden. Sie konzentrieren sich gerne auf den Anwendungsfall der Volltextsuche, auch wenn die Technologie auf andere Weise verwendet werden könnte. Sie verfolgen einen Grundsatz des Softwareerfolgs: Tun Sie eine Sache und tun Sie es gut.

73
Bill Karwin

Nach mehr Google-Suchen, denke ich, fasst dieses Dokument es ziemlich gut zusammen:

https://web.archive.org/web/20100504055638/http://www.lucidimagination.com/blog/2010/04/30/nosql-lucene-and-solr/

Ein Beispiel dafür ist Lucene/Solr is NoSql und könnte als einer der reiferen "Vorväter" von NoSql betrachtet werden. Es bekommt einfach nicht den NoSql-Hype, den es verdient, weil es den Begriff "no-SQL" nicht erfunden hat und seine Benutzer den Begriff nicht verwenden, sodass der Hype-Computer ihn übersehen hat.

13
Jon Davis

Ich denke, dass das relevanteste Merkmal von solr/lucene, das von der nosql-Liste abfällt, darin liegt, dass es bis vor kurzem schmerzhaft war, Lucene als Echtzeitsystem zu verwenden. Der übliche Workflow für jede performante Anwendung bestand darin, die inkrementellen Aktualisierungen in Batches zu indizieren und den Index beispielsweise alle 5 Minuten zu aktualisieren. 

4
Jokin

Ich denke, dass stimpy77 teilweise richtig ist, wenn NoSQL eine Branding-Sache ist . NoSQL bedeutet aber auch, dass es sich um eine Datenspeicherplattform handelt, die einfacher als SQL-basierte Lösungen ist. Ich denke, während Solr/Lucene einige Aspekte teilen (sie speichern Daten), verfehlt es wirklich den Eindruck, dass Solr/Lucene als primärer Datenspeicher für alles, was Beziehungen hat, verwendet werden könnte. Sicher, viele Dokumente können hineingeworfen werden, und eine leistungsstarke Suche zieht sie zurück. Sobald Sie jedoch Beziehungen wünschen, ist es für andere wie CouchDB und andere, die eine Abfragesyntax haben, viel besser. Suche ist in diesem Fall eine bandaid-Lösung. Denken Sie an den Anwendungsfall "Alle Dokumente suchen, die mit Word" car "gekennzeichnet sind". Wenn ich einige Strukturen in meinen Daten habe, ist es einfach für mich, das Dokument für das Tag-Auto zu erhalten und alle zurück zu ziehen. Im Gegensatz zu einer Suchabfrage, die fq = Tag enthält: "Auto". Die Suche wird immer leistungsfähiger, je weniger Beziehungen Sie haben, aber je mehr Beziehungen, desto besser sind Datastores wie CouchDB und Brüder. Deshalb sehen Sie immer noch CouchDB und Freunde, die mit Solr gepaart sind, und umgekehrt! Lassen Sie jeden tun, was er am besten kann.

Das heißt natürlich nicht, dass Sie das Speichern Ihrer Quelldaten in Solr nicht nutzen können, da dies ein mächtiges Werkzeug sein kann!

2
Eric Pugh

Die Hauptunterschiede zwischen No-sql und Solr in operativer Hinsicht sind meiner Meinung nach die folgenden.

  1. Solr erfordert einen Zwischenspeicher (Datenbank- oder XML-Dateien), während nosql selbst ein reiner Datenspeicher ist.
  2. Sie können keine konstanten Schreibvorgänge in solr durchführen (solr 4.0 scheint diese Unterstützung zu bieten), und Sie können nur alle 2 Minuten und 200 Datensätze indexieren (was für Schreibvorgänge mit hohem Durchsatz sehr langsam ist und Sie zwangsweise zwischenspeichern). .
  3. Sie müssen das Schema ändern/definieren, wenn Sie ändern, was im Dokument gespeichert ist. NoSQL hat keine solchen Definitionen.
  4. Solr-Indizes haben Auswirkungen auf die Leistung, wenn die Indexgröße ansteigt, während NoSQL für sie optimiert ist (oder behauptet, :))
  5. Solr hat zugrunde liegende Lucene-Suchalgorithmen gebündelt, aber in NoSQL müssen Sie diese erstellen. Dies gilt für die großartige facettenreiche Suche oder die rasante Dokumentensuche von solr.
1

Letzte Punkte, Es geht um den Unterschied, der hier nicht als Marketingstrategie erwähnt wird, bei der solr von NoSQL ausgeht

Lucene/Solr - Ich werde Solr verwenden, Da Solr intern Lucene verwendet und zusätzliche Funktionen hat. Solr ist also im Grunde ein Upgrade auf Lucene mit neuer Version.

  • Solr wird hauptsächlich zum Erstellen von Facetten und zum Indizieren von Klartexten für Suchmaschinen verwendet.

  • Solr kann die meisten Datenbanken zum Speichern seiner Daten verwenden. Es ist inkonsistent, Daten in solr zu behalten, da sie direkt Festplatten verwenden.

  • NoSQL-Datenbanken sind im Vergleich zu Solr leicht zu erlernen. Solr hat mehr oder weniger viele Konfigurationen und Konzepte (z. B. Felder).

  • Leistung ist etwas, das wir s/w berücksichtigen müssen. Solr bietet im Vergleich zu anderen NoSQL-Datenbanken eine hohe Leistung.

Hinweis: Die Kombination des Solr mit einigen Datenbanken bietet die beste Leistung. 

Zusammenfassung: Solr ist auch ein NoSQL-Datastore, der ein Vorgänger aller NoSQL-Datenbanken ist. Was nicht den Hype von anderen bekam. Aber immer noch auf dem Feld wegen seiner Leistung und Leistung.