PureBoard

Hi, fange demnächst mit einem Projekt an, bei dem ich einige M Datensätze speichern und schnell wiederfinden und lesen muss. Die Daten sind nicht so strukturiert, dass eine relationale SQLdb ihre Vorteile ausspielen könnte. Deshalb hätte ich da an eine key-value (noSQL) Datenbank gedacht. Es gibt ja hier auch einige freie auf dem Markt, die sehr performant sein sollen. Eine direkte Anbindung einer solchen Datenbank in PB habe ich jetzt nicht entdeckt.
Grundsätzlich sehe ich folgende Möglichkeiten:
- PostgreSQL mit HStore
Vorteil: Dafür gibt es eingebaute Funktionen (zumindest auf den ersten Blick)
Nachteil: Ist möglicherweise nur so ein Marketing Gag von den Entwicklern und man könnte das aus Performancesicht auch in einer 2 spaltigen
normalen Tabelle speichern .... Und ich kann auch noch nicht einschätzen, wie proprietär das Interface im Vergleich zu anderen Datenbanken ist.
Stichwort CQL etc.
- Eine Datenbank die sich mit REST ansprechen lässt. Habe mich schon mit dem PB TCP Stack beschäftigt. Einer der großen Probleme ist, dass ein
Rückantwort immer gepollt werden muss. Das gibt entweder CPU Last oder unnötige Wartezeiten. Lasse mich hier aber gerne eines besseren
belehren.
- Eine Datenbank, die eine C/C++ API hat und diese dann in PB einbinden. Letzteres ich noch nie gemacht, C kann ich, mit C++ 'lite'
(Arduino) habe ich mich schon angefreundet, aber zu C++ habe ich seit 30 Jahren keinen Bezug. Evtl. geht das ja alles jetzt mit 6.0ff ganz einfach ...

Ich möchte mich bei der Datenbank auf ein paar wenige elementare Operationen beschränken: Datensatz schreiben. Datensatz mit key suchen und lesen. Datensatz suchen und löschen. Datensatz suchen und überschreiben. Tabelle anlegen und löschen. Je weniger elementare Operationen, umso leichter ist es später mal auch eine Datenbank austauschen zu können.

Was meint Ihr dazu? Hoffe auf viele Antworten, da ich denke, dass dieses Thema auch für andere, die das Forum besuchen, interessant sein könnte und die letzte Diskussion, die ich hier gefunden habe, schon 6 Jahre alt ist..

Eine REST basierte NoSQL-Datenbank kannst du direkt mit der HTTP-Bibliothek nutzen. Eine REST-Schnittstelle sendet dir in der Regel die Antwort direkt retoure. Da ist kein Polling nötig. HTTP ist zustandslos. Das wissen auch die REST-Datenbanken und verhalten sich entsprechend. EIne solche Datenbank wäre die Apache CouchDB. Allerdings solltest du bedenken, das HTTP immer eine gewisse Latenz mit sich bringt. Daher solltest du die Dokumentation von CouchDB über Möglichkeiten durchforsten, mit der du mehrere Datensätzen in einem Request unterbringen kannst. Ansonsten kann das bei Millionen Datensätzen lange dauern.

Als Key-Value Datenbanken sind auch In-Memory Datenbanken wie Redis oder MemCache gefragt. Da weiß ich aber auch nicht, ob es da Suchfunktionen gibt. Mit solchen Datenbanken habe ich noch nichts gemacht, das es erfordert, da solche DB's sich eher als Cache eignet. Für Redis gibt es aber auch C-Bibliotheken. Und schnell sind sie, wenn die Daten im RAM liegen, auf jeden Fall.

Dein Hauptproblem wird in der Regel immer die Anbindung an PureBasic sein. Man hat nur die integrierten Treiber (Postgres, MariaDB/MySQL, SQLite), der Systeminterne Datenquellenmanger über ODBC oder HTTP für REST. Damit ist der Aufwand vergleichsweise gering. Alles andere benötigt Vorarbeit.

Um sich was Datenbanken angeht inspirieren zu lassen, empfehle ich eigentlich immer: https://db-engines.com/de/

SQLite nicht gut? Ist es eine entfernte DB auf einem anderen Rechner?
So viel ich weiß bietet fast jede DB auch einen ODBC connector oder wie das heisst an, und soviel ich weiß gibt es ODBC sogar für Linux. Das wäre etwas umweghaft aber gehbar. SQLite wird i.d.R. für kleinere Projekte benutzt, da ist die gesammte DB in einer Datei untergebracht, und kann auch im Speicher gespiegelt werden bzw. gibt es einige Features. Auch lässt sich SQLite "einfach" ein wenig erweitern; du kannst hier dein eigenenes "Dateisystem" zusammenbrauen und einbinden, oder eigene SQL-Hilfsfunktionen (z.B. eine md5(..) Procedure für die sql-Abfragen zugänglich machen). Für SQLite brauchst Du auch keine lokale Installation, Treiber usw, nicht mal die DLL - im Gegensatz zu allen anderen.

Wer Folgendes lesen möchte, ist wohl ein wenig zu neugierig

Ich bin gerade dabei mir meine eigene "NoSQL Micro-DB" zu schreiben. Ein abgetippter bzw. portierter (C) AVL Tree war das mal, der etwas groß gewachsen ist Habe erst später gemerkt, dass es auch in den Foren PB Beispiele gegeben hat, aber ich wollte ein wenig learning-by-doing machen.
Für BTrees bin ich ein wenig zu doof, da ich keinen Source zum Abtippen bzw. Portieren gefunden habe Eigentlich wollte ich einen Region-Tree erst bauen, bin aber davon irgendwie abgekommen.Das ist leider schon "etwas" komplizierter als eine Doubly Linked List, z.B. Weil ich wollte einen Quadtree komplett neu denken. Weil ich mir eine eigene GUI schreiben wollte. Weil das ist schon ca. ein Jahr her, und ich habe vergessen wo das alles hinführen sollte, achja eine coole "einfache" GUI naja So ist es eben mit dem "einfach" und "irgendwann"...

Erst gestern habe ich es geschafft! (Wie der Zufall so spielt). Ich will auf folgendes abzielen: eventuell SQL und PB Strutktur definitionen austauschbar nutzen. Strukturen direkt speichern/laden/alloziieren ein bisschen wie in den ExtractStructure Befehlen bei der XML und JSON Lib. Ich habe da an anderer Stelle etwas halbwegs Brauchbares zusammengebraut.

Derzeit wäre die "avl db" aber noch etwas langsam bei "offline" Zugriffen, kann selbstverständlich noch kein SQL, und sowieso gibt es nur einen Demo code für einen Demo Datentyp bzw. Struktur. Daher werde ich noch alles ein weiteres Mal aufkrempeln müssen (bin bei Implementation 5 und 6).

Ich benutze Key-Pair (Implementation 5) der Key ist immer ein Quad, entspricht also einer "RowID" wenn man so will. Schnell und "inline" sortiert. Nummer 6 ist ein User-übergebener Strukturpointer, mit benutzer-definierter Sortierfunktion. Das wäre also genau etwas, was Du bräuchtest - allerdings noch leider nicht ausgereift bzw. in einer nutzbaren Form vorhanden.

Das ganze ist noch sehr Callback-lastig und in den "Kinderschuhen", weil ich mich erst auf die RAM-Seite des AVL-Trees ausschließlich beschränkt habe.

Aber in den nächsten implementationen werde ich das neue DB Dateiformat definieren, vermutlich ein wenig von SQLite inspiriert alles in eine Datei packen, unverschlüsselt um Zeit und komplexität zu sparen) und ein Seiten Cache einbinden müssen, damit es "offline" wie "online" schneller und vor allem dynamisch funzt. Das an sich selbst ist aber schon eine komplexe Sache, bei der ich dann viel mit Thread-sicherer Programmierung experimentieren müsste. Und Write Ahead Logging oder wie das heisst muss es auch geben - "nur" als Option . Ich dachte aber dennoch sollte es eine Single-User DB sein, jedenfalls je Rechner. Ich fantasiere schon größenwahnsinnigerweise das ganze clusterisierbar zu machen mit up/downstream servern aber ich riskiere hier einen geistige Burnout dabei, wenn ich zuviel denke und zu wenig probiere.


Es lässt sich die "Demo DB" offline auslesen. "Online" bedeutet so wie ich es hier meine: der komplette AVL Tree ist im RAM der Applikation wieder hergestellt, mit Struktur-pointern und allozierten Strings etc. Das habe ich relativ schnell, aber auch RAM lastig, hinbekommen.

Zeit Faktoren sind
2 Mio Zufalls-Strings etc. generieren = 1
Das Ganze laden = 1,5 - 2
Das Ganze speichern = ?? Ich vermute zwischen 1 und 1,5 aber es könnte derzeit etwas länger sein (mehr Dateioperationen als optimal)



Auf dem Raspi ist der Zeitfaktor ca. 10x wie auf meinem Desktop PC, von der Geschwindigkeit her, Pi mal Daumen die gleichen Zeit-Verhältnisse, ich vermute es ist relativ Schnuppe ob es eine SSD oder mechanische ist weil ich lade die "DB" in einem Durchgang rein und raus, daher wird auch viel RAM benutzt um erst die Datei dort vollständig rein zu laden. Ich muss schauen in welche Richtung sich das entwickeln soll, mutable unmutable DB und so, oder mein eigenes Hexengebräu mit Nebenwirkungen. Derzeit wäre das Democode-Format unmutable, so wie ich es verstehe. Also man kann nur schwer wieder etwas entfernen, aber (der Begriff mag verwirren) jederzeit etwas hinzufügen. Einen Delete Flag oder sowas habe ich auch nicht eingebaut. Ist nur ein Baum je Datei derzeit (aber theoretisch mehrere), so als fixes Game-Save Format, oder benutzerdefiniertes Datei-Archiv "leicht" nutzbar (3 Callbacks je Baum für Laden+Speichern, dann noch 1 oder 2 um "online" neue Elemente anzulegen bzw. bei einem delete wieder den Speicher zulären (aka Allocate & ClearStructure). Das ganze lässt sich aber abstrahieren und dann wrappen, was einer der nächstes Schritte wäre für Implementationen 7 und 8, wenn ich es anpacken sollte.

ca. 216 MB (AvlTree5) und 150MB (AvlTree6) bei 2 mio ID+strings ("Node #11234 blabla" artige strings), weil die generierten Strings bei etwas unterschiedlicher sind. Ladezeiten liegen auf dem PC bei ca. 2 Sekunden und bein Raspi also ca. 20s. Sorry falls das unpräzise ist, das sind nur grobe Richtwerte aber ich denke es ist immer nützlich sich etwas Feeling anzueignen.

Overhead sind 50-60 bytes je Node und ungefähr genauso viel für den Datei-Header. Alle größen-Angaben und Datei-Offsets sind in 64bit Quads, sodaß auch sehr große Dateien möglich wären, aber eben auch der Overhead erzeugt wird; Im RAM ist der Overhead auf 64bit quasi identisch, auf 32bit kleiner (es werden 2 zusätzliche Pointer im Vergleich zu klassischen AVL Trees zusätzlich benötigt, um aus dem AVL Tree eine implizierte Linked-List zu machen; d.h. man kann den AVL Tree auch als Priority list oder LL benutzen, welche eine andere "Sortierung" hat als die ID's, aber wied gesagt der Baum ist schon dick gewachsen und aufgepeppelt). Wenn der Baum im RAM "entpackt" ist, geht es kaum schneller - insbesondere bei den ID-*Structure Vergleichen. Bei den nächsten Implementationen werde ich aber noch mehr rausziehen können, glaube ich ^^ Es geht mit implementierter Linked List ca. 10-20% langsamer, wenn nach ID/benutzerdefiniertem Callback sortiert wird; aber wenn zum "Listen" Anfang oder Ende hinzugefügt bzw. inserted wird, ist der Zeit-Overhead quasi bei 0, es wird aber mehr Zeit benötigt um seites PB/OS die 2 zusätzlichen Pointer zu allozieren (mehr Speicher) und diese größere Struktur zu nullen (bei FreeMemory bzw. AllocateMemor). Das spielt also auch da rein, ist aber vernachlässigbar wenn man eine LL haben will. Und das ist cool, weil erst mit dem BTree angeblich LL's implizit sind, geht aber auch mit einem modifizierte AVL ganz einfach, wie ich beim experimentieren rausgefunden habe

Wenn ich was Präsentierbares habe werde ich gerne hier damit prahlen Ich denke dass wir hier ein überschneidendes Interesse haben, aber nunja die perfekte DB kenne ich auch nicht (SQLite fand ich überraschend langsam, aber ich denke es liegt auch an den standart Optionen, meiner Unwissenheit und hohen Ansprüchen).

Wenn Du bestimmte Ideen oder Features wünschst, die auch in meine Richtung gehen, immer her damit - ich könnte auch auf Inspiration und Erfahrungen von anderen gerne zurrückgreifen.

SQLite nicht gut? Ist es eine entfernte DB auf einem anderen Rechner?
So viel ich weiß bietet fast jede DB auch einen ODBC connector oder wie das heisst an, und soviel ich weiß gibt es ODBC sogar für Linux. Das wäre etwas umweghaft aber gehbar. SQLite wird i.d.R. für kleinere Projekte benutzt, da ist die gesammte DB in einer Datei untergebracht, und kann auch im Speicher gespiegelt werden bzw. gibt es einige Features. Auch lässt sich SQLite "einfach" ein wenig erweitern; du kannst hier dein eigenenes "Dateisystem" zusammenbrauen und einbinden, oder eigene SQL-Hilfsfunktionen (z.B. eine md5(..) Procedure für die sql-Abfragen zugänglich machen). Für SQLite brauchst Du auch keine lokale Installation, Treiber usw, nicht mal die DLL - im Gegensatz zu allen anderen.

Wer Folgendes lesen möchte, ist wohl ein wenig zu neugierig

Ich bin gerade dabei mir meine eigene "NoSQL Micro-DB" zu schreiben. Ein abgetippter bzw. portierter (C) AVL Tree war das mal, der etwas groß gewachsen ist Habe erst später gemerkt, dass es auch in den Foren PB Beispiele gegeben hat, aber ich wollte ein wenig learning-by-doing machen.
Für BTrees bin ich ein wenig zu doof, da ich keinen Source zum Abtippen bzw. Portieren gefunden habe Eigentlich wollte ich einen Region-Tree erst bauen, bin aber davon irgendwie abgekommen.Das ist leider schon "etwas" komplizierter als eine Doubly Linked List, z.B. Weil ich wollte einen Quadtree komplett neu denken. Weil ich mir eine eigene GUI schreiben wollte. Weil das ist schon ca. ein Jahr her, und ich habe vergessen wo das alles hinführen sollte, achja eine coole "einfache" GUI naja So ist es eben mit dem "einfach" und "irgendwann"...

Erst gestern habe ich es geschafft! (Wie der Zufall so spielt). Ich will auf folgendes abzielen: eventuell SQL und PB Strutktur definitionen austauschbar nutzen. Strukturen direkt speichern/laden/alloziieren ein bisschen wie in den ExtractStructure Befehlen bei der XML und JSON Lib. Ich habe da an anderer Stelle etwas halbwegs Brauchbares zusammengebraut.

Derzeit wäre die "avl db" aber noch etwas langsam bei "offline" Zugriffen, kann selbstverständlich noch kein SQL, und sowieso gibt es nur einen Demo code für einen Demo Datentyp bzw. Struktur. Daher werde ich noch alles ein weiteres Mal aufkrempeln müssen (bin bei Implementation 5 und 6).

Ich benutze Key-Pair (Implementation 5) der Key ist immer ein Quad, entspricht also einer "RowID" wenn man so will. Schnell und "inline" sortiert. Nummer 6 ist ein User-übergebener Strukturpointer, mit benutzer-definierter Sortierfunktion. Das wäre also genau etwas, was Du bräuchtest - allerdings noch leider nicht ausgereift bzw. in einer nutzbaren Form vorhanden.

Das ganze ist noch sehr Callback-lastig und in den "Kinderschuhen", weil ich mich erst auf die RAM-Seite des AVL-Trees ausschließlich beschränkt habe.

Aber in den nächsten implementationen werde ich das neue DB Dateiformat definieren, vermutlich ein wenig von SQLite inspiriert alles in eine Datei packen, unverschlüsselt um Zeit und komplexität zu sparen) und ein Seiten Cache einbinden müssen, damit es "offline" wie "online" schneller und vor allem dynamisch funzt. Das an sich selbst ist aber schon eine komplexe Sache, bei der ich dann viel mit Thread-sicherer Programmierung experimentieren müsste. Und Write Ahead Logging oder wie das heisst muss es auch geben - "nur" als Option . Ich dachte aber dennoch sollte es eine Single-User DB sein, jedenfalls je Rechner. Ich fantasiere schon größenwahnsinnigerweise das ganze clusterisierbar zu machen mit up/downstream servern aber ich riskiere hier einen geistige Burnout dabei, wenn ich zuviel denke und zu wenig probiere.


Es lässt sich die "Demo DB" offline auslesen. "Online" bedeutet so wie ich es hier meine: der komplette AVL Tree ist im RAM der Applikation wieder hergestellt, mit Struktur-pointern und allozierten Strings etc. Das habe ich relativ schnell, aber auch RAM lastig, hinbekommen.

Zeit Faktoren sind
2 Mio Zufalls-Strings etc. generieren = 1
Das Ganze laden = 1,5 - 2
Das Ganze speichern = ?? Ich vermute zwischen 1 und 1,5 aber es könnte derzeit etwas länger sein (mehr Dateioperationen als optimal)



Auf dem Raspi ist der Zeitfaktor ca. 10x wie auf meinem Desktop PC, von der Geschwindigkeit her, Pi mal Daumen die gleichen Zeit-Verhältnisse, ich vermute es ist relativ Schnuppe ob es eine SSD oder mechanische ist weil ich lade die "DB" in einem Durchgang rein und raus, daher wird auch viel RAM benutzt um erst die Datei dort vollständig rein zu laden. Ich muss schauen in welche Richtung sich das entwickeln soll, mutable unmutable DB und so, oder mein eigenes Hexengebräu mit Nebenwirkungen. Derzeit wäre das Democode-Format unmutable, so wie ich es verstehe. Also man kann nur schwer wieder etwas entfernen, aber (der Begriff mag verwirren) jederzeit etwas hinzufügen. Einen Delete Flag oder sowas habe ich auch nicht eingebaut. Ist nur ein Baum je Datei derzeit (aber theoretisch mehrere), so als fixes Game-Save Format, oder benutzerdefiniertes Datei-Archiv "leicht" nutzbar (3 Callbacks je Baum für Laden+Speichern, dann noch 1 oder 2 um "online" neue Elemente anzulegen bzw. bei einem delete wieder den Speicher zulären (aka Allocate & ClearStructure). Das ganze lässt sich aber abstrahieren und dann wrappen, was einer der nächstes Schritte wäre für Implementationen 7 und 8, wenn ich es anpacken sollte.

ca. 216 MB (AvlTree5) und 150MB (AvlTree6) bei 2 mio ID+strings ("Node #11234 blabla" artige strings), weil die generierten Strings bei etwas unterschiedlicher sind. Ladezeiten liegen auf dem PC bei ca. 2 Sekunden und bein Raspi also ca. 20s. Sorry falls das unpräzise ist, das sind nur grobe Richtwerte aber ich denke es ist immer nützlich sich etwas Feeling anzueignen.

Overhead sind 50-60 bytes je Node und ungefähr genauso viel für den Datei-Header. Alle größen-Angaben und Datei-Offsets sind in 64bit Quads, sodaß auch sehr große Dateien möglich wären, aber eben auch der Overhead erzeugt wird; Im RAM ist der Overhead auf 64bit quasi identisch, auf 32bit kleiner (es werden 2 zusätzliche Pointer im Vergleich zu klassischen AVL Trees zusätzlich benötigt, um aus dem AVL Tree eine implizierte Linked-List zu machen; d.h. man kann den AVL Tree auch als Priority list oder LL benutzen, welche eine andere "Sortierung" hat als die ID's, aber wied gesagt der Baum ist schon dick gewachsen und aufgepeppelt). Wenn der Baum im RAM "entpackt" ist, geht es kaum schneller - insbesondere bei den ID-*Structure Vergleichen. Bei den nächsten Implementationen werde ich aber noch mehr rausziehen können, glaube ich ^^ Es geht mit implementierter Linked List ca. 10-20% langsamer, wenn nach ID/benutzerdefiniertem Callback sortiert wird; aber wenn zum "Listen" Anfang oder Ende hinzugefügt bzw. inserted wird, ist der Zeit-Overhead quasi bei 0, es wird aber mehr Zeit benötigt um seites PB/OS die 2 zusätzlichen Pointer zu allozieren (mehr Speicher) und diese größere Struktur zu nullen (bei FreeMemory bzw. AllocateMemor). Das spielt also auch da rein, ist aber vernachlässigbar wenn man eine LL haben will. Und das ist cool, weil erst mit dem BTree angeblich LL's implizit sind, geht aber auch mit einem modifizierte AVL ganz einfach, wie ich beim experimentieren rausgefunden habe

Wenn ich was Präsentierbares habe werde ich gerne hier damit prahlen Ich denke dass wir hier ein überschneidendes Interesse haben, aber nunja die perfekte DB kenne ich auch nicht (SQLite fand ich überraschend langsam, aber ich denke es liegt auch an den standart Optionen, meiner Unwissenheit und hohen Ansprüchen).

Wenn Du bestimmte Ideen oder Features wünschst, die auch in meine Richtung gehen, immer her damit - ich könnte auch auf Inspiration und Erfahrungen von anderen gerne zurrückgreifen.

Danke für die Views und die Antworten.
Aus ca. 80 Views und 2 Antworten (ca. 2,5%) lese ich, dass schon Interesse am Thema besteht, aber wohl kaum jemand über die integrierten DBs hinausgewachsen ist.
db-engines.com (@Troax, Danke!) bietet einen guten überblick, was alles an Datenbanken zur Verfügung steht. Leider gibt es nur eine sehr eingeschränkte Filtermöglichkeit, so dass man doch recht viel manuell vergleichen muss. Immerhin besteht die Möglichkeit zum Vergleich und man kann dann rel. schnell viele Lösungen aussortieren. Hat man was interessantes gefunden, geht man auf die Herstellerseite und recherchiert dann weiter. Meist wird man dann von irgend einer Eigenschaft, den Interfaces, den Installations- und Wartungsaufwand, der benutzten Sprache oder auch vom Lizenzmodell wieder verscheucht. Es ist nicht einfach.
Hier die wesentlichen Kriterien:
- Freemium Modell/Community Modell
- Aktive Community (Und damit auch eine gewisse Anzahl an erfolgreichen Nutzungen)
- Lauffähig in default Konfiguration auf OS in default Konfiguration, Win und Linux
- Einfache und performante Anbindung an PB (*)
- Nutzbar mit geringer Anzahl von Befehlen (damit man die DB auch mal tauschen kann)
- Persistentes Datenmodell
- Nicht zu alt und nicht zu neu (@Benubi, sorry)

(*) Wenn ich das richtig sehe, läuft wohl alles außer SQLlite letztlich irgendwie über Netzwerk, was Latenz verursacht. Wieviel, das kann ich jetzt noch nicht abschätzen. Wenn ich dann mehrere key-value Abfragen benötige um eine (komplexe) SQL Abfrage zu ersetzen, dann kann eine 'ineffektiv' erscheinende klassische Speicherung der Daten in einer SQL Datenbank die bessere Alternative sein. Nach derzeitiger Datenlage (wenn niemand mehr was in dieser Richtung beisteuert) werde ich wohl einen Satz von Benchmarks machen müssen ...

Kann also sein, dass dieser Thread jetzt erst mal eine gewisse Zeit auf Eis liegt ... Wenn´s dann taut, bitte wieder vorbeischauen.

Das Thema Datenbanken ist generell immer ein sehr umfangreiches Thema, über das man vorzüglich streiten kann. In der Regel sind DBMS-Systeme, die extra installiert werden müssen darauf ausgelegt, für mehrere Clients erreichbar zu sein. Aus diesem Grund sind diese auch zwingend über das Netzwerk anzusprechen. Je kürzer der Weg (Latenz), um so weniger Leerlauf entsteht und um so schneller arbeitet das ganze. Verwendet man das DBMS auf dem System, auf dem auch der Client ausgeführt wird, macht die Latenz nicht so viel aus. Bei einer REST Schnittstelle kommt aber erschwerend hinzu, das HTTP nun einmal Daten auch in Form von Strings überträgt. Der Webserver benötigt also mehr Zeit, um die Anfrage zu zerlegen. Denn der Header einer Anfrage ist definitiv immer ein String. Dieser muss geparsed, interpretiert und die Daten damit aus dem Körper Kategirisiert werden. Mit einer HTTP bzw. REST Schnittstelle ist das ganze also zwingend nochmal deutlich langsamer als Socket-Basierte Datenbanken.

Aber am Ende steht einfach die Frage im Raum, wozu man die Datenbank brauch. Wenn die Daten nicht zentral für mehrere Clients zur Verfügung stehen müssen, dann macht ein DBMS-System wie Postgres, MariaDB/MySQL, MongoDB, CouchDB und Co. nur sehr wenig Sinn. Wenn man dann auch nur 2 Spalten brauch, was für eine Key-Value Datenbank sprechen würde, wird es schwieriger. Denn gerade die sind als Dateidatenbank alá SQLite doch recht selten.

Im Grunde spricht aber auch absolut garnichts dagegen, mit SQLite nur eine Tabelle mit 2 Spalten zu nutzen. Und wenn man diese im RAM verwaltet ist das eben auch sehr schnell. Aber dann bekommt man ein Problem mit der Persistenz, für das man sich auch eine Lösung einfallen lassen muss, wenn man Daten persistent halten will. Ich weiß nicht, in wie weit SQLite-Funktionen aus der Lib mit der Funktion_() Schreibweise direkt erreichbar sind. Siehe hier: https://www.sqlite.org/backup.html
Müssen die Daten aber nicht gespeichert werden, dann spielt das ganze erst Recht keine Rolle. Aber dann stellt sich mir eine andere Frage. Warum dann bei Key-Value überhaupt eine Datenbank? Dann kann man den Kram auch in einer String-Map speichern. Aber es steht ja auch die Durchsuchbarkeit im Raum. Will man dabei nur nach expliziten Schlüsseln suchen, dann würde ich klar eine String-Map nehmen. Dafür ist die Map da. Will man aber eine Volltextsuche auf den Wert durchführen, dann dürfte ein entsprechendes Statement an die SQLite DB schneller sein. Es sei denn man hat einen guten Algorithmus für die Suche in einer Map. Das bezweifel ich allerdings.

Wenn Performance eine Rolle spielt, kommen REST/HTTP basierte Interfaces nicht in Frage. Die sind einfach durch das HTTP-Protokoll generell langsam. Es sei denn man kann mit JSON einen Bulk-Insert durchführen. Dadurch gehen alle Datensätze über einen Request an die Datenbank. Hier kann ich NocoDB empfehlen (PS: Wer versucht, eine SQLite-Datenbank an eine REST-API zu hängen: NocoDB <- Fertig ). Hier kann neben SQLite auch noch andere SQL-Datenbanken mit verwendet werden. Allerdings geht das meiner Meinung nach für diesen Zweck schon zu weit.

Daher meine Empfehlung für folgende Szenarien:
1. Datenbank für mehrere Clients: PostgesSQL, MariaDB (Etabliert, Funktioniert nativ mit PB, Performance kann auch mit Datenbankeinstellungen erhöht werden Stichwort: InnoDB vs. MyISAM bei MySQL, Aufwendiger in der Konfiguration) oder Redis (C-Bibliotheken sind verfügbar - Wenn Key-Value eine Rolle spielt, API erschreckend groß für ein Key-Value Storage, Teilweise C-Bibliotheken selbst zu kompilieren)
2. Datenbank nur für einen Client: SQLite (Etabliert, Funktioniert nativ mit PB, lässt sich auch im RAM verwalten, Durchsuchbar, Memory-DB macht aber Replikation über Backups notwendig, wenn die Daten über Sessions hinweg erhalten bleiben müssen)
3. Wenn REST wirklich interessant ist: NocoDB (kann direkt als fertige portable Anwendung heruntergeladen werden, Unterstützt Bulk-Import/Export, kann alle wichtigen SQL-Datenbanken auf REST mappen, man benötigt allerdings ein wenig Know-How in Sachen JWT <- Müsste man erst einmal implementieren, Benötigt viel JSON-Fummelei <- was aber bei REST immer der Fall sein dürfte, allerdings komplett in Javascript mit Node geschrieben, trotzdem wirklich ekelhaft mächtig das Teil )

Und was das Thema NoSQL angeht. NoSQL steht im Kern ja nur für Datenbanken, die kein SQL benötigen (also für nicht-relationale Datenbanken). Programmieren muss man aber trotzdem, um Daten da rein und raus zu bekommen. Mit SQL-Datenbanken hat man die Vorteile, das sie für nahezu jeden Einsatzzweck hervorrang zu skalieren sind, gut dokumentiert sind, große Communities haben und sich damit dank ODBC auch nahezu alle mit PB verwenden lassen. Man kann relationale Datenbanken auch als nicht-relationale Datenbanken verwenden. Oder als dokumentbasierte Datenbank oder Key-Value-Store. Aber auch der Mischbetrieb ist möglich. Alles hängt nur vom Tabellendesign ab. Nutzt man ein klar definiertes Tabellen-Design, so kann man sich hinterher das SQL leichter wegabstrahieren und man schreibt sich seine eigene NoSQL damit.

Man kann sagen was man will. Aber SQL ist nicht umsonst im Web, in der Cloud und generell im Netzwerk gefühlt allgegenwertig. SQL gehört seit Dekaden zu den Top 20 Sprachen und genießt einen hohen Stellenwert. 2022 war auch Postgres zumindest laut Stackoverflow das wichtigste DBMS. Einarbeitung brauch man bei allen, wenn man von 0 anfängt. Aber mit PureBasic und seinen Datenbankfunktionen hat man eben das mächtigste Werkzeug von allen schon mit an Board (wobei ich immernoch für eine Funktion Namen InsertDatabaseRowAsStruct und GetDatabaseRowAsStruct oder so wäre - Boah würde das Arbeit sparen. Wo anders landen die bei mir sowieso nicht ). Auch wenn ich mal zeitweise schon scharf auch MongoDB und CouchDB gewesen bin. Der Benefit ist mir da eichfach zu gering. Und wenn sich die Anforderung an einer Anwednung ändert, dann stehe ich da und kriege es bei denen nicht mehr sauber unter. SQL-Datenbanken juckt das nicht. Die können nun einmal fast alles

Und wenn man viele Datensätze in Reihe in die DB schreiben will, gibt es immernoch Transaktionen. Die sind viel Wert, wenn man Millionen zig tausende Datensätze da rein hämmert

Wenn 2 sich streiten freuen sich die Zuschauer ... oder so ähnlich. Wenn es um Datenbanken Streit gibt, dann ist das wohl so ähnlich wie mit der 'besten Programmiersprache'.

Mir ist jedenfalls in den letzten gut 30 Jahren aufgefallen, dass Anwendungen mit Datenbanken gerne mal langsamer sind, als sich der Anwender das wünscht. Wohl alles SQL Varianten. Da hilft dann oft auch die neueste Hardware nichts. Wenn es dann ein Hersteller geschafft hat, dass alles nur noch quälend langsam ist, dauert es oft Jahre bis die Anwendung wieder soweit optimiert werden konnte, dass die Anwender wieder zufrieden sind. Begeisterung bleibt normalerweise aus.

Ich möchte damit nicht behaupten, dass SQL Datenbanken grundsätzlich schlecht sind. Aber irgendetwas verleitet bei SQL dazu, langsame Anwendungen zu erstellen. Man stelle sich vor, Google hätte voll auf SQL gesetzt: "Google, was ist das?"

Wenn es so einfach wäre, aus einer SQL eine noSQL (steht übrigens für "not only SQL", was aber wohl nicht für alle noSQLs zutrifft) zu machen, also eine SQL nur mit key-value Tabellen zu betreiben (PostgreSQL bietet dies als Sonderfunktion an), warum gibt es dann so viele noSQL Datenbanken. Ein Grund könnte sein, dass die jeweils zur Lösung eines bestimmten Problems (mit der Gesamtperformance von SQL Datenbanken) entwickelt wurden und dann hat man das halt veröffentlicht, um die Entwicklungskosten und mehr, schneller zurück zu bekommen. Wenn dann jeder gut zahlende Kunde sich ein paar Funktionen wünscht, bekommt man dann so ein Interface wie bei Redis? Allein die Auflistung mit Minimalbeschreibung der Befehle/Funktionen reicht für ein kleines Taschenbuch.

Ich bin (noch ) kein Experte aber ich denke das was das langsam macht sind einerseits verschachtelte interne Abstraktionsebenen, String Manipulationen und dynamische Datengrößen, Springen über weite Datei-Entfernungen, das Umwandeln und interpretieren der SQL Befehle in Bytecode. Dann werden die meisten DBMS's ihre Daten über Netzwerk versenden an sich selbst, ihre Clients und Servers, selbst wenn es nur an "localhost" ist. Es gibt da mehrere Stellen wo es blockieren kann, auf Puffer warten und Übertragungs-Latenzen, konkurrente Zugriffe.

Denn um eine 100% zuverlässiges Write zu erzeugen muss die Transaktion zuerst komplet in eine andere Datei geschrieben werden, bis ein "commit" in dieser erscheint um zu zeigen, dass sie vollständig und nun durchgeführt werden soll. Dann erst wird diese Transaktions Datei in die DB rüberkopiert, und gleichzeitig das RAM von der DB mit den Updates versorgt. Die Datei enthält auch die DB.Daten wie sie waren, bevor die Veränderung vorgenommen wurde. (Alter Sektor+Neuer Sektor Paare)

Bei einem Neustart kann so, sofern der Computer abgestürzt ist, die Integrität wiederhergestellt werden. Wenn die Transaktion vor dem "Commit" abgebrochen wurde, ist sie unvollständig und es werden alle alten Seiten wiederhergestellt, bzw. gar nichts getan, ist aber ein Commit da, wird Seite für Seite (oder DB-Sektor) mit dem in Transkationsdatei verglichen und bei Unterschieden wird die neue Seite aus der TD eingespielt.

Wenn Du etwas sicher in die DB schreiben willst, "musst" du es also zwei mal schreiben und einmal lesen, wenn Du das nächste mal das richtige Ergebnis lesen möchtest. Es sei denn du schaltest die Journaling/Write Ahead Logging Meachanismen ab (bei SQLite z.B. gibts sowas), dann müsste alles direkt in die DB-Datei geschrieben werden also könntest Du schon mindestens die Zugriffsgeschwindigkeit verdoppeln können, was den Dateizugriff angeht. Aber dann sind deine Daten ja nicht mehr "sicher in der Bank"

Dadurch gibt es immer eine Verzögerung zwischen dem was auf der Festplatte ist, man kann das auch nicht-blockend machen, aber es gibt dennoch eine kleine Latenz. Die darauf folgende Transaktion muss dann auch warten bis die erste beendet wurde, bei Sqlite immer - bei größeren DBMS wird da kompliziert geschaut ob es Überscheidungen und Konflikte zwischen den Transaktionen gibt, und ggf. ein Rewind oder bei Fehlern Rollback durchzuführen. Rewind würde die die Transaktion abeglockte/nicht integre Transaktion wiederholen, dabei können schlaue DBMS ihre Transaktionen gut gliedern sodaß diese nicht von A bis Z durchgeführt werden müssen, sondern erst ab der Stelle wo's hakt.

Man kann bei SQLite den WAL Modus bzw. Journaling Modus abschalten, aber dann hat man keine gesicherte Integrität mehr. Wenn der Computer absürtzt kann die DB dann komplett unbrauchbar sein, wenn ein Schreibvorgang standfand. Dann läuft die DB etwas schneller aber auch nicht perfekt. SQLite muss ja auf Datei- und OS-Ebene den Zugriff auf die DB regeln, wenn die meisten DB's ihre Dateien exklusiv nutzen und nicht vor sich selbst abschirmen müssen, können den Zugriff über Netzwerk im RAM organisieren, währen SQLite dort mehr mit Dateien und global Mutexes und sowas arbeiten muss, File Locks usw.

Wenn man die DB im RAM komplett gespiegelt hat, wie mit SQLite möglich sein soll, hat man im RAM schon die neuste Version während noch auf der DIsk diese geschrieben wird. Man könnte also ab dann direkt Lese-Abfragen ungeblockt durchführen, während die DB die Transaktion schreibt. Aber ich weiss nicht wie viel gepuffert wird wenn mehrere Transaktionen in einer Warteschleife sind. Ich denke die Nachfolger werden warten müssen. Dafür ist SQLite aber auch perfekt für eigenständige DB Apps geeignet, es wird quasi immer nur ein "Single User" vorrausgesetzt und das spart Overhead mit Zugangsberichtigungen und Kryptographie.

steht übrigens für "not only SQL"

Das spielt keine Rolle. Der Begriff hat seine Mehrdeutigkeiten, die in Einzelfällen so ziemlich alle zutreffen. Zur Geschichte des Begriffs:

Der Begriff NoSQL, noch im Sinne von no SQL, wurde erstmals für eine 1998 erschienene einfache Open-Source-Datenbank verwendet, die keine SQL-Zugriffsmöglichkeit bereitstellte.

- Wikipedia

Aber darum geht es hier nicht.

Genauso wenig lässt sich ein gemeinsamer Nenner finden, wenn es um das Thema Performance geht. Es ist am Ende immer wieder ein abwiegen zwischen Software ist schnell, die Entwicklung ist schnell, das Deployment ist schnell, die Datenbank ist schnell etc. Eine schnelle Entwicklung (Frameworks, Frameworks und ... achja Frameworks ... und bis zum geht nicht mehr tief verschachtelte Abhängigkeiten ... Man muss ja das Rad nicht neu erfinden, gelle? ) und ein schnelles Deployment (z.B. kein kompilieren nötig) geht immer zu Lasten der Performance und/oder Effizienz. In die andere Richtung kehrt sich das um. Je mehr Performance und Effizienz, um so länger dauert in der Regel die Entwicklung und es ist auch in der Regel eine Kompilierung nötig und man verwirkt die Plattformunabhängigkeit.

Genauso ist es bei Datenbanken. In PB sind von Haus aus nur SQL-Datenbanken integriert (ODBC in Sonderfällen ein wenig ausgenommen). Das liegt natürlich an der sehr sehr sehr großen Schnittmenge an Nutzern. Relationale Datenbanken setzen aber nun einmal nicht auf extreme Performane. Mit den Boardmitteln von PB ist eine SQLite im Speicher denke ich das schnellste, was man haben kann. Alternativ kann man schauen, ob man Redis per ODBC dranhängen kann. Allerdings dürfte die Verwaltung fummelig werden.

Früher habe ich mir auch bzgl. der Performance und Effizienz Gedanken gemacht. Deswegen hatte ich mich damals ja auch für PB entschieden. Aber am Ende .... Es interessiert einfach kaum eine Sau. Viel wichtiger sind Abstraktion, Test-Frameworks, so wenig selbst entwickeln wie geht/andere die Vorarbeit machen lassen. Einfach weird, das man sich heute dafür bezahlen lassen kann, in dem man sich Code-Schnipsel von StackOverflow aneinander hängt, bis was funktionierendes bei raus kommt.

Hallo und guten Tag!

... vielleicht will man es ja nicht glauben, aber auch eine HTMl-Datei (Seiten... kurz lang, ganz lang) kann als Datenbank herangezogen werden und hat ganz besondere Vorteile, zum Beispiel im Bereich von Dokumentationen für das Gesundheitswesen, Jugendhilfe, Psychotherapie, usw. usw. Sie bekommen meines Wissens nach immer mehr Bedeutung, weil die Anpassungsfähigkeiten viel viel größer sind als bei Datenbanken der herkömmlichen Art. Zentrale und dezentrale Datensicherungen haben dann ganz andere Möglichkeiten, von der Vergleichbarkeit der Daten über viele Anwendungen (Gemeinden, Organisatoren) ganz zu schweigen. Hinzu kommt die Einfachheit der Datenhaltung (primär dezentral mit allen Möglichkeiten zur zentralen Sicherung und Auswertung). Ein kleiner Hinweis dazu: Ein Programm zum Lesen aller denkbaren HTML-Dateien benötigt nicht mehr als 4000 Zeichen,
Ich wünsche ein schönes Wochenende, brigitte.