Hallo Dev!
Ich bin Alex, ein Technikbegeisterter. Ich freue mich, Ihnen Jinbase zu zeigen, meine eingebettete Transaktionsdatenbank mit mehreren Modellen.
Vor fast einem Jahr habe ich Paradict vorgestellt, meine Version der Multiformat-Streaming-Serialisierung. Aufgrund seiner Lesbarkeit erscheint das Paradict-Textformat de facto als interessantes Datenformat für Konfigurationsdateien. Die Verwendung von Paradict zum Verwalten von Konfigurationsdateien würde jedoch dazu führen, dass die Programmieroberfläche überladen wird und es für Benutzer verwirrend wird, die immer noch die Wahl zwischen alternativen Bibliotheken (TOML, INI-Datei usw.) für Konfigurationsdateien haben. Deshalb habe ich Paradict als Abhängigkeit für KvF (Schlüsselwert-Dateiformat) verwendet, ein neues Projekt von mir, das sich auf Konfigurationsdateien mit Abschnitten konzentriert.
Mit seinem kompakten Binärformat dachte ich, Paradict wäre eine effiziente Abhängigkeit für ein neues Projekt, das auf I/O-Funktionen (wie Öffnen, Lesen, Schreiben, Suchen, Tell und Schließen) angewiesen wäre, um ein minimalistisches und dennoch zuverlässiges zu implementieren Persistenzlösung. Aber das war, bevor ich gelernt habe, dass „Dateien hart sind“. SQLite schien mir mit seinen Transaktionen, dem BLOB-Datentyp und den inkrementellen I/Os für BLOBs der richtige Riese zu sein, auf dem ich für mein neues Projekt stehen konnte.
Jinbase begann klein als Schlüsselwertspeicher und endete als eingebettete Datenbank mit mehreren Modellen, die die Grenzen dessen, was wir normalerweise mit SQLite machen, verschiebt. Der erste Übergang zum zweiten Datenmodell (dem Depot) erfolgte, als mir klar wurde, dass der Schlüsselwertspeicher nicht gut für Fälle geeignet war, in denen für jeden neuen Datensatz automatisch eine eindeutige Kennung (UID) generiert werden soll, was dem Benutzer das erspart Belastung durch die Bereitstellung einer Kennung, die versehentlich einer Kollision unterliegen und somit einen vorhandenen Datensatz überschreiben könnte. Danach habe ich eine Suchfunktion implementiert, die UID-Bereiche für den Depotspeicher, Zeitspannen (Datensätze werden automatisch mit einem Zeitstempel versehen) sowohl für den Depot- als auch für den Schlüsselwertspeicher sowie GLOB-Muster und Zahlenbereiche für Zeichenfolgen- und Ganzzahlschlüssel im Schlüsselwertspeicher akzeptiert .
Die Warteschlangen- und Stapeldatenmodelle haben sich als Lösungen für Anwendungsfälle herausgestellt, bei denen Datensätze in einer bestimmten Reihenfolge verbraucht werden müssen. Ein typischer Datensatz würde in einer einzigen Transaktionseinheit aus der Datenbank abgerufen und gelöscht werden.
Da SQLite als Speicher-Engine verwendet wird, unterstützt Jinbase de facto das relationale Modell. Der Einfachheit halber wird allen Tabellen, die sich auf Jinbase-Interna beziehen, jinbase_ vorangestellt, was Jinbase zu einem nützlichen Tool zum Öffnen älterer SQLite-Dateien macht, um neue Datenmodelle hinzuzufügen, die sicher mit dem relationalen Ad-hoc-Modell koexistieren.
Alle vier Hauptdatenmodelle (Schlüsselwert, Depot, Warteschlange, Stapel) unterstützen Paradict-kompatible Datentypen wie Wörterbücher, Zeichenfolgen, Binärdaten, Ganzzahlen, Boolesche Werte, Datums- und Uhrzeitangaben usw. Unter der Haube, wenn der Benutzer initiiert einen Schreibvorgang, Jinbase serialisiert (mit Ausnahme von Binärdaten), fragmentiert und speichert die Daten iterativ. Auf einen Datensatz kann nicht nur in großen Mengen zugegriffen werden, sondern auch mit zwei Ebenen der Teilzugriffsgranularität: der Byte-Ebene und der Feldebene.
Während die inkrementelle E/A von SQLite für BLOBs auf eine einzelne BLOB-Spalte in einer Zeile abzielt, erweitert Jinbase dies so, dass für jeden Datensatz inkrementelle Lesevorgänge alle Blöcke abdecken, als wären sie ein einzelnes einheitliches BLOB. Nur für Wörterbuchdatensätze erstellt und verwaltet Jinbase automatisch einen einfachen Index, der aus Zeigern auf Stammfelder besteht, der es dann ermöglicht, aus einem beliebigen Datensatz den Inhalt eines Felds zu extrahieren, das vor der Rückgabe automatisch deserialisiert wird.
Die offensichtlichsten Anwendungsfälle für Jinbase sind das Speichern von Benutzereinstellungen, das Beibehalten von Sitzungsdaten vor dem Beenden, die auftragsbasierte Verarbeitung von Datenströmen, das Offenlegen von Daten für andere Prozesse, das Aktualisieren älterer SQLite-Dateien mit neuen Datenmodellen und maßgeschneiderte Datenpersistenzlösungen.
Jinbase ist in Python geschrieben, ist auf PyPI verfügbar und Sie können mit den Beispielen in der README-Datei experimentieren.
Lassen Sie mich wissen, was Sie von diesem Projekt halten.
Projektlink: https://github.com/pyrustic/jinbase
Das obige ist der detaillierte Inhalt vonJinbase – eingebettete Transaktionsdatenbank mit mehreren Modellen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!