Diskussion:NoSQL

message: 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)
replies: text: 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)
thread_title:  Relationale DB contra NOSQL 

message: 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)
thread_title:  Apollo 

message: 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)
replies: text: 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)
thread_title:  Anfang 

message: NoSQL wird ja gerne als not only SQL bezeichnet.
Aber was ist denn Non SQL?
--Chevarri 10:21, 15. Okt. 2010 (CEST)
replies: text: den Begriff "Non SQL" kenne ich nicht, wo hast denn den her? --Sebastian.Dietrich  ✉ 20:15, 15. Okt. 2010 (CEST)
replies: text:  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)
replies: text:  "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)
thread_title:  Non SQL vs. NoSQL 

message: 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)
thread_title:  "Graphdatenbank" VS. "Graph_en_datanbank" 

message: 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)
replies: text: 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)
thread_title:  Facebookerwähnung 

message: 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)
thread_title:  Liste der NoSQL Datenbanken 

message: 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)
replies: text: 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)
thread_title:  konkretes Beispiel 

message: 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)
replies: text: 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)
replies: text:  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)
thread_title:  Bessere Gliederung 

message: "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)
thread_title:  Im Abschnitt Geschichte 

message: 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)
thread_title:  NoSQL ist ein mehrfacher Begriffunfall