Diskussion:NoSQL

Relationale DB contra NOSQL

Ich bin mit dem Artikel nicht glücklich, weil er NOSQL zwar gut darstellt, die Unterschiede zu relationalen Datenbanken aber im Wesentlichen auf die Nichtverwendung von SQL reduziert. NQSQL-Datenbanken haben mit Sicherheit für bestimmte Anwendungen (Dokumente, Beziehungen zwischen z.B. Personen, evtl. bei großen Stücklisten) große Vorteile, für andere (insbesondere strukturierte Daten wie Rechnungen, Buchungen, Ein-/Auszahlungen etc.) aber sind relationale Datenbanken geeigneter. Das wird in dem Artikel leider nicht ausreichend herausgearbeitet. (nicht signierter Beitrag von 2A02:908:F67A:A3C0:ECF4:639A:E3AC:EB51 (Diskussion | Beiträge) 19:13, 26. Jan. 2016 (CET))

Ja, auch die Vergleichstabelle suggeriert, dass NoSQL eigentlich alles besser kann als SQL. Mir kommt es aber eher so vor, als ob da Kriterien fehlen, die im Text durchaus erwähnt werden (Transaktionssicherheit). --217.91.139.42 11:27, 19. Aug. 2016 (CEST)

Apollo

Facebook's Apollo ist eine weitere NoSQL. Es ist unklar, ob sie OpenSource sein wird. (nicht signierter Beitrag von 77.7.153.132 (Diskussion) 20:21, 16. Jun. 2014 (CEST))

Anfang

Um mit diesem Thema zu beginnen habe ich versucht den Inhalt des englischen Beitrags relativ frei zu übersetzen. Vielleicht findet sich ja jemand der sich mit dem Thema etwas mehr auskennt und den Artikel fortführen möchte. (nicht signierter Beitrag von 79.214.82.5 (Diskussion) 20:45, 18. Jun. 2010 (CEST))

Ich hab jetzt den Rest des englischen Artikels eingebaut & alles geprüft - jetzt hat der Artikel zumindest mal eine für die Ansprüche der deutschen Wikipedia akzeptable Qualität erreicht. --Sebastian.Dietrich ✉ 22:46, 24. Jun. 2010 (CEST)

Non SQL vs. NoSQL

NoSQL wird ja gerne als not only SQL bezeichnet. Aber was ist denn Non SQL? --Chevarri 10:21, 15. Okt. 2010 (CEST)

den Begriff "Non SQL" kenne ich nicht, wo hast denn den her? --Sebastian.Dietrich ✉ 20:15, 15. Okt. 2010 (CEST)

gib mal ein bei Google. Ist denn NoSQL vollkommen frei von SQL oder wirklich nur not only? Oder gibt es beides, also DBs die wirklich überhaupt keine SQL-Funktionalitäten übernehmen? --Chevarri 12:07, 21. Okt. 2010 (CEST)

"non-SQL" entspricht "nicht SQL" und ist kein Fachbegriff. Eine Nicht-SQL Datenbank ist eine DB, auf die man nicht mittels SQL zugreift (z.B. gibts kein SQL bei einer XML-DB). NoSQL ist die Bewegung (und das auf dieser Seite beschriebene Lemma) und somit ein Fachbegriff, die die Persistierung in was anderem als SQL Datenbanken treibt. Das können Nicht-SQL-Datenbanken sein, oder auch ganz andere Dinge wie memcached. --Sebastian.Dietrich ✉ 22:08, 21. Okt. 2010 (CEST)

NoSQL vs. NoSQL

"Carlo Strozzi, der Entwickler dieser Datenbank, unterscheidet allerdings die NoSQL-Datenbank von der NoSQL-Bewegung insofern, als ersteres eine Datenbank ist, welche bewusst auf die Verwendung von SQL verzichtet, während zweiteres ein Konzept ist, welches vom relationalen Modell abstammt."

Bitte was? Was ist den eine NoSQL-Datenbank? Und was ist die NoSQL-Bewegung? Ich versteh wirklich nicht um was es hier geht. Beide Begriffe sind, wenn man sie im Artikel antrifft noch nicht aussreichend erklärt, was (zumindest bei mir) extremste Verwirrung auslöst.

Sehe ich es Recht dass Carlo Strozzi in seiner Auffassung auf SQL komplett verzichtet, die "NoSQL-Bewegung", welche nicht auf seinen Mist gewachsen ist, aber doch vom relationellen Modell abstammt?

Die Formulieren momentan macht einem zu Schaffen. --CatzHoek 00:50, 25. Nov. 2010 (CET)

Bezüglich der Frage zu Carlo Strozzi:

Es gibt eine Software "nosql", welches auf RDB basiert und im Wesentlichen Daten in Text-Dateien im Unix Filesystem speichert und mit den Standard-Unix-Kommandos operiert. Hier steht "nosql" für "not sql" und bezeichnet eine ganz bestimmte Software. Die Software wurde von C. Strozzi entwickelt und hat nichts mit "nosql" im Sinne von "not-only sql" zu tun. In diesem Sinne "stammt" Strozzis Software vom relationalen Modell ab, sie unterstützt nur nicht SQL als Abfragesprache.

Der Begriff "NoSQL" oder "no-only sql" steht im Allgemeinen für Datenbanken, welche sich bewusst von RDMS unterscheiden. Dabei geht die Geschichte sicherlich genauso weit zurück, wie die der RDMS. Ein solcher Veteran ist Lotus Notes, den es seit fast 30 Jahren gibt. Der Term "NoSQL" für diesen Bereich ist allerdings relativ neueren Datums und dient als Oberbegriff für Dokumentdatenbanken, Key-Value-Stores, Graphdatenbanken usw. In diesem Sinne "stammen" Vertreter der NoSQL Datenbanken meist nicht vom relationalen Modell ab. Ein Grund warum Strozzi schreibt, man sollte die Bewegung lieber "norel" nennen. Das hat sich aber nicht weiter durchgesetzt.

Leider bedeutet "nosql" also ja nach Zusammenhang etwas völlig anderes - was die Verwirrung erklärt. Einmal eine spezielle Datenbank-Software, welche nicht SQL als Abfragesprache einsetzt - also wirklich "no sql". Einmal Datenbanken, welche in der einen oder anderen Weise von klassischen RDBMS abweichen und mit "no-only sql" bezeichnet werden. Aus diesem Grund ist der Satz

"Der Begriff NoSQL (Not only SQL) wurde erstmals für eine 1998 erschienene leichtgewichtige Open-Source-Datenbank verwendet..."

eigentlich falsch. Der Begriff "NoSQL", so wie er bei Strozzi verwendet wird, bedeutet wirklich "no sql" und nicht "not only sql".

--Fceller 10:29, 19. Sep. 2011 (CEST)

"to depart from" heisst übrigens nicht "von etwas abstammen", diese Übersetzung kehrt die Bedeutung des zitierten Satzes um. -- 84.169.81.244 22:29, 20. Mär. 2011 (CET)

"Graphdatenbank" VS. "Graph_en_datanbank"

Der Link "Graphendatenbank" in der Tabelle verweist ins Leere, weil das Lemma Graphdatenbank(ohne "en") ist.

Ich hab mir zuerst mal die Freiheit genommen, den Link mal direkt zu fixen. Habe die Bennenung aber noch im Plural gelassen, da ich unsicher war, was eigentlich (im deutschen) Konsens ist.

Also Google liefert da:

• Graphdatenbank: ~14.000
• Graphendenatenbank: ~300

Nicht dass ich Google alles glaube, aber einige der Stellen, wo ich "Graphdatenbank" gelesen hatte, waren durchaus ernstzunehmender (auf der Website von "Sones DB" z.B.).

Also ich lasse das erstmal so stehen und änder es dann heute abend oder so, wenn keiner Einwände erhebt. KleinerPinguin 13:14, 8. Jun. 2011 (CEST)

XML-Datenbanken

Warum werden BaseX und eXist nicht in einer eigenen Kategorie XML-Datenbanken aufgeführt? Es gibt schließlich deutliche Unterschiede zwischen den XML-Datenbanken und anderen dokumentenorientierten Datenbanken (z.B. die gemeinsame standardsierte Abfragesprache XQuery). Und: Es gibt ja sogar einen eigenen Wikipedia Artikel dafür.

Facebookerwähnung

Finde in den Quellen keinen Verweis darauf, dass Facebook eine "NoSQL"-basierende Datenbank verwendet. Wäre um Quellnachreichung sehr dankbar. (nicht signierter Beitrag von 178.202.181.84 (Diskussion) 04:25, 5. Apr. 2012 (CEST))

--78.49.224.125 15:35, 26. Feb. 2012 (CET)

Facebook hat ursprünglich Cassandra entwickelt, nutzt mittlerweile aber andere Systeme. Ein paar Details finden sich unter highscalability.com Gruß--Flash1984 (Diskussion) 14:46, 10. Apr. 2012 (CEST)

Liste der NoSQL Datenbanken

