Warum sollten Sie eine Datenbank verwenden, anstatt Ihre Daten nur auf der Festplatte zu speichern?

193

Anstelle einer Datenbank serialisiere ich meine Daten einfach in JSON und speichere und lade sie bei Bedarf auf die Festplatte. Die gesamte Datenverwaltung erfolgt über das Programm selbst. Dies ist schneller UND einfacher als die Verwendung von SQL-Abfragen. Aus diesem Grund habe ich nie verstanden, warum Datenbanken überhaupt notwendig sind.

Warum sollte man eine Datenbank verwenden, anstatt die Daten nur auf der Festplatte zu speichern?

MaiaVictor
quelle
61
Wenn die Verwaltung der Beziehungen Ihrer Daten in Ihrer Anwendung tatsächlich schneller ist als die Verwaltung in einer Datenbank (was ich sehr schwer zu glauben finde), müssen Sie sich über die SQL- und Datenbanknormalisierung informieren. Was Sie erleben, ist höchstwahrscheinlich der Nebeneffekt einer schrecklich gestalteten Datenbank.
Yannis
68
In dem von Ihnen beschriebenen Szenario benötigen Sie keine Datenbank, da Ihr Datensatz trivial ist. Datenbanken sind für komplexere Datensätze gedacht. Wenn Sie lediglich eine Liste lesen und anzeigen, funktioniert Ihr Ansatz.
Yannis
16
Auf welche Rennbedingungen könntest du stoßen und bist du bereit dafür? Möchten Sie über einen einzelnen Webserver hinaus skalieren? Was ist Ihr Backup-Plan, wenn Ihr Server ausfällt? Ihre Antwort auf all diese Fragen ist wahrscheinlich besser, wenn Sie über eine Datenbank verfügen, als wenn Sie dies nicht tun. Auch wenn Sie jemals über den Haufen des Erlernens des Umgangs mit Datenbanken gegangen sind, sollte nach meiner Einschätzung "Einfacher als die Verwendung von SQL-Abfragen" in "Einfacher als die Verwendung von SQL-Abfragen, wenn Sie SQL nicht verstehen" geändert werden.
btilly
37
Die Datenbank speichert die Daten trotzdem auf der Festplatte. Es ist nur das Endergebnis einer natürlichen Entwicklung von Systemen zum Speichern strukturierter Daten in Dateien. Wenn Sie Dateien zum Speichern Ihrer strukturierten Daten verwenden, werden Sie wahrscheinlich Funktionen neu erfinden, die bereits in Datenbanken entwickelt wurden. Warum also nicht einfach von Anfang an eine Datenbank verwenden?
Benedict
13
Je nachdem, wie sich Ihr Projekt entwickelt, müssen Sie sich möglicherweise mit gleichzeitigen Zugriffen und Rollbacks befassen. Sie klingen trivial, sind es aber nicht. Wenn Sie mit dem Lösen fertig sind, werden Sie feststellen, dass Sie im Grunde genommen eine Datenbank geschrieben haben. Möchten Sie wirklich im Datenbankgeschäft oder in einem anderen Geschäft tätig sein?
jwernerny

Antworten:

280
  1. Sie können Daten in einer Datenbank abfragen (Fragen stellen).
  2. Sie können relativ schnell Daten aus einer Datenbank abrufen.
  3. Sie können Daten aus zwei verschiedenen Tabellen mithilfe von JOINs miteinander verknüpfen.
  4. Sie können aussagekräftige Berichte aus Daten in einer Datenbank erstellen.
  5. Ihre Daten haben eine eingebaute Struktur.
  6. Informationen eines bestimmten Typs werden immer nur einmal gespeichert.
  7. Datenbanken sind ACID .
  8. Datenbanken sind fehlertolerant.
  9. Datenbanken können sehr große Datenmengen verarbeiten.
  10. Datenbanken sind gleichzeitig vorhanden. Mehrere Benutzer können sie gleichzeitig verwenden, ohne die Daten zu beschädigen.
  11. Datenbanken lassen sich gut skalieren.

Kurz gesagt, Sie profitieren von einer Vielzahl bekannter, bewährter Technologien, die über viele Jahre von einer Vielzahl sehr intelligenter Menschen entwickelt wurden.

Wenn Sie befürchten, dass eine Datenbank überlastet ist, lesen Sie SQLite.

Robert Harvey
quelle
21
6. Normalisierung, 7. Siehe Link, 8. Informationen zur Fehlertoleranz. Oh, und bevor Sie sich in die NoSQL-Begeisterung vertiefen, sollten Sie sich mit SQL-Datenbanken vertraut machen. Lernen Sie sie auf eigene Faust kennen. Du wirst verstehen. Wenn Sie nur über einfache Konfigurationsdaten sprechen, ist JSON möglicherweise alles, was Sie benötigen. Neben den Programmeinstellungen gibt es noch viele andere Datentypen.
Robert Harvey
25
Soweit es nicht sicher ist, dass zwei Programme die Daten gleichzeitig bearbeiten, gibt es teilweise Datenbanken. Wenn Sie jemals dieses Bedürfnis haben (und einige oder alle der anderen Bedürfnisse, die ich erwähnt habe), werden Sie sehr froh sein, dass Sie all dies nicht neu erfinden müssen.
Robert Harvey
23
@Dokkat Es ist nicht notwendig, nichts ist. Wenn Ihr Ansatz für Sie funktioniert, entscheiden Sie sich auf jeden Fall dafür. Ich sollte jedoch erwähnen, dass die meisten halbwegs vernünftigen rdbms speicherbasierte Speicher unterstützen. Sie können alles, was Sie brauchen, in den Speicher laden, wenn Ihre App aufwacht (wie Sie es bereits tun), und sie wie eine typische Datenbank abfragen (wobei alle von Robert erwähnten Vorteile erhalten bleiben) ).
Yannis
28
Anders ausgedrückt, manchmal braucht man ein Zelt, aber manchmal braucht man ein Haus, und das Bauen eines Hauses ist ein ganz anderes Ballspiel als das Aufstellen eines Zeltes.
Robert Harvey
49
@Dokkat Wenn Leute sich auf Abstürze beziehen, meinen sie Dinge wie ... Ihre CPU ist in der Mitte des Schreibens Ihrer "Datenbank" -Datei in die Luft gesprengt. Was passiert jetzt? Höchstwahrscheinlich ist Ihre Datei beschädigt / nicht lesbar (zumindest entspricht sie möglicherweise nicht mehr Ihrem eigenen Format), und Sie müssen eine Sicherungskopie wiederherstellen (während die meisten "echten" DBs nur die letzte Transaktion verlieren würden). Natürlich können Sie Code schreiben, um dies zu handhaben. Dann können Sie Code für alle anderen Dinge schreiben. Und dann stellen Sie fest, dass Sie 6 Monate damit verbracht haben, eine Datenbank zu schreiben, die Sie von Anfang an mit sehr geringem Aufwand hätten verwenden können.
Daniel B
200

