it-swarm.com.de

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

Anstelle einer Datenbank serialisiere ich meine Daten einfach in JSON, speichere sie und lade sie bei Bedarf auf die Festplatte. Die gesamte Datenverwaltung erfolgt über das Programm selbst, was schneller UND einfacher ist 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 nur die Daten auf der Festplatte zu speichern?

201
MaiaVictor
  1. Sie können Daten in einer Datenbank abfragen (Fragen stellen).
  2. Sie können relativ schnell Daten aus einer Datenbank abrufen.
  3. Mit JOINs können Sie Daten aus zwei verschiedenen Tabellen 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; 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 kluger Menschen entwickelt wurden.

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

283
Robert Harvey

Obwohl ich mit allem, was Robert sagte, einverstanden bin, hat er Ihnen nicht gesagt, wann Sie eine Datenbank verwenden sollten, anstatt nur die Daten 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, d. H. 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 Gedanken über die zuvor festgestellten Probleme machen: Skalierbarkeit, Zuverlässigkeit, ACID-Konformität
  • Sie müssen Berichts- oder Intelligence-Tools verwenden, um geschäftliche Probleme zu lösen

Wann sollte ein NoSQL verwendet werden?

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

Schließlich, wann Dateien verwendet werden sollen

  • Sie haben unstrukturierte Daten in angemessenen Mengen, die das Dateisystem verarbeiten kann
  • Sie interessieren sich nicht für Struktur, Beziehungen
  • Skalierbarkeit oder Zuverlässigkeit sind Ihnen egal (obwohl dies je nach Dateisystem möglich ist).
  • Sie möchten oder können nicht mit dem Overhead umgehen, den eine Datenbank hinzufügen wird
  • Sie haben es mit strukturierten Binärdaten zu tun, die in das Dateisystem gehören, zum Beispiel: Bilder, PDFs, Dokumente usw.
204
Sam

Eine Sache, die niemand erwähnt zu haben scheint, ist die Indizierung 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 ist nur eine Reihe von Datensätzen, die auf der Festplatte gespeichert sind. Unabhängig davon, ob Sie die Datei erstellen oder MySQL , SQLite oder was auch immer die Datei (en) erstellt, 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 in den Sinn kommt, 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 iterieren relativ schnell.

Stellen Sie sich vor, Sie haben 10.000, 100.000 oder sogar 1.000.000 Datensätze. Wenn jemand versucht, sich anzumelden, müssen Sie eine Datei öffnen, die jetzt mehrere hundert Megabyte groß ist, sie in den Speicher Ihres Programms laden, ein ähnlich großes Informationsarray abrufen und dann Hunderttausende von Datensätzen durchlaufen Suchen Sie den 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 dies mit etwas wie Memcached oder sogar einem selbstgebrauten Caching-System (speichern Sie beispielsweise die Ergebnisse einer Suche 10 Minuten lang in einer separaten Tabelle und laden Sie diese Ergebnisse, falls jemand anderes nach dem sucht Das Gleiche bald danach), und Sie werden blitzschnelle Abfragen haben, die Sie mit einem so großen Datensatz nicht erhalten, 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, wenn Sie Dateien mit Hunderten oder Tausenden von Megabyte haben, müssen Sie all diese Informationen in den Speicher laden, sie manuell iterieren (wahrscheinlich im selben Thread) und dann Ihre Daten bearbeiten.

Mit 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.

57
Thomas Clayson

TLDR

Es hört sich so an, als hätten Sie eine im Wesentlichen gültige, kurzfristige technische Entscheidung für den Datenspeicher für Ihre Anwendung getroffen. Sie haben sich für ein benutzerdefiniertes Tool zur Verwaltung des Datenspeichers entschieden.

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

Auf lange Sicht werden Sie wahrscheinlich (fast, aber nicht zu 100% sicher) in Schwierigkeiten geraten und möglicherweise besser auf die Verwendung vorhandener Datenspeicherlösungen umsteigen. Es gibt bestimmte, sehr häufige, vorhersehbare Leistungsprobleme, mit denen Sie sich befassen müssen, und Sie sollten vorhandene Tools besser verwenden, als Ihre eigenen zu rollen.


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 eigentliche Schreiben und Lesen der Festplatte zu verwalten und die Kombination als Datenspeicher zu behandeln.