Die Liste der NoSQL Datenbanken ist weder vollständig noch eindeutig klassifiziert. Ich fände es besser, eine separate Seite "Liste der NoSQL Datenbanken" dafür zu eröffnen. Wenn niemand etwas dagegen hat, würde ich dies in den nächsten Tagen beginnen. --Fceller (Diskussion) 14:57, 12. Dez. 2012 (CET)

Ich denke ein Verweis auf diese Seite http://nosql-database.org/ sollte ausreichend sein. Das erspart doch viel Arbeit. --Jehasius (Diskussion) 14:18, 24. Dez. 2012 (CET)

konkretes Beispiel

Ich vermisse irgendwie ein konkretes Beispiel, welches aufzeigt, was sich bei Einbindung einer NoSQL Datenbank im Gegensatz zu SQL (Select x FROM y WHERE ...) nun nach außen hin konkret ändert. (nicht signierter Beitrag von 79.224.96.110 (Diskussion) 14:06, 3. Mai 2013 (CEST))

das Problem ist, dass es nicht wirllich die NoSQL Datenbank gibt. Es gibt auch NewSQL Datenbank, welche man zu den NoSQL Datenbanken rechnen kann, die SQL verwenden --Fceller (Diskussion) 21:52, 24. Jan. 2014 (CET)

Bessere Gliederung