Ich bin mit allem einverstanden, was Robert gesagt hat, aber er hat Ihnen nicht gesagt, wann Sie eine Datenbank verwenden sollten, anstatt die Daten nur auf der Festplatte zu speichern.

Nehmen Sie dies zusätzlich zu dem, was Robert über Skalierbarkeit, Zuverlässigkeit, Fehlertoleranz usw. gesagt hat.

Für die Verwendung eines RDBMS sind folgende Punkte zu beachten:

  • Sie haben relationale Daten, dh Sie haben einen Kunden, der Ihre Produkte kauft, und diese Produkte haben einen Lieferanten und einen Hersteller
  • Sie haben große Datenmengen und müssen in der Lage sein, relevante Informationen schnell zu finden
  • Sie müssen sich über die zuvor identifizierten Probleme Gedanken machen: Skalierbarkeit, Zuverlässigkeit, ACID-Konformität
  • Sie müssen Berichts- oder Intelligence-Tools verwenden, um geschäftliche Probleme zu lösen

Wann ein NoSQL zu verwenden ist

  • Sie haben viele Daten, die unstrukturiert gespeichert werden müssen
  • Skalierbarkeit und Geschwindigkeitsanforderungen
  • Im Allgemeinen müssen Sie Ihr Schema nicht im Voraus definieren. Wenn Sie also Anforderungen ändern, ist dies möglicherweise ein guter Punkt

Endlich, wann man Dateien benutzt

  • Sie haben unstrukturierte Daten in angemessenen Mengen, die das Dateisystem verarbeiten kann
  • Sie interessieren sich nicht für Struktur, Beziehungen
  • Sie interessieren sich nicht für Skalierbarkeit oder Zuverlässigkeit (obwohl dies je nach Dateisystem möglich ist)
  • Sie wollen oder können nicht mit dem Overhead umgehen, den eine Datenbank hinzufügen wird
  • Es handelt sich um strukturierte Binärdaten, die zum Dateisystem gehören, z. B. Bilder, PDFs, Dokumente usw.
Sam
quelle
14
+1, ich denke es ist wichtig, dass Sie darauf hingewiesen haben, dass es Zeiten gibt, in denen Dateien tatsächlich zur Speicherung geeignet sind.
GroßmeisterB
15
Sie können Ihrer dritten Liste ein weiteres Beispiel hinzufügen: Wenn es sich bei den Daten tatsächlich um Dateien handelt, z. B. hochgeladene Bilder, PDF-Dokumente und dergleichen. Es mag offensichtlich erscheinen, aber ich habe Fälle gesehen, in denen Bilder ohne triftigen Grund in einem Datenbank-Blob gespeichert wurden.
Goran Jovic
5
Nun, es wurde nie ausdrücklich erwähnt, dass es sich um eine Web-App handelt, aber ich habe es dem JSON-Kommentar entnommen. Manchmal wird jedoch etwas nur von wenigen Personen verwendet, und Sie können den Umfang der Anwendung rechtfertigen, um sich keine Sorgen über Skalierbarkeit und Zuverlässigkeit zu machen. Damit meine ich, dass ich mir keine Gedanken über Clustering und Redundanz machen muss.
Sam
8
@GoranJovic es macht manchmal Sinn. Speichern Sie mehr als 10.000 Images in einem Verzeichnis, und einige Dateisysteme kommen zum Stillstand. Eine Datenbank ist möglicherweise einfacher als ein manuelles Partitionsschema für Unterverzeichnisse.
Martin Beckett
2
@MartinBeckett: Welches Dateisystem des letzten Jahrzehnts macht das?
Eamon Nerbonne
55

Eine Sache, die anscheinend niemand erwähnt hat, ist das Indizieren von Datensätzen. Ihr Ansatz ist im Moment in Ordnung, und ich gehe davon aus, dass Sie einen sehr kleinen Datensatz haben und nur sehr wenige Personen darauf zugreifen.

Wenn Sie komplexer werden, erstellen Sie tatsächlich eine Datenbank. Wie auch immer Sie es nennen möchten, eine Datenbank besteht nur aus einer Reihe von Datensätzen, die auf der Festplatte gespeichert sind. Ob Sie die Datei erstellen oder MySQL , SQLite oder was auch immer die Datei (en) erstellt, sie sind beide Datenbanken.

Was Sie vermissen, ist die komplexe Funktionalität, die in die Datenbanksysteme integriert wurde, um deren Verwendung zu vereinfachen.

Die Hauptsache, die mir einfällt, ist die Indizierung. OK, Sie können also 10 oder 20 oder sogar 100 oder 1000 Datensätze in einem serialisierten Array oder einer JSON-Zeichenfolge speichern und aus Ihrer Datei ziehen und relativ schnell iterieren .

Stellen Sie sich vor, Sie haben 10.000, 100.000 oder sogar 1.000.000 Datensätze. Wenn jemand versucht, sich anzumelden, muss er eine Datei mit einer Größe von mehreren Hundert Megabyte öffnen, sie in den Speicher Ihres Programms laden, eine ähnlich große Sammlung von Informationen abrufen und dann hunderttausende von Datensätzen durchlaufen, nur um Suchen Sie den einen Datensatz, auf den Sie zugreifen möchten.