Wann tun, was Sie getan haben?

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

Es ist auch eine einfache Kombination, Code für zu schreiben - die API ist ziemlich 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 es sehr unwahrscheinlich ist, dass sie hinsichtlich der Leistung skaliert werden müssen
  • 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 von hier aus können Sie zwei "Richtungen" einschlagen, die ich als "unten" und "oben" betrachte:

Nieder

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

Wenn Sie möchten, können Sie nach unten gehen, dh das Betriebssystem und das Dateisystem insgesamt umgehen und direkt von der Festplatte schreiben und lesen. Diese Auswahl ist normalerweise nur in Fällen relevant, in denen extreme Effizienz erforderlich ist - denken Sie beispielsweise an ein minimales/winziges MP Player-Gerät ohne genügend RAM für ein voll funktionsfähiges Betriebssystem oder für etwas wie Wayback Machine , das unglaublich effiziente Massendatenschreibvorgänge erfordert (die meisten Datenspeicher tauschen langsamere Schreibvorgänge gegen schnellere Lesevorgänge aus, da dies überwiegend der Fall ist häufigerer Anwendungsfall für fast alle Anwendungen).

Oben

Hier gibt es mehrere Unterkategorien - diese sind jedoch nicht gerade exklusiv. Einige Tools umfassen beide Funktionen und bieten jeweils Funktionen. Einige können vollständig von der Arbeit in einem Modus zur Arbeit in der anderen wechseln. Einige Tools können übereinander geschichtet werden und bieten unterschiedliche Funktionen für verschiedene Teile Ihrer Anwendung.

Leistungsstärkere Datenspeicher

Möglicherweise müssen Sie immer größere Datenmengen speichern, während Sie sich weiterhin auf Ihre eigene Anwendung verlassen, um die Komplexität der Datenmanipulation zu verwalten. Ihnen steht eine ganze Reihe von Schlüsselwertspeichern mit unterschiedlichem Support für verwandte Funktionen zur Verfügung. NoSQL Tools fallen ebenso wie andere in diese Kategorie.

Dies ist der naheliegende Weg, um die Skalierbarkeit zu verbessern, wenn im Folgenden Ihre Anwendung beschrieben wird:

  • Es ist ungewöhnlich stark leseabhängig
  • Sie können eine höhere Leistung gegen niedrigere (kurzfristige) Konsistenzgarantien eintauschen (viele bieten "eventuelle Konsistenz").
  • 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 einbringen werden). .
  • Sie möchten die Menge der gespeicherten Daten und/oder Ihre 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 APIs zur Datenmanipulation, Indizierung und andere Optionen, die möglicherweise mehr oder weniger zum einfachen Schreiben Ihrer spezifischen Anwendung geeignet sind. Wenn die oben genannten Punkte Ihre Anwendung 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 Datenmanipulationswerkzeuge 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 auf der Seite des Schlüsselwertspeichers verfügbar ist. Sie möchten diesen Weg einschlagen, wenn:

  • Sie müssen unbedingt Lesekonsistenz haben, 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 Slicing usw.
  • Es ist in Ordnung, die Starrheit gegen die Leistung auszutauschen (denken Sie an erzwungene, feste Datenspeicherformate wie Tabellen, die nicht einfach und/oder effizient geändert werden können).
  • Sie verfügen über die Ressourcen, um mit häufig komplexeren Tools und Schnittstellen umzugehen.

Dies ist die "traditionellere" Denkweise einer Datenbank oder eines Datenspeichers und gibt es schon viel länger - es gibt also eine Menge, die hier verfügbar ist, und es gibt oft viel Komplexität damit umgehen. Es ist möglich, obwohl es einige Fachkenntnisse und Kenntnisse erfordert und einfache Lösungen erstellt/einen Großteil der Komplexität vermeidet - Sie werden 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 mehrere moderne Tools und Bibliotheken von Drittanbietern, die sich zwischen Ihren Datenspeicher-Tools und Ihrer Anwendung befinden, um Sie bei der Verwaltung der Komplexität zu unterstützen.

Sie versuchen zunächst, den größten Teil oder die gesamte Arbeit für die Verwaltung und Bearbeitung von Datenspeichern wegzunehmen, und ermöglichen Ihnen im Idealfall nur dann einen reibungslosen Übergang in die Komplexität, wenn dies erforderlich ist. Dies ist ein aktiver Bereich des Unternehmertums und der Forschung, mit einigen jüngsten Ergebnissen, die sofort zugänglich und nutzbar sind.

Bekannte Beispiele sind MVC tools ( Django , Yii ), Ruby on Rails und Datomic . Es ist schwer, 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 möglicherweise einige der datenbankbezogenen Videos von Rich Hickey ansehen. Er macht einen guten Job, um den größten Teil des Denkens zu klären, das bei der Auswahl, Gestaltung und Verwendung eines Datenspeichers anfällt.

14
blueberryfields

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

Aber selbst bei einer einfachen Liste, die Sie laden, im Speicher halten und bei Bedarf schreiben, kann es zu einer Reihe von Problemen kommen:

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 beenden. Sie können Ihre eigenen Mechanismen verwenden, um dies zu handhaben, aber Datenbanken erledigen dies für Sie mit kampferprobten Techniken.

Wenn Ihre Daten zu groß werden und zu oft aktualisiert werden, wird das Serialisieren aller Daten und das Speichern ein großer Ressourcenverbrauch sein und alles verlangsamen. Sie müssten anfangen, herauszufinden, wie man Dinge partitioniert, 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 Datenbits 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 aufgeteilt, abgefragt und intelligent aufgeteilt werden können.

Auch einige Leute vermischen die Dinge. Sie verwenden möglicherweise einen NoSQL-Datenspeicher wie Redis zum Speichern von Anmeldeinformationen. Verwenden Sie dann relationale Datenbanken, um komplexere Daten dort zu speichern, wo sie interessantere Abfragen durchführen müssen.

14
Keith Nicholas

Ich sehe viele Antworten, die sich auf das Problem der Parallelität und Zuverlässigkeit konzentrieren. Datenbanken bieten neben Parallelität, Zuverlässigkeit und Leistung weitere Vorteile. Sie ermöglichen es, sich nicht darum zu kümmern, wie Bytes und Zeichen im Speicher dargestellt werden. Mit anderen Worten, Datenbanken ermöglichen es dem Programmierer, sich auf "was" und nicht auf "wie" zu konzentrieren.

In einer der Antworten werden Fragen erwähnt. "SQL-Datenbank eine Frage stellen" lässt sich gut mit der Komplexität einer Frage skalieren. Während sich der Code während der Entwicklung entwickelt, können einfache Abfragen wie "Alle abrufen" leicht zu "Alle abrufen, wenn Eigenschaft1 diesem Wert entspricht, und dann nach Eigenschaft2 sortieren" erweitert werden, ohne dass der Programmierer die Datenstruktur für eine solche Abfrage optimieren muss. 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 sauberer, Daten aus verschiedenen Datensätzen zu referenzieren, als verschachtelte Schleifen zu haben. Beispielsweise kann die Suche nach allen Forenbeiträ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 verschiedenen Teilen des Codezugriffs auf verschiedene Teilmengen von Daten.

12
Emperor Orionii

Ein Dateisystem passt zur Beschreibung einer NoSQL-Datenbank, daher würde ich sagen, dass Sie dies unbedingt in Betracht ziehen sollten, wenn Sie entscheiden, wie Ihre Daten gespeichert werden sollen, und sie nicht einfach zugunsten von RDBMS verwerfen, wie einige Antworten hier zu vermuten scheinen.

Ein Problem mit Dateisystemen (und NoSQL im Allgemeinen) ist die Behandlung von Beziehungen zwischen Daten. Wenn das hier kein großer Blocker ist, würde ich sagen, überspringen Sie das RDBMS vorerst. Denken Sie auch an die positiven Seiten der Verwendung eines Dateisystems als Speicher:

  • Keine Verwaltung
  • Geringe Komplexität, einfach einzurichten
  • Funktioniert mit jedem Betriebssystem, jeder Sprache, Plattform, Bibliothek usw.
  • Die einzige Konfigurationseinstellung ist das Verzeichnis
  • Trivial zu testen
  • Trivial mit vorhandenen Tools zu überprüfen, zu sichern, zu ändern 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 extern zugänglich

( Quelle )

11
Martin Wickman

Dateisysteme sind eine Art Datenbank. Vielleicht nicht ein RDBMS wie alle anderen, aber sicherlich eine DB im strengsten Sinne. Sie stellen Schlüssel (Dateiname) zum Nachschlagen von Daten (Dateiinhalt) bereit, die über einen 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 ...

9
Chris S

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

Sie benötigen auch eine Datenbank, wenn Ihre Daten größer als der Speicher 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 Overhead hinzugefügt.

8
funql.org

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 wie zuvor an ähnlichen Anwendungen gearbeitet, dass sie vor Projektstart automatisch einbezogen werden. Viele Projekte können damit durchkommen, also urteilen Sie nicht zu hart.

Sie haben Ihr Projekt ohne eins gestartet und es funktioniert. Es war einfacher für Sie, dies zum Laufen zu bringen, ohne auf SQL zu warten. Daran ist nichts auszusetzen.

Da dieses Projekt erweitert wird und die Anforderungen komplizierter werden, werden einige Dinge schwierig zu bauen sein. Woher wissen Sie, welche besser ist, bis Sie alternative Methoden erforschen und testen? Sie können auf Programmierer fragen und durch die Flammen 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 erfinden Sie 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, weil Gott es verbietet, dass Sie alles eng mit der GUI verbunden haben. Ein Nicht-Programmierer hat gerade einen Prototyp gebaut. viele YAGNI 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, aber versuchen Sie es zu installieren, erstellen Sie eine Tabelle und ziehen Sie Einige Daten aus einer beliebten Datenbank mit SQL (Wählen Sie * Von; ist nicht umwerfend). Es ist einfach zu machen. Deshalb hat sie jemand zuerst 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.

7
JeffO

Das Speichern der Daten auf der Festplatte [~ # ~] bedeutet [~ # ~] , sie in eine Datenbank zu schreiben, insbesondere wenn Sie jedes Objekt in eine eigene Datei einfügen Der Name der Datei ist der Schlüssel zum Datensatz. Um die Suchzeiten für das Lesen der Datei zu minimieren, erstellen Sie Unterverzeichnisse basierend auf den ersten Zeichen des Schlüssels.

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 gehen. Wählen Sie Ihr Namensschema basierend auf der Verteilung Ihrer Schlüssel. Wenn es sich um Sequenznummern 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 so. Heutzutage würde man das eine NoSQL-Datenbank wie GDBM oder Berkeley db nennen. So viele Möglichkeiten. Stellen Sie zuerst 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 ändern müssen mit unterschiedlichen Eigenschaften.

Beachten Sie, dass einige SQL-Datenbanken wie PostgreSQL und Apache Derby DB es Ihnen ermöglichen, SQL-Abfragen zusätzlich zu vielen NoSQL-Formaten durchzuführen, einschließlich Ihrer eigenen selbst erstellten Datenbanken. Ich bin mir bei MyBatis nicht sicher, aber es kann ähnlich sein.

Vermeiden Sie NoSQL-Hype. Informieren Sie sich über die Funktionen, testen Sie die Leistung und die Funktionen 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 nicht oft in Betracht gezogen wird.

6
Michael Dillon

Sobald die Daten gleichzeitig aktualisiert werden, ist der Ansatz, eine Datenbank zu verwenden (es könnte sich durchaus um eine In-Memory-Datenbank handeln), wahrscheinlich korrekter und leistungsfähiger, während Ihr Code gleichzeitig einfach bleibt, da Sie dies einfach nicht haben Sorgen um gleichzeitige Aktualisierungen, Transaktionen, Caching, asynchrone E/A und all das.

4
Ingo