Ich habe mir eine etwas andere Gliederung überlegt, um hoffentlich besser herauszustellen, was NoSQL ist und was nicht NoSQL (also insbesondere nicht das Gegenteil von SQL).

   NoSQL
       Abschnitt "Geschichte"
           Herkunft/Entstehung des Begriffs "NoSQL" (bereits vorhanden)
           Alternative Datenbanksystem, welche man heute NoSQL Datenbank nennen würde (neu)
       Treiber der Entwicklung (neu)
           Herausforderungen von Benutzern
               Menge der Daten
               Kosten
       Enabler (neu)
           Speicherpreise
               RAM
               HDD
               SDD
           Denkblockaden bzgl Eigenentwicklungen von DB (Amazon Dynamo)
       Kernpunkte der Diskusion (neu)
           Skalierung von relationalen Datenbanken
           CAP
       Typen (statt Linksammlung eine kurze Beschreibung, Verweis auf entsprechende Linkseiten)
           Dokumentdatenbanken (Hauptartikel: Dokumentenorientierte Datenbank)
           Key-Value
           Extended Column Stores
           Graphdatenbanken
           Map-Reduce
       Techniken (neu)
           Vector Clocks (Hauptarktikel: Amazon_Dynamo#Vector_Clocks)
           MVCC (Hauptarktikel: Multiversion Concurrency Control)
           Consistent Hashing (Hauptarktikel: Konsistente_Hash-Funktion)
           Eventually Consistent (Hauptartikel: Eventual_consistency müsste auch überarbeitet werden)
           Verteilung (vielleicht ist dies auch oder zum Teil Verteiltes Datenbankmanagementsystem)
           Gossip-Protokoll (Hauptarktikel: Amazon_Dynamo#Gossip-basiertes_Protokoll)

--Fceller (Diskussion) 21:54, 24. Jan. 2014 (CET)

Ich finde es gut, dass du dir Gedanken über die Struktur machst, finde aber deinen konkreten Vorschlag nicht "sooo" gelungen. Was man typischerweise unter NoSQL versteht, sind eigentlich die Klassen Key-Value-Store (Voldemort, Dynamo, HDFS, ...), Column-Store (Cassandra, HBase, ...) und Document-Store (MongoDB, CouchDB, ...). Dabei handelt es sich eben um konkret neu aufgetretene Klassen von Datenbanken, wohingegen Graphdatenbanken schon lange etabliert sind und Map-Reduce eher im Bereich Batch Processing zu verorten ist. NewSQL wiederum würde ich als dazu orthogonale Bewegung sehen, d.h. die Entwicklung war quasi wie folgt: RDBMS => RDBMS skaliert nicht und eigentlich brauchen wir keine ACID-Garantien => NoSQL (Key-Value-Stores) => Mmmh, eigentlich brauchen wir doch ein bisschen mehr Strukturierung => NoSQL (Document- und Column-Stores) => Datenbankcommunity schlägt zurück: "Aber das liegt doch nicht an SQL und Transaktionen, dass RDBMS nicht skalieren!" (tut es großteils doch) => Entwicklung von NewSQL. D.h. aber auch, dass die Eigenschaft "nicht klassisch relational" nicht automatisch jedes Datenbanksystem in die Kategorie NoSQL schubst. Zumindest ist das mein Eindruck, von dem, was die Datenbank- und Systems-Communitys darunter verstehen. Der Kern-"Enabler" ist aber eigentlich auch nicht die Entwicklung und Verfügbarkeit bestimmter Hardwaretypen sondern möglich war es auch vorher schon (wenn auch ohne Cloudressourcen nicht für jedermann nutzbar). Hauptsächlich getrieben wurde diese Entwicklung eigentlich durch die Anforderungen von Workloads, die aus global verfügbaren Webanwendungen resultieren, so dass dann entsprechend die Storagesysteme für einen ganz konkreten Anwendungsfall entwickelt und dann typischerweise weiterentwickelt und auch an anderen Stellen genutzt wurden. Die als neu bezeichneten Techniken sind auch nicht neu sondern alle durchaus schon älter. Nur ihre weitverbreitete Verwendung ist neu. Nebenbei ist Eventual Consistency keine Technik sondern ein "Resultat", d.h. eine Garantie, die das Storagesystem geben kann. Ich stimme dir aber zu, dass ich den Artikel zu Konsistenz mal wieder etwas überarbeiten sollte. Grüße--Flash1984 (Diskussion) 13:26, 28. Jan. 2014 (CET)

Das Problem mit NoSQL ist halt leider, dass der Begriff völlig ungeeignet ist. HBase gehört eigentlich mehr zu Big-Data. Lotus Notes war die erste Dokument-Datenbank - gibt es also fast genausio lange wir Graphendatenbanken. MapReduce gibt es auch als Streaming. ACID und BASE gehen leider in der Tat auch drunter und drüber. Und unter NewSQL versteht jeder etwas anderes. -Fceller (Diskussion) 14:29, 28. Jan. 2014 (CET)

Im Abschnitt Geschichte

"Dieses Thema ist nicht ganz neu. " Welche Information versteckt sich dahinter? Rätselraten, wo, wie und vor allem wann das Thema "neu" war? Die Floskel hört sich nach Politiker im Sommerloch-Interview an. --62.159.86.77 16:34, 9. Aug. 2016 (CEST)

NoSQL ist ein mehrfacher Begriffunfall

Wie im Artikel beschrieben soll NoSQL nicht als Alternative zur Sprache SQL sondern als Alternative zu relationalen SQL-Datenbanken aufgefasst werden. Die Begrifflichkeit ist dafür aber ein absoluter Fehlgriff:

Zunächst richtet sich NoSQL nicht gegen SQL, die viele NoSQL-DBs haben eine SQL(-ähnliche) Anfragesprache.

Die Idee, SQL stünde synonym für relational (wie im Artikel angedeutet) ist auch problematisch, weil relational leider auch schon ein Begriffsunfall ist. Jede Datenbank speichert Relationen - nur anders strukturiert: Attribute (Dokumenten-DB), Key-Values (Key-Value-Store), Graphenkanten (Graph-DB), Spalten (Column Store), Relationen (Deduktive DB) oder eben Zeilen (traditionelle relationale DB).

Die Idee das No für Nicht steht, lehnt die Community ab. Völlig unverständlich für mich. Wenn sich SQL auf traditionelle SQL-Datenbanken bezieht und man akzeptiert, dass "relational" auch schon ein schlecht gewählter aber nunmal üblicher Begriff dafür ist, dann sind NoSQL-Datebanken doch alle die Datenbanken, die vom relationalen, tabellenbasierten Design abweichen. Warum dann not only?

Not only SQL würde doch bedeuten, dass NoSQL Datebanken aus SQL bestehen - und noch mehr. Das ist jetzt aber gleich doppelt widersinnig. Normale SQL-Datenbanken bestehen doch nicht nur aus SQL? Zum einen ist die Programiersprache der kleinste Teil eines DBMS, zum anderen ist SQL nur in seltenen Fällen die einzige Programmiersprache eines modernen SQL-DBMS (meist gibt es noch einen prozedurale Erweiterungssprache). Der zweite Widerspruch findet sich darin, dass Not only SQL andeutet, dass der gemeinsame Nenner von NoSQL-Datenbanken SQL wäre, der Rest jedoch variabel. Sicherlich haben einige NoSQL-Datenbanken SQL-ähnliche Anfragesprachen, aber ich habe nicht den Eindruck, dass man NoSQL genauso verstehen sollte. Demnach wären die ganzen Key-Value-Stores, Dokumenten-DBs und Graph-DBs ohne SELECT-FROM-WHERE-Anfrage-Sprache ja gar nicht Teil von NoSQL.

Ich glaube nicht, dass der Artikel diese Form von Kritik verträgt, aber mich würde mal interessieren, warum diese Begrifflichkeit so populär geworden ist? Etherial (Diskussion) 00:09, 8. Mär. 2018 (CET)