Mit einer geeigneten Datenbank können Sie Indizes für bestimmte Felder in Datensätzen einrichten, sodass Sie die Datenbank abfragen und auch bei großen Datenmengen sehr schnell eine Antwort erhalten können. Kombinieren Sie das mit so etwas wie Memcached oder sogar einem selbst gebrauten Caching-System (speichern Sie beispielsweise die Ergebnisse einer Suche 10 Minuten lang in einer separaten Tabelle und laden Sie diese Ergebnisse, falls jemand anderes kurz danach nach dem gleichen Ding sucht), und Sie haben blitzschnelle Abfragen, was Sie mit einem so großen Datensatz nicht bekommen, wenn Sie manuell in Dateien lesen / schreiben.

Eine andere Sache, die lose mit der Indizierung zusammenhängt, ist die Übertragung von Informationen. Wie ich oben sagte, müssen Sie, wenn Sie Dateien mit Hunderten oder Tausenden von Megabyte haben, alle diese Informationen in den Speicher laden, sie manuell iterieren (wahrscheinlich auf demselben Thread) und dann Ihre Daten manipulieren.

Bei einem Datenbanksystem wird es auf einem eigenen Thread oder sogar auf einem eigenen Server ausgeführt. Alles, was zwischen Ihrem Programm und dem Datenbankserver übertragen wird, ist eine SQL-Abfrage, und alles, was zurück übertragen wird, sind die Daten, auf die Sie zugreifen möchten. Sie laden nicht den gesamten Datensatz in den Speicher - alles, was Sie senden und empfangen, ist ein winziger Bruchteil Ihres gesamten Datensatzes.

Thomas Clayson
quelle
1
1. Bitte laden Sie niemals alle Ihre Benutzerinformationen in den clientseitigen Code! (Ich bin sicher, es war nur ein Beispiel) 2. Das Laden einer Datei, die 100 MB groß ist, wird eine Weile dauern. 3. Ihr Beispiel ist korrekt, es wird jedoch davon ausgegangen, dass Sie immer nur anhand des Benutzernamens suchen. Was passiert, wenn Sie weitere Daten zu einem Benutzer speichern möchten? zB Alter. Jetzt möchten Sie nach allen Benutzern suchen, die zwischen 20 und 30 Jahre alt sind. Oder noch einfacher: Suchen Sie einen Benutzer anhand seiner Adresse, wenn Ihr json so aussieht: {login: {pass: pass, add1: "123 sasd", city: "Wherever"}}.
Thomas Clayson
2
Ihr letzter Punkt ist möglicherweise korrekt, aber dann könnte ich von alten Daten arbeiten - speziell, wenn ich Ihr Programm öffne, die aktuelle Datenbank lade, dann 5 Minuten später sich jemand anderes anmeldet und etwas bearbeitet, ist meine Datenbank jetzt eine spätere Version, bis ich Beenden Sie das Programm und starten Sie es erneut. Wenn ich dann meine Datenbank bearbeite und wieder speichere, überschreibe ich alle Änderungen, die der andere Benutzer vorgenommen hat. Wenn Sie eine Benutzerdatenbank haben, kann dies alles sein, indem Sie nur Ihr Kennwort ändern. Wenn zwei Benutzer ihr Kennwort während der jeweils anderen Sitzungen ändern, wird die Änderung eines Benutzers rückgängig gemacht.
Thomas Clayson
4
Ich habe viel gelernt, nachdem ich einige Dinge über die Indizierung gesucht habe. Es war wirklich aufschlussreich. Datenbanken sind jetzt etwas sinnvoller. Es gibt noch einige Dinge, die ich nicht verstehe, aber das ist ein großer Fortschritt. Danke für diese Antwort!
MaiaVictor
4
Über Indizes, nein, die Datenbank indiziert nicht alles automatisch. Nur wenige Dinge werden automatisch indiziert, während der Rest explizit "Bitte machen Sie dies indiziert" erfordert. Und Indizes reduzieren die Suche auf die logarithmische Zeit O (log (n)), die etwas langsamer als die Konstante ist.
Kaiser Orionii
1
Sich über den Unterschied zwischen einer Hash-basierten und einer B-Tree-basierten Implementierung Gedanken zu machen, ist eine vorzeitige Optimierung. Wenn sich Daten im Index befinden, sind sie immer noch ein Dutzend Mal schneller als das Lesen von der Festplatte.
SilverbackNet
14

Wenn Sie einfache Daten haben, wie eine Liste von Dingen, die Sie in den Kommentaren Ihrer Frage beschreiben, dann gibt Ihnen eine SQL-Datenbank nicht viel. Viele Leute benutzen sie immer noch, weil sie wissen, dass ihre Daten mit der Zeit komplizierter werden können, und es gibt viele Bibliotheken, die die Arbeit mit Datenbanken trivial machen.

Aber selbst mit einer einfachen Liste, die Sie laden, im Speicher halten und dann bei Bedarf schreiben, kann eine Reihe von Problemen auftreten:

Bei einer abnormalen Programmbeendigung können Daten verloren gehen oder beim Schreiben von Daten auf die Festplatte kann ein Fehler auftreten, und Sie können die gesamte Datei löschen. Sie können Ihre eigenen Mechanismen entwickeln, um dies zu handhaben, aber Datenbanken handhaben dies für Sie unter Verwendung von kampferprobten Techniken.

Wenn Ihre Daten zu groß werden und zu oft aktualisiert werden, wird das Serialisieren und Speichern all Ihrer Daten ein großes Problem sein und alles verlangsamen. Sie müssten sich überlegen, wie die Dinge aufgeteilt werden sollen, damit es nicht so teuer wird. Datenbanken sind so optimiert, dass nur die Dinge, die sich auf der Festplatte ändern, fehlertolerant gespeichert werden. Außerdem sind sie so konzipiert, dass Sie schnell und einfach die kleinen Datenmengen laden können, die Sie zu einem bestimmten Zeitpunkt benötigen.

