Ist eine NoSQL-Datenbank so einfach wie SQLite?


7 Answers

Ich denke, Berkeley DB ist die klassische Wahl hier.

Berkeley DB (BDB) ist eine Softwarebibliothek, die eine hochleistungsfähige eingebettete Datenbank für Schlüssel / Wert-Daten bereitstellt. Berkeley DB ist in C mit API-Bindungen für C ++, C #, PHP, Java, Perl, Python, Ruby, Tcl, Smalltalk und vielen anderen Programmiersprachen geschrieben. BDB speichert beliebige Schlüssel / Daten-Paare als Byte-Arrays und unterstützt mehrere Datenelemente für einen einzelnen Schlüssel. Berkeley DB ist keine relationale Datenbank.

Question

Ist eine NoSQL-Datenbank so einfach wie SQLite? Ich suche nach einer leichten Datenbank, um eine kleine Menge von Daten für eine einfache Desktop-Anwendung zu erhalten. Ich kann immer noch SQLite verwenden, bevorzuge aber einen eher OO-Ansatz, da meine App nicht viele Daten verarbeitet.




Klingt wie ein Job für y_serial ;-)

Hier ist die Beschreibung: "Serialisierung + Persistenz: Komprimieren und kommentieren Sie in einigen Codezeilen Python-Objekte in SQLite und rufen Sie sie später chronologisch nach Schlüsselwörtern ohne SQL ab. Das nützlichste" Standard "-Modul für eine Datenbank, um schemalos zu speichern Daten."

Weitere Informationen finden Sie unter http://yserial.sourceforge.net/ .




Ich habe vor ein paar Tagen UnQLite gefunden, aber es scheint keine Indizes zu unterstützen und hat keine Adapter.




Eine andere Lösung ist LevelDB . Die Homepage sagt:

LevelDB ist eine schnelle Schlüsselwert-Speicherbibliothek, die bei Google geschrieben wurde und eine geordnete Zuordnung von Zeichenfolgenschlüsseln zu Zeichenfolgenwerten bietet.

Eigenschaften

  • Schlüssel und Werte sind beliebige Byte-Arrays.
  • Daten werden nach Schlüsseln sortiert gespeichert.
  • Anrufer können eine benutzerdefinierte Vergleichsfunktion bereitstellen, um die Sortierreihenfolge zu überschreiben.
  • Die grundlegenden Operationen sind Put (Schlüssel, Wert), Get (Schlüssel), Delete (Schlüssel).
  • Mehrere Änderungen können in einer atomaren Charge vorgenommen werden.
  • Benutzer können einen vorübergehenden Snapshot erstellen, um eine konsistente Datenansicht zu erhalten.
  • Die Vorwärts- und Rückwärtsiteration wird über die Daten unterstützt.
  • Daten werden automatisch mithilfe der Snappy-Komprimierungsbibliothek komprimiert.
  • Externe Aktivitäten (Dateisystemoperationen usw.) werden über eine virtuelle Schnittstelle weitergeleitet, sodass Benutzer die Betriebssysteminteraktionen anpassen können.
  • Ausführliche Dokumentation zur Verwendung der Bibliothek ist im Quellcode enthalten.

Einschränkungen

  • Dies ist keine SQL-Datenbank. Es verfügt nicht über ein relationales Datenmodell, SQL-Abfragen werden nicht unterstützt und Indizes werden nicht unterstützt.
  • Nur ein einzelner Prozess (möglicherweise mehrere Threads) kann auf eine bestimmte Datenbank gleichzeitig zugreifen.
  • Es ist keine Client-Server-Unterstützung in die Bibliothek integriert. Eine Anwendung, die diese Unterstützung benötigt, muss ihren eigenen Server in die Bibliothek einbinden.



Tokyo Cabinet und sein Nachfolger Kyoto Cabinet sind am besten.

Kyoto Cabinet ist eine Bibliothek von Routinen zum Verwalten einer Datenbank. Die Datenbank ist eine einfache Datendatei, die Datensätze enthält, jedes ist ein Paar aus einem Schlüssel und einem Wert. Jeder Schlüssel und Wert ist ein serielles Byte mit variabler Länge. Sowohl Binärdaten als auch Zeichenkette können als Schlüssel und Wert verwendet werden. Jeder Schlüssel muss innerhalb einer Datenbank eindeutig sein. Es gibt weder ein Konzept von Datentabellen noch Datentypen. Datensätze sind in Hash-Tabelle oder B + Struktur organisiert.




Unter bestimmten Umständen (wenn Sie keine Requisiten als Indizes benötigen) können Sie das Dateisystem selbst als DB verwenden: Dateiname / Pfad als Schlüssel und Dateiinhalt als Wert. JSON ist speichereffizient, daher können Sie einen Parser verwenden, um Daten serialisieren / unserialisieren.

Stellen Sie sicher, dass Sie nicht zu viele Dateien (Tausende) unter demselben Ordner speichern (teilen Sie Dateien in verschiedene Ordner mit einem Hash).

Das eigentliche Problem dieser Lösung (zusätzlich zu dem Fehlen einiger Features) ist, dass Dateieinträge in 4KB Blöcken gespeichert werden, so dass eine Datei von 10 Bytes 4KB verwendet, eine Datei von 4097 Bytes 8KB usw. (at mindestens bei den meisten Dateisystemen), so dass große Mengen kleiner Datensätze nicht sehr disketteneffizient sind.

Die Vorteile: ist schnell, leicht, weil viel weniger RAM verwendet, und kein Interprozess Connector Engpass hinzugefügt wird, ist bewiesen und transparent-OS optimiert durch den RAM-R / W-Cache. Sie können Sperren verwenden und sogar per Remote-Mount verteilen.

Schließlich würde ich diese Lösung vermeiden, wenn Ihre Produktionsplattform eine Windows-Maschine ist, aber auch möglich ist.




Technisch gesehen, wenn Sie keine SQL-ähnliche Funktionalität benötigen, um bestimmte Elemente auszuwählen, können Sie die einfache Serialisierung verwenden und jedes Objekt als separate Datei speichern.

Zum Beispiel mit C # lang + psuedo zum Verkürzen

   List<Customer> customers = ...//some data here

   JsonSerlializer.Save(customers, "c:\...\customers.json"); //you can use .db extension if you will
   //load back
   List<Customer> customers = JsonSerlializer.Load("c:\...\customers.json");

Ein Objekt ein Dokument auf dem Dateisystem, oder Sie können ein großes Nutzlastobjekt erstellen, um alle Ihre Daten zu speichern und in einer Datei zu speichern. Berücksichtigen Sie nur die Arbeitslast der Anwendung, wenn Sie viele Daten verwenden.

Jetzt, antwortend "Gibt es irgendeine NoSql-Datenbank so einfach wie SQLite" Ich weiß nicht, also bin ich hier, die gleiche Frage stellend :) aber wirklich für einfache Konfigurationsdatei oder einige wenige Gegenstände oder Listen, lokale json-Datei sollte gerade genug sein .

EDIT: Das könnte vielversprechend sein UnQLite

"UnQLite ist eine In-Process-Software-Bibliothek, die eine eigenständige, serverlose, transaktionsfreie NoSQL-Datenbank-Engine ohne Konfiguration implementiert. UnQLite ist eine Dokumentenspeicher-Datenbank ähnlich wie MongoDB, Redis, CouchDB usw. sowie ein Standard-Schlüssel / Wert-Speicher ähnlich wie BerkeleyDB, LevelDB usw. "




Friendly ist eine Art NOSQL-Datenbank, die Ruby + SQLite als Backend verwendet. Es ist eine Art Hack, aber es ist auch irgendwie nett. Ich habe eine Beispiel-Sinatra-App geschrieben, die es here demonstriert.




Related



Tags

sqlite   nosql