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

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?

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.

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.

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.

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.

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.

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.

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 )

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

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.

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.

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.

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.

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.