Außerdem müssen Sie keine SQL-Datenbanken verwenden. Sie können NoSQL- "Datenbanken" verwenden, was viele tun. Verwenden Sie einfach JSON, um die Daten zu speichern. Dies geschieht jedoch fehlertolerant und so, dass die Daten intelligent auf mehrere Computer verteilt, abgefragt und intelligent aufgeteilt werden können.

Außerdem vermischen manche Leute die Dinge. Sie könnten einen NoSQL-Datenspeicher wie Redis zum Speichern von Anmeldeinformationen verwenden. Verwenden Sie dann relationale Datenbanken, um komplexere Daten dort zu speichern, wo sie interessantere Abfragen ausführen müssen.

Keith Nicholas
quelle
12

Ich sehe viele Antworten, die sich auf das Problem der Nebenläufigkeit und Zuverlässigkeit konzentrieren. Datenbanken bieten neben Parallelität, Zuverlässigkeit und Leistung weitere Vorteile. Sie erlauben es, sich keine Gedanken darüber zu machen, wie Bytes und Zeichen im Speicher dargestellt werden. Mit anderen Worten, Datenbanken ermöglichen es dem Programmierer, sich auf das "Was" und nicht auf das "Wie" zu konzentrieren.

In einer der Antworten werden Fragen genannt. "SQL-Datenbank eine Frage stellen" lässt sich gut an die Komplexität einer Frage anpassen. Während sich der Code während der Entwicklung entwickelt, können einfache Abfragen wie "Alle abrufen" leicht zu "Alle abrufen, bei denen Eigenschaft1 diesem Wert entspricht, und dann nach Eigenschaft2 sortieren", ohne dass sich der Programmierer darum bemüht, die Datenstruktur für eine solche Abfrage zu optimieren. Die Leistung der meisten Abfragen kann beschleunigt werden, indem ein Index für eine bestimmte Eigenschaft erstellt wird.

Ein weiterer Vorteil sind Beziehungen. Bei Abfragen ist es übersichtlicher, Daten aus verschiedenen Datensätzen mit verschachtelten Schleifen zu verknüpfen. Beispielsweise kann die Suche nach allen Forumsbeiträgen von Benutzern mit weniger als 3 Beiträgen in einem System, in dem Benutzer und Beiträge unterschiedliche Datensätze (oder DB-Tabellen oder JSON-Objekte) sind, mit einer einzigen Abfrage durchgeführt werden, ohne die Lesbarkeit zu beeinträchtigen.

Alles in allem sind SQL-Datenbanken besser als einfache Arrays, wenn das Datenvolumen groß sein kann (sagen wir mehr als 1000 Objekte), der Datenzugriff in nicht trivialen und unterschiedlichen Teilen des Codes auf unterschiedliche Teilmengen von Daten zugreift.

Kaiser Orionii
quelle
Ich bin ein bisschen misstrauisch über die Idee, dass man einfach ignorieren kann, wie Sachen dargestellt werden. Während Sie dies ignorieren können, wenn Sie dies tun, und esp. Wenn Sie eine etwas komplexere Abfrage schreiben, kann Ihre Anwendung höchstwahrscheinlich nicht mehr skaliert werden. "Hinzufügen eines Index" ist nicht immer möglich - Sie müssen sich mit Schreibvorgängen auseinandersetzen, und bei Abfragen, deren Komplexität sich über mehrere Tabellen erstreckt, hilft dies einfach nicht viel. Wenn Indizes erforderlich sind , haben Sie den Vorteil der interaktiven Abfragbarkeit verloren, da nur speziell strukturierte Abfragen in angemessener Zeit beantwortet werden können.
Eamon Nerbonne
12

TLDR

Anscheinend haben Sie eine im Wesentlichen gültige, kurzfristige technische Entscheidung für den Datenspeicher für Ihre Anwendung getroffen. Sie haben sich entschieden, ein benutzerdefiniertes Datenspeicherverwaltungstool zu schreiben.

Sie sitzen auf einem Kontinuum und haben die Möglichkeit, sich in beide Richtungen zu bewegen.

Langfristig werden Sie wahrscheinlich (aber mit Sicherheit nicht zu 100%) in Schwierigkeiten geraten und es ist möglicherweise besser, auf die Verwendung vorhandener Datenspeicherlösungen umzusteigen. Es gibt bestimmte, sehr häufige, vorhersehbare Leistungsprobleme, mit denen Sie sich auseinandersetzen müssen, und Sie sind besser dran, vorhandene Tools zu verwenden, als Ihre eigenen zu verwenden.


Es hört sich so an, als hätten Sie eine (kleine) benutzerdefinierte Datenbank geschrieben, die in Ihre Anwendung integriert ist und von dieser direkt verwendet wird. Ich gehe davon aus, dass Sie sich auf ein Betriebssystem und ein Dateisystem verlassen, um das tatsächliche Schreiben und Lesen von Datenträgern zu verwalten und die Kombination als Datenspeicher zu behandeln.

Wann tun, was du getan hast?

Sie sitzen an einem Sweet-Spot für die Datenspeicherung. Ein Datenspeicher für Betriebssysteme und Dateisysteme ist unglaublich praktisch, zugänglich und plattformübergreifend portierbar. Die Kombination gibt es schon so lange, dass Sie sicher sind, dass Ihre Anwendung in nahezu jeder Standardbereitstellungskonfiguration unterstützt und ausgeführt wird.

Es ist auch eine einfache Kombination, für die Code geschrieben werden kann - die API ist recht einfach und grundlegend, und es sind relativ wenige Codezeilen erforderlich, um sie zum Laufen zu bringen.

Im Allgemeinen ist es ideal, das zu tun, was Sie getan haben, wenn:

  • Prototyping neuer Ideen
  • Erstellen von Anwendungen, bei denen eine Skalierung in Bezug auf die Leistung höchstwahrscheinlich nicht erforderlich ist
  • Eingeschränkt durch ungewöhnliche Umstände wie fehlende Ressourcen für die Installation einer Datenbank

Alternativen

Sie befinden sich auf einem Kontinuum von Optionen und es gibt zwei Richtungen, in die Sie von hier aus gehen können, die ich als "unten" und "oben" betrachte:

Nieder

Dies ist die am wenigsten wahrscheinliche Option, aber der Vollständigkeit halber hier:

Sie können, wenn Sie wollen, gehen nach unten , das heißt, umgeht das Betriebssystem und Dateisystem insgesamt und wirklich schreiben und direkt von der Festplatte gelesen werden . Diese Auswahl ist normalerweise nur in Fällen relevant, in denen extreme Effizienz erforderlich ist - denken Sie beispielsweise an ein minimales / winziges MP3- Player-Gerät ohne genügend RAM für ein voll funktionsfähiges Betriebssystem oder an etwas wie die Wayback-Maschine , das eine unglaublich effiziente Masse erfordert Datenschreibvorgänge (die meisten Datenspeicher tauschen langsamere Schreibvorgänge gegen schnellere Lesevorgänge aus, da dies der am weitesten verbreitete Anwendungsfall für fast alle Anwendungen ist).

Nach oben

Hier gibt es mehrere Unterkategorien - diese sind jedoch nicht gerade exklusiv. Einige Tools umfassen beide Funktionen, einige können vollständig von einem Modus zum anderen wechseln, und einige können übereinander gelegt werden, wodurch verschiedene Funktionen für verschiedene Teile Ihrer Anwendung bereitgestellt werden.

Leistungsstärkere Datenspeicher

Möglicherweise müssen Sie immer größere Datenmengen speichern und müssen sich dennoch auf Ihre eigene Anwendung verlassen, um die Komplexität der Datenmanipulation zu bewältigen. Ihnen steht eine ganze Reihe von Schlüsselwertspeichern zur Verfügung, die in unterschiedlichem Umfang verwandte Funktionen unterstützen. NoSQL- Tools fallen ebenso wie andere in diese Kategorie.

Dies ist der naheliegende Skalierungspfad, wenn im Folgenden Ihre Anwendung beschrieben wird:

  • Es ist ungewöhnlich stark leseabhängig
  • Es ist in Ordnung, höhere Leistung gegen niedrigere (kurzfristige) Konsistenzgarantien auszutauschen (viele bieten "letztendlich Konsistenz" an).
  • Verwaltet "direkt" den größten Teil der Datenmanipulation und mangelnde Konsistenz (in der Praxis werden Sie wahrscheinlich zuerst ein Drittanbieter-Tool verwenden, obwohl Sie dies schließlich in Ihre Anwendung oder in eine benutzerdefinierte geschriebene Zwischenschicht bringen werden) .
  • Sie möchten die Datenmenge, die Sie speichern, und / oder die Fähigkeit, sie zu durchsuchen, mit "relativ einfachen" Datenmanipulationsanforderungen massiv skalieren.

Hier gibt es etwas Spielraum - Sie können eine bessere Lesekonsistenz für langsamere Lesevorgänge erzwingen. Verschiedene Tools und Optionen bieten Datenmanipulations-APIs, Indizierungs- und andere Optionen, die mehr oder weniger zum einfachen Schreiben Ihrer spezifischen Anwendung geeignet sind. Wenn die obigen Punkte Ihre Anwendung also fast vollständig beschreiben, sind Sie möglicherweise "nah genug", um mit einer leistungsstärkeren Datenspeicherlösung zu arbeiten.

Bekannte Beispiele: CouchDB , MongoDB , Redis , Cloud-Speicherlösungen wie Microsoft Azure , Google App Data Store und Amazon ECE.

Komplexere Datenmanipulations-Engines

Die "SQL" -Familie von Datenspeicheranwendungen sowie eine Reihe anderer Anwendungen werden besser als Datenmanipulations-Tools beschrieben als reine Speicher-Engines. Sie bieten eine breite Palette zusätzlicher Funktionen, die über die Speicherung von Daten hinausgehen und häufig über das hinausgehen, was im Geschäft mit Schlüsselwerten verfügbar ist. Sie möchten diesen Weg einschlagen, wenn:

  • Sie müssen unbedingt über Lesekonsistenz verfügen, auch wenn dies bedeutet, dass Sie einen Leistungseinbruch erleiden.
  • Sie möchten hochkomplexe Datenmanipulationen effizient durchführen - denken Sie an sehr komplexe JOIN- und UPDATE-Operationen, Datenwürfel und -schnitte usw.
  • Es ist in Ordnung, die Rigidität für die Leistung abzuwägen (denken Sie an erzwungene, feste Datenspeicherformate wie Tabellen, die nicht einfach und / oder effizient geändert werden können).
  • Sie haben die Ressourcen, um mit häufig komplexeren Tools und Schnittstellen umzugehen.

Dies ist die "traditionellere" Denkweise für eine Datenbank oder einen Datenspeicher, die es schon viel länger gibt. Es gibt also eine Menge , die hier verfügbar ist, und es ist häufig eine Menge Komplexität zu bewältigen. Es ist möglich, obwohl es einige Fachkenntnisse und Kenntnisse erfordert und einfache Lösungen schafft / einen Großteil der Komplexität vermeidet - Sie werden jedoch höchstwahrscheinlich Tools und Bibliotheken von Drittanbietern verwenden, um das meiste davon für Sie zu verwalten.

Bekannte Beispiele sind MySQL , SQL Server , Oracle's Database und DB2 .

Die Arbeit auslagern

Es gibt verschiedene moderne Tools und Bibliotheken von Drittanbietern, die sich zwischen Ihren Datenspeichertools und Ihrer Anwendung befinden, um Sie bei der Verwaltung der Komplexität zu unterstützen.

Sie versuchen, den größten Teil oder die gesamte Arbeit, die für die Verwaltung und Bearbeitung von Datenspeichern erforderlich ist, anfangs wegzunehmen. Im Idealfall können Sie den Übergang zur Komplexität nur dann reibungslos vollziehen, wenn dies erforderlich ist. Dies ist ein aktiver Bereich des Unternehmertums und der Forschung, mit einigen aktuellen Ergebnissen, die sofort zugänglich und verwertbar sind.

Bekannte Beispiele sind MVC- Tools ( Django , Yii ), Ruby on Rails und Datomic . Es ist schwierig, hier fair zu sein, da es buchstäblich Dutzende von Tools und Bibliotheken gibt, die als Wrapper um die APIs verschiedener Datenspeicher fungieren.


PS: Wenn Sie Videos dem Text vorziehen, möchten Sie vielleicht einige von Rich Hickeys datenbankbezogenen Videos ansehen. Er macht einen guten Job darin, den größten Teil der Überlegungen zu klären, die bei der Auswahl, Gestaltung und Verwendung eines Datenspeichers anfallen.

Blaubeerfelder
quelle
11

Ein Dateisystem passt zur Beschreibung einer NoSQL-Datenbank. Ich würde also sagen, Sie sollten es unbedingt in Betracht ziehen, wenn Sie sich für die Speicherung Ihrer Daten entscheiden und sie nicht einfach zugunsten von RDBMS verwerfen, wie einige Antworten hier nahe legen.

Ein Problem mit Dateisystemen (und NoSQL im Allgemeinen) ist die Behandlung von Beziehungen zwischen Daten. Wenn das hier kein Hauptblocker ist, dann würde ich das RDBMS fürs Erste überspringen. Denken Sie auch an die positiven Aspekte der Verwendung eines Dateisystems als Speicher:

  • Keine Administration
  • Geringe Komplexität, einfach einzurichten
  • Funktioniert mit jedem Betriebssystem, jeder Sprache, Plattform, Bibliothek usw
  • Die einzige Konfigurationseinstellung ist das Verzeichnis
  • Trivial zu testen
  • Einfach mit vorhandenen Tools zu untersuchen, zu sichern, zu modifizieren usw
  • Gute Leistungseigenschaften und vom Betriebssystem gut abgestimmt
  • Für jeden Entwickler leicht zu verstehen
  • Keine Abhängigkeiten, keine zusätzlichen Treiber
  • Das Sicherheitsmodell ist trivial zu verstehen und ein grundlegender Bestandteil des Betriebssystems
  • Daten sind nicht von außen zugänglich

( Quelle )

Martin Wickman
quelle
10

Dateisysteme sind eine Art Datenbank. Vielleicht nicht ein RDBMS wie alle anderen, aber sicherlich eine DB im engsten Sinne. Sie stellen Schlüssel (Dateinamen) für die Suche nach Daten (Dateiinhalten) bereit, die über abstrahierten Speicher und eine API verfügen, über die Ihr Programm kommuniziert.

Sie verwenden also eine Datenbank. Die anderen Beiträge können über die Vorzüge verschiedener Arten von Datenbanken streiten ...

Chris S
quelle
1
Datenbank und Speicher können nicht wirklich austauschbar verwendet werden. Eine Datenbank ist eine Art Speicher, aber ein Dateisystem ist sicherlich keine Art Datenbank
Gaz_Edge
3
"Speicher" ist, wo Bits und Bytes gehalten werden. Eine Datenbank verwendet nicht unbedingt Dateien in einem Dateisystem. Ein Dateisystem ist mit Sicherheit eine Art Datenbank im engeren Sinne.
Chris S
6
Für jemanden, der argumentiert, dass es in Datenbanken keine Verwendung gibt, wenn er eine Alternative darstellt, ist die Verwendung einer Datenbank . Ja. Es scheint hilfreich zu sein, ihnen zu erklären, dass ihre Argumentation auf einer vorgefassten Vorstellung beruht, die falsch ist. Sobald sie ein besseres Verständnis für ihre Ausgangssituation haben, können wir ihnen helfen, die verfügbaren Technologien besser zu verstehen. Dateisysteme sind hierarchische Datenbanken. Es gibt gute Gründe, warum Beziehungs- und Objektdatenbanksysteme sie als schneller, besser organisiert und effizienter zum Speichern und Abrufen von Daten abgelöst haben.
Chris S
2
@Gaz_Edge Die Daten befinden sich bereits in einer ineffizienten "Datenbank", indem sie in einer Reihe von Dateien gespeichert werden, deren Struktur und Inhalt beide von der OP-Anwendung verwaltet werden. Der Versuch, das OP zu verstehen und zu akzeptieren , ist ein nützlicher erster Schritt, um den Anwendungsfall für ein "echtes" Datenbanksystem zu verstehen. Sobald sie verstehen, dass sowieso eine "Datenbank" vorhanden ist, ist es einfacher, darüber zu sprechen, wo ein ordnungsgemäß strukturierter und verwalteter Service effizienter ist, als die App ihre eigene Sache machen zu lassen. Ich würde vorschlagen, dass diese Antwort sehr hilfreich ist.
Rob Moir
8

Eine Datenbank wird benötigt, wenn mehrere Prozesse (Benutzer / Server) die Daten ändern. Die Datenbank dient dann dazu, zu verhindern, dass sich die Änderungen gegenseitig überschreiben.

Sie benötigen auch eine Datenbank, wenn Ihre Daten größer als der Arbeitsspeicher sind. Heutzutage macht der verfügbare Speicher die Verwendung von Datenbanken in vielen Anwendungen überflüssig.

Ihr Ansatz ist definitiv besser als der Unsinn von "In-Memory-Datenbanken". Welches sind im Wesentlichen Ihr Ansatz, aber mit viel Aufwand hinzugefügt.

funql.org
quelle
Um ehrlich zu sein, ich liebe diese Antwort und möchte, dass sie wahr ist, aber ich bin mir nicht sicher, ob das der Fall ist. Einige Benutzer (und Sie) äußerten beispielsweise Bedenken hinsichtlich des Arbeitsspeichers. Wenn ich Daten im Wert von GB speichere, kann ich natürlich nicht alles im Speicher behalten. Aber was ist, wenn ich sicher bin, dass die Daten niemals so groß sind, sollte ich nur Speicher verwenden? Nun, es gibt auch andere Dinge. Ich habe zum Beispiel die inkrementellen Ansichten von CouchDB kennengelernt. Das ist sicherlich etwas, das anders als die Indizierung NICHT trivial wäre, sich selbst zu implementieren, und es ist sicherlich eine enorme Beschleunigung, wenn Sie ein Ansichtsmodell verwenden,
MaiaVictor
was ich denke ich bin. Wenn ich zum Beispiel Daten von "Spielerliste" in "Rangliste" umwandle, ist dies nichts anderes als eine Kartenverkleinerungsoperation. Beim Erstellen eines Spiels oder einer interaktiven Website ist so ziemlich alles, was Sie präsentieren, eine mapReduce-Operation aus Ihren Kerndaten! Eine solche Optimierung könnte also wirklich wünschenswert sein. Nun, ich habe keine Ahnung, ob irgendetwas von dem, wovon ich spreche, weitergeht, aber das macht Sinn. Heute viel lernen, und ich mag die NoSQL-Konzepte wirklich. Vielen Dank für die Antwort (:
MaiaVictor
7

Sie sollten sich immer fragen, ob eine bestimmte Anwendung ein RDBMS benötigt. Zu viele Anwendungen werden mit einem Entwurfsprozess erstellt, der zu Beginn automatisch alle erforderlichen Tools und Frameworks übernimmt. Relationale Datenbanken sind so verbreitet und viele Entwickler haben bereits an ähnlichen Anwendungen gearbeitet, dass sie vor dem Start des Projekts automatisch einbezogen werden. Viele Projekte können damit durchkommen, also urteilen Sie nicht zu hart.

Sie haben Ihr Projekt ohne eines gestartet, und es funktioniert. Es war einfacher für Sie, dies in Betrieb zu nehmen, ohne auf SQL zu warten. Daran ist nichts auszusetzen.

Da dieses Projekt erweitert wird und die Anforderungen immer komplizierter werden, wird es schwierig, einige Dinge zu erstellen. Woher wissen Sie, welche Methode besser ist, bis Sie alternative Methoden erforschen und testen? Sie können Programmierer bitten, durch die Flammen zu jäten und "es kommt darauf an", diese Frage zu beantworten. Sobald Sie es gelernt haben, können Sie überlegen, wie viele Codezeilen Sie in Ihrer Sprache schreiben möchten, um einige der Vorteile einer Datenbank zu nutzen. Irgendwann erfindest du das Rad neu.

Einfach ist oft relativ. Es gibt einige Frameworks, die eine Webseite erstellen und ein Formular mit einer Datenbanktabelle verbinden können, ohne dass der Benutzer Code schreiben muss. Ich denke, wenn Sie mit der Maus kämpfen, könnte dies ein Problem sein. Jeder weiß, dass dies nicht skalierbar oder flexibel ist, denn Gott bewahre, dass Sie alles eng an die GUI gekoppelt haben. Ein Nicht-Programmierer hat gerade einen Prototyp gebaut. Viele YAGNI sind hier zu finden.

Wenn Sie lieber ein ORM lernen möchten , das von der Sprache Ihrer Wahl manipuliert wird, anstatt SQL zu lernen, versuchen Sie es, installieren, erstellen Sie eine Tabelle und ziehen Sie einige Daten mit SQL aus einer gängigen Datenbank (Wählen Sie * Von; nicht umwerfendes Zeug). Es ist leicht zu machen. Deshalb hat sie jemand geschaffen. Es scheint keine so große Investition zu sein, um eine fundierte Entscheidung zu treffen. Sie könnten wahrscheinlich auch einen Leistungstest durchführen.

JeffO
quelle
Nur zur Erinnerung, ich habe eigentlich jahrelang mysql verwendet, als ich einen "otserv" gehostet habe. Erraten Sie, was? Alles was es brachte waren Probleme. Leute konnten Gegenstände mit einem schmutzigen Trick "klonen", nachdem sie festgestellt hatten, dass ihre Charaktere beim Abmelden gespeichert wurden, aber nicht, als der Server abstürzte. Dies ist ein ernstes Problem für otservs. Und die OTSERV-Community ist riesig. Das würde nicht passieren, wenn sie nur Daten im Speicher ablegen und diese in regelmäßigen Abständen serialisieren würden. Also habe ich den Quellcode, diese langen C ++ - Dateien, selbst modifiziert und angefangen, sie regelmäßig in mysql zu speichern, anstatt wenn sich die Zeichen abgemeldet haben. Erraten Sie, was? Es war langsam!
MaiaVictor
Mysql schaffte es einfach nicht, alle 2 Minuten oder so den Status zu speichern. Es war ziemlich klar, wann die Speicherung stattfand - der gesamte Server "verzögerte" sich für eine Sekunde. Jetzt wäre ich sehr dankbar, wenn die Leute, die hier posten, eine Antwort darauf hätten!
MaiaVictor
1
Beurteilen Sie RDBMS nicht nach dem, was mit einer einzelnen Anwendung passiert ist, die wahrscheinlich schlecht codiert wurde. Insbesondere, wenn die Änderungen zur Unterstützung einer Datenbank von jemandem ohne Datenbankerfahrung vorgenommen wurden.
Alroc
1
@Dokkat, ich hoffe, dass niemand das Stromkabel zwischen der Einzahlung von Geldern auf Ihr Bankkonto und dem "regelmäßigen" Schreiben des Kontostands auf die Festplatte abschaltet. Sie haben eine garantierte Datenverlustarchitektur beschrieben. Das ist für einige Anwendungen in Ordnung, aber die meisten Datenbankanwendungen geben Benutzern die Möglichkeit zu wählen. Sie können einen einzelnen Datenbankknoten mit Sicherungen ausführen und Datenverluste riskieren oder mithilfe der Replikation Datenverluste vermeiden, wenn ein einzelner Knoten ausfällt.
mikerobi
@Dokkat, damit Sie nicht MySQL oder eine andere Datenbank mit vollem Funktionsumfang im Serverstil verwenden. Sie verwenden Sqlite (oder ähnliches) und es bleibt jedes Mal auf der Festplatte, während Sie eine in Ihre App eingebettete Datenbank erhalten (keine separate Installation erforderlich) und trotzdem SQL-Zugriff, Transaktionsintegrität und Festplattenpersistenz erhalten.
gbjbaanb
6

Das Speichern der Daten auf der Festplatte IST Schreiben in eine Datenbank, vor allem , wenn Sie jedes Objekt in einer eigenen Datei mit dem Namen der Datei stellen der Schlüssel zum Datensatz zu sein. Erstellen Sie Unterverzeichnisse basierend auf den ersten Zeichen des Schlüssels, um die Nachschlagezeiten für das Lesen der Datei zu minimieren.

Zum Beispiel würde key = ghostwriter in g / ho / stwriter.json oder g / h / o / stwriter.json oder g / ho / ghostwriter.json oder g / h / o / ghostwriter.json stehen. Wählen Sie Ihr Namensschema basierend auf der Verteilung Ihrer Schlüssel. Wenn es sich um Folgenummern handelt, ist 5/4/3 / 12345.json besser als umgekehrt.

Das ist eine Datenbank, und wenn sie alles tut, was Sie brauchen, dann tun Sie es auf diese Weise. Heutzutage würde das eine NoSQL-Datenbank wie GDBM oder Berkeley db heißen. So viele Möglichkeiten. Stellen Sie zunächst fest, was Sie benötigen, und erstellen Sie dann eine Schnittstellenbibliothek, um die Details zu verarbeiten, z. B. eine get / set-Schnittstelle wie memcached oder eine CRUD-Schnittstelle. Anschließend können Sie Bibliotheken austauschen, wenn Sie das Datenbankformat für eine ändern müssen mit verschiedenen Eigenschaften.

Beachten Sie, dass einige SQL-Datenbanken wie PostgreSQL und Apache Derby DB es Ihnen ermöglichen, SQL-Abfragen über viele NoSQL-Formate hinweg durchzuführen, einschließlich Ihrer eigenen selbst erstellten Datenbanken. Ich bin mir nicht sicher über MyBatis, aber es könnte ähnlich sein.

Vermeiden Sie NoSQL-Hype. Informieren Sie sich über die Funktionen, testen Sie die Leistung und Leistungsfähigkeit und wählen Sie dann aus, wie gut sie Ihren Anwendungsanforderungen entsprechen.

http://www.hdfgroup.org/HDF5/ ist ein weiteres interessantes und weit verbreitetes Datenspeicherformat, das die Leute nicht oft in Betracht ziehen.

Michael Dillon
quelle
4

Sobald die Daten gleichzeitig aktualisiert werden, ist der Ansatz mit einer Datenbank (es könnte sich auch um eine In-Memory-Datenbank handeln) wahrscheinlich korrekter und performanter, während gleichzeitig Ihr Code einfach bleibt, weil Sie es einfach nicht haben Sorgen über gleichzeitige Updates, Transaktionen, Caching, asynchrone E / A und all das.

Ingo
quelle
Die gleichzeitige Änderung innerhalb eines Prozesses ist effizienter, wenn prozessinterne Sperren anstelle von IPC für einen Datenbankdämon verwendet werden, der eine Reihe von Sperren erwirbt. Vermutlich sprechen Sie jedoch von mehreren Prozessen, mit denen die Daten geändert werden.
Dhasenan
@dhasenan - Dies ist ein weiterer Vorteil guter Datenbanksysteme. Sie erhalten die Parallelität und es funktioniert in allen Fällen: Multi-Threaded, Multi-Prozess, mehrere Clients auf verschiedenen Servern oder eine beliebige Kombination davon. Ihr gut durchdachtes Multithread-Programm kann in bestimmten Fällen "effizienter" sein, lässt sich aber einfach nicht skalieren.
Ingo
-5

Sie benötigen eine Datenbank zum Speichern / Abrufen von QAs, wie wir sie hier veröffentlichen! Eine einfache Datei kann keine Daten zu verschiedenen Themen organisieren.

Joe
quelle
3
Nein, "Themen" können Ordner sein, und die "Beiträge" auf der Site können Dateien sein. Es ist definitiv möglich, eine Site wie diese von einem Dateisystem aus zu betreiben. Es ist nicht effizient: langsam und kompliziert zu entwickeln, Abfragen auszuführen, neue Daten einzufügen usw.
Chris S
langsam + kompliziert = unfähig?
Joe
Langsam und kompliziert zu bauen! = Langsam und kompliziert zu funktionieren
Joe
1
@ Joe, es ist wirklich nicht wahr, dass eine Datei (vielleicht keine "einfache" Datei, aber was bedeutet das?) nicht zum Organisieren von Daten verwendet werden kann, die sich auf verschiedene Themen beziehen. Sie könnten JSON, wie von Dokkat vorgeschlagen, oder XML oder Dateien mit gemischten Datensätzen verwenden, wie wir es in den Tagen vor XML getan haben, oder welches Dateiformat auch immer Sie sich vorstellen können. Ich würde keinen dieser Ansätze für die meisten Szenarien empfehlen, aber das bedeutet nicht, dass sie nicht durchgeführt werden können.
John M Gant
@John M Gant: Stimmen Sie voll und ganz zu, Datenbanken können keine einzelnen Dateien ersetzen (da Sie keine einfachen mögen) und umgekehrt, nur aus dem Grund, dass ein Auto kein Fahrrad ersetzen kann. Ich spreche 3 "menschliche" Sprachen, und meine Wahl der Wörter und Vokabeln ist der Grund, warum ich missverstanden wurde ... Ich denke
Joe