Sind flache Dateidatenbanken gut?

Question

Informierte Optionen benötigt über die Vorteile der Flat-File-Datenbank. Ich überlege, ein einfaches Datei-Datenbank-Schema zu verwenden, um Daten für ein benutzerdefiniertes Blog zu verwalten. Es würde auf einer Linux-OS-Variante bereitgestellt und in Java geschrieben werden.

Was sind die möglichen Nachteile oder Vorteile hinsichtlich der Leistung beim Lesen und Schreiben von Artikeln und Kommentaren?

Wäre der Artikelabruf wegen der Tatsache, dass es sich um eine flache Datei handelt, eher als um ein RDBMS, wenn es slashdoted werden sollte? (Wunschdenken)

Ich bin nicht gegen die Verwendung eines RDBMS, nur die Community ihre Meinung über die Tragfähigkeit eines solchen Software-Architektur-Schema zu fragen.

Follow Up: Bei dieser Frage würde ich „Flat-Datei == Dateisystem-basierte“ Zum Beispiel jeden Blog-Eintrag und die zugehörigen Metadaten sehen in einer einzigen Datei wären. Herstellung für viele Dateien nach Datum Struktur der Datei-Ordner organisiert (Blogs \ testblog2 \ 2008 \ 12 \ 01) == 12/01/2008

Answer 1

Flat-File-Datenbanken haben ihren Platz und sind für die richtige Domäne recht brauchbar.

E-Mail-Server und NNTP-Server der Vergangenheit schoben wirklich die Grenzen, wie weit Sie diese Dinge wirklich nehmen können (was eigentlich ziemlich weit ist - Dateisysteme können Millionen von Dateien und Verzeichnissen haben).

Flat File DBs Die zwei größten Schwächen sind Indexierung und atomare Updates, aber wenn die Domain geeignet ist, sind diese möglicherweise kein Problem.

Aber Sie können, zum Beispiel, mit der richtigen Verriegelung, eine "atomare" Index-Update mit grundlegenden Dateisystem-Befehle, zumindest unter Unix.

In einem einfachen Fall wird der Indizierungsprozess durch die Daten ausgeführt, um die neue Indexdatei unter einem temporären Namen zu erstellen. Wenn Sie fertig sind, benennen Sie einfach die alte Datei über die neue Datei um (entweder den Systemaufruf umbenennen (2) oder den Befehl shell mv). Rename und MV sind atomare Operationen auf einem Unix-System (d. H. Es funktioniert entweder oder es nicht und es gibt nie einen fehlenden "Zwischenzustand").

Gleiches mit dem Erstellen neuer Einträge.Im Grunde schreiben Sie die Datei vollständig in eine temporäre Datei, benennen Sie sie dann um oder bringen Sie sie an ihren endgültigen Platz. Dann haben Sie nie eine "Zwischen" -Datei in der "DB". Andernfalls haben Sie möglicherweise eine Race-Bedingung (z. B. wenn ein Prozess eine Datei liest, die noch geschrieben wird und möglicherweise bis zum Ende des Schreibvorgangs zu Ende geht - hässliche Race-Bedingung).

Wenn Ihre primäre Indizierung gut mit Verzeichnisnamen funktioniert, funktioniert das problemlos. Sie können beispielsweise ein Hashing-Schema verwenden, um Verzeichnisse und Unterverzeichnisse zum Suchen neuer Dateien zu erstellen.

Das Finden einer Datei mit dem Dateinamen und der Verzeichnisstruktur ist sehr schnell, da die meisten Dateisysteme heute ihre Verzeichnisse indexieren.

Wenn Sie eine Million Dateien in einem Verzeichnis speichern, kann es zu Optimierungsproblemen kommen, in denen Sie suchen sollten, aber außerhalb dieser Box werden die meisten Zehntausende problemlos verarbeitet. Denken Sie daran, dass, wenn Sie das Verzeichnis durchsuchen müssen, viele Dateien zu scannen sind. Die Partitionierung über Verzeichnisse verhindert dies.

Aber das hängt alles von Ihren Indexierungs- und Suchtechniken ab.

Effektiv ist ein Vorrat aus dem Regal Web-Server, der statischen Inhalt dient eine große, flache Datei-Datenbank, und das Modell funktioniert ziemlich gut.

Schließlich haben Sie natürlich die Fülle von freien Unix-Dateisystem-Tools zur Verfügung, aber sie alle haben Probleme mit Zillionen von Dateien (Forking 1000000 grep, um etwas in einer Datei zu finden wird Performance-Kompromisse haben - der Aufwand summiert sich einfach).

Wenn sich alle Dateien auf demselben Dateisystem befinden, bieten feste Links auch Optionen (da sie ebenfalls atomar sind), die dieselbe Datei an verschiedenen Stellen ablegen (im Prinzip für die Indexierung).

Zum Beispiel könnten Sie ein "Heute" -Verzeichnis, ein "Gestern" -Verzeichnis, ein "Java" -Verzeichnis und das eigentliche Nachrichtenverzeichnis haben.

So könnte ein Beitrag im "today" -Verzeichnis, dem "java" -Verzeichnis (weil der Beitrag mit "java" getaggt ist, sagen wir) und an seinem endgültigen Platz (say/articles/2008/12) verlinkt werden /01/my_java_post.txt). Um Mitternacht führen Sie dann zwei Prozesse aus. Der erste nimmt alle Dateien im "today" -Verzeichnis, überprüft ihr Erstellungsdatum, um sicherzustellen, dass sie nicht "heute" sind (da der Prozess einige Sekunden dauern kann und eine neue Datei eingeschleust wird), und benennt diese Dateien in " gestern". Als nächstes machen Sie dasselbe für das "gestern" -Verzeichnis, nur hier löschen Sie es einfach, wenn sie veraltet sind.

Inzwischen befindet sich die Datei noch im Verzeichnis "java" und ".../12/01". Da Sie ein Unix-Dateisystem und feste Links verwenden, existiert die "Datei" nur einmal, das sind alles nur Zeiger auf die Datei. Keiner von ihnen ist "die" Datei, sie sind alle gleich.

Sie können sehen, dass, während jede einzelne Datei bewegen atomaren ist, ist die Masse nicht. Während zum Beispiel das "today" -Skript läuft, kann das "gestern" -Verzeichnis durchaus Dateien sowohl von "gestern" als auch "vom Vortag" enthalten, weil das "gestern" -Skript noch nicht ausgeführt wurde.

In einer transaktionalen DB würden Sie das alles auf einmal tun.

Aber einfach, es ist eine bewährte Methode. Insbesondere Unix arbeitet sehr gut mit diesem Idiom und die modernen Dateisysteme können es auch sehr gut unterstützen.

Answer 2

(Antwort kopiert und geändert von here)

würde ich raten davon ab, eine Flat-Datei für alles außer schreibgeschützten Zugriff zu verwenden, da Sie dann Probleme mit Nebenläufigkeit haben müssen, z. B. sicherzustellen, dass nur ein Prozess gleichzeitig in die Datei schreibt. Stattdessen empfehle ich SQLite, eine voll funktionsfähige SQL-Datenbank, die in einer Datei gespeichert ist. SQLite hat bereits eine integrierte Nebenläufigkeit, so dass Sie sich nicht um Dinge wie das Sperren von Dateien kümmern müssen, und es ist wirklich schnell für Lesevorgänge.

Wenn Sie jedoch viele Datenbankänderungen vornehmen, ist es am besten, alle gleichzeitig in einem transaction zu tun. Dadurch werden die Änderungen nur einmal in die Datei geschrieben, und nicht bei jeder Ausgabe einer Änderungsabfrage. Dies erhöht die Geschwindigkeit der Durchführung mehrerer Änderungen dramatisch.

Wenn eine Änderungsanfrage ausgegeben wird, ist die gesamte Datenbank gesperrt, bis die Abfrage beendet wird. Dies bedeutet, dass extrem große Transaktionen die Leistung anderer Prozesse beeinträchtigen können, da sie auf den Abschluss der Transaktion warten müssen, bevor sie auf die Datenbank zugreifen können. In der Praxis habe ich festgestellt, dass dies nicht so auffällig ist, aber es ist immer eine gute Übung, die Anzahl der Datenbankänderungsanfragen zu minimieren, die Sie ausgeben, und es ist sicherlich schneller, als eine einfache Datei zu verwenden.

Answer 3

Schreckliche Idee. Das Anhängen würde jedes Mal das Ende der Datei suchen, wenn Sie etwas hinzufügen möchten. Das Aktualisieren würde jedes Mal das Neuschreiben der gesamten Datei erfordern. Das Lesen umfasst einen Tabellenscan (oder das Beibehalten eines separaten Index, der die gleichen Probleme beim Schreiben/Aktualisieren hätte). Verwenden Sie einfach eine Datenbank, es sei denn, Sie implementieren alles, was ein RDBMS bereits zur Verfügung stellt, um Ihre Lösung sogar moderat skalierbar zu machen.

Answer 4

Dies wurde mit asp.net mit Dasblog getan. Es verwendet dateibasierten Speicher.

Einige Details sind auf diesem älteren Link aufgeführt. http://www.hanselman.com/blog/UpcomingDasBlog19.aspx

Sie können auch weitere Informationen erhalten, auf http://dasblog.info/Features.aspx

Ich habe einige gemischte Meinungen über die Leistung gehört. Ich würde vorschlagen, dass Sie ein wenig mehr recherchieren, um zu sehen, ob diese Art von System für Sie gut funktionieren würde. Das ist das Nächste, von dem ich bisher gehört habe.

Answer 5

Das Schreiben einer eigenen Engine in systemeigenem Code kann eine allgemeine Datenbank übertreffen.

Die Qualität des Motors und der Feature-Level wird sich jedoch nie annähern. All die Dinge, die Ihnen Datenbanken als Kernfunktionen geben - Indizierung, Transaktionen, referentielle Integrität - müssten Sie alle selbst implementieren.

Es gibt nichts falsches, als das Rad neu zu erfinden (schließlich war Linux genau das), aber denken Sie an Ihre Erwartungen und an Ihre Zeit.

Answer 6

Sie scheinen recht gut für High-Write, niedrig-lesen, keine Update-Datenbanken, wo neue Daten angehängt werden.

Webserver und ihre Cousins ​​verlassen sich stark auf sie für Protokolldateien.

DBMS Software sie auch für Protokolle verwenden.

Wenn Ihr Design innerhalb dieser Grenzen liegt, sind Sie in guter Gesellschaft, so scheint es. Vielleicht möchten Sie Metadaten und Zeiger in einer Datenbank behalten und eine Art schneller asynchroner Queue-Writer einrichten, um die Kommentare zu puffern, aber das Dateisystem ist auf dieser Ebene der Pufferung und Schreibsperrung bereits ziemlich gut.

Answer 7

Flatfile-Datenbanken sind möglich, berücksichtigen Sie jedoch Folgendes.

Datenbanken müssen alle ACID-Elemente (Atomarität, Konsistenz, Isolation, Dauerhaftigkeit) erreichen, und wenn Sie sicherstellen wollen, dass alles in einer flachen Datei erfolgt (insbesondere mit gleichzeitigem Zugriff), haben Sie im Grunde ein ausgewachsenes DBMS.

Warum also nicht ein vollständiges DBMS verwenden?

Sie sparen sich die Zeit und das Geld beim Schreiben (und beim wiederholten Schreiben, ich garantiere) wenn Sie nur eine der freien Optionen verwenden (SQLite, MySQL, PostgresSQL, usw.) .

Answer 8

Sie können Fiat-Datei-Datenbanken verwenden, wenn es klein genug ist, hat keinen zufälligen Zugriff verloren. Eine große Datei mit viel zufälligem Zugriff wird sehr langsam sein. Und keine komplexen Abfragen. Keine Joins, keine Summe, Gruppierung nach usw. Sie können auch nicht erwarten, hierarchische Daten aus der Flat-Datei zu holen. XML-Format ist viel besser für komplexe Strukturen.

Answer 9

Ich beantworte dies nicht zu beantworten, warum flache Datei-Datenbanken gut oder schlecht sind, andere haben eine gute Arbeit geleistet.

Allerdings haben einige auf SQLite hingewiesen, was seine Aufgabe gut macht. Da Sie Java verwenden, wäre die beste Option, HSQLDB zu verwenden, die genau das Gleiche wie SQLite tut, aber in Java implementiert ist und in Ihre Anwendung eingebettet wird.

Answer 10

Die meiste Zeit ist eine flache Datei-Datenbank genug jetzt. Aber du wirst deinem jüngeren Selbst danken, wenn du dein Projekt mit einer Datenbank beginnst. Dies könnte SQLite sein, wenn Sie kein ganzes Datenbanksystem wie PostgreSQL einrichten möchten.

Answer 11

Überprüfen Sie dies http://jsondb.io eine Opensource-Java-basierte Datenbank hat das meiste, was Sie suchen. Speichert Daten als flache .json-Dateien, Multithreading-Unterstützung, Verschlüsselungsunterstützung, ORM-Unterstützung, Atomicity Support, XPATH-basierte erweiterte Abfrageunterstützung.

Haftungsausschluss: Ich habe diese Datenbank erstellt.