Schnelle Datenbank ohne Server und ohne BDE

[Jackie1983]

Hallo,

unser Programm hat als log eine formatierte Textdatei verwendet. Jetzt möchten wir das ganze auf eine DB umstellen da das suchen demnächst über eine GUI erfolgen soll. Die Daten müssen also nicht mehr lesbar sein.

Pro Sekunde müssen ca. 2-4 Datensätze gespeichert werden. Es darf kein Server verwendet werden und keine zusätzliche Software.

Mein Test mit xml ergab das das ganze viel zulangsam ist. Fürs laden und speichern über 5 Minuten bei 3MB.

Kennt jemand eventuell noch ein anderes Format?

gruß

[DeddyH]

Auf Anhieb fallen mir da SQLite, FB Embedded und Absolute Database ein.

[p80286]

XML ist ja eher ein Austauschformat (zwischen zwei Datenbanken) Wie wäre es ein "File of myRecord" zu verwenden, wenn Du schon keine "zusätzliche" Software benutzen darfst. Fällt embedded Firebird bzw. Interbase auch unter zusätzlich?

Gruß
K-H

[Bernhard Geyer]

Zitat:

Zitat von DeddyH (Beitrag 1144385)

Auf Anhieb fallen mir da SQLite ...

Wenn schnell wichtig wäre dann würde ich SQLite nicht empfehlen. Jedenfalls ist diese DB bei meinen Tests mit Zeos vor 2-3 Jahren geschwindigkeitstechnisch stark abgefallen.

[DeddyH]

Ich persönlich würde ja auch Firebird bevorzugen, aber bevor man mir Voreingenommenheit vorwerfen kann, nenne ich halt auch Alternativen ;) Mit SQLite habe ich persönlich überhaupt keine Erfahrungen, ABS habe ich nur vor Jahren einmal ausprobiert und bin da schnell auf Probleme gestoßen. Allerdings weiß ich nicht, wie das mittlerweile aussieht.

[CCRDude]

"XML" ist ein Dateiformat, keine Implementierung, und kann daher an sich gar nicht zu langsam sein. Allerdings kann ich mir schon vorstellen, daß die meisten Implementierungen langsam sind. Aber natürlich ist XML tatsächlich nicht gerade für realtime geeignet, selbst mit schnelleren Implementierungen geht es sicher immer besser, und wenn dann noch die Suchfunktion dazukommt...

Die typisierte Datei ist für ein einfaches Format sicherlich super. Sobald aber Felder in unterschiedlicher Größe vorkommen oder die Datenmengen so groß werden, daß ein Index bei der Suche von Vorteil ist, würde ich auch zu einer Datenbank raten.

SQLite würde mir da auch als erstes einfallen. Und das Argument Geschwindigkeit ist da extrem relativ. Zum einen lernt man mit Datenbanken nie aus, und mindestens 90% der Geschwindigkeitsprobleme, mit denen ich bisher zu kämpfen hatte, lagen an ungünstigen Tabellen, Indizes und Queries und der Platte. Geschwindigkeit bei Dir ist in erster Linie bei INSERTs relevant, bei anderen kann das etwas ganz anderes sein. Das einzige unpraktische an SQLite: wenn Du während des Loggens suchen willst, und die Suche komplex wird (etwa nach Teilstrings, das lässt sich nur schlecht per Index optimieren), läuft das nicht parallel ab, da wäre ein Cache für's Logging notwendig (paralleler Thread mit Pool an zu schreibenden Log-Einträgen, mMn sowieso zu empfehlen, damit das Logging nicht aufhält).

[mkinzler]

Voteil von FireBird embedded wäre zudem die zusätzlichen Features des DBMS und die Skalierbarkeit ( ohne Programmänderungen läuft das Programm auch mit der Serverversion)

[generic]

Um die Liste der Kollegen hier zu erweitern:
Es gibt auch noch MSSQL Compact Edition.

>Es darf kein Server verwendet werden und keine zusätzliche Software.
Das ist wohl eine Anforderung die *alle* übersehen haben.
Für die die meisten genannten Produkte wird du zumindest die Engine (Treiber-Dlls etc.) nutzen müssen.

Mit Delphi Bordmitteln würde mir nur die Client-Datasets einfallen bzw. via ADO Client-Datasets erstellen.

[DeddyH]

Ich denke nicht, dass wir das übersehen haben. Allerdings ist der Begriff "zusätzliche Software" nur unzureichend definiert. Sind schon DLLs gemeint, oder geht es um Installation zusätzlicher Programme/Dienste, wie sie für einen DB-Server notwendig wären?

[mkinzler]

Bei SQLite und Firebird embedded muss keine weitere Software installiert sein, es handelt sich ja nur um Dlls, die man auch ins Programmverzeichnis ablegen kann.
Zudem gibt es Lösungen, welche die Dll in die Exe einlagern.

[jobo]

Ist DB da nicht etwas hochgegriffen?

Vorausgesetzt das Programm arbeitet nicht multithreaded, gibt es nur einen Prozess, der read und write Operationen durchführt. Das ist doch relativ überschaubar.
Oder geht es mehr um "bequeme" Suche per SQL?

Zu SQlite hab ich noch dunkel in Erinnerung, dass man es auch nach Bedarf relativ stark anpassen / neu kompilieren kann, bspw. Journaling aus, usw. Transaktionen bspw braucht man in diesem Fall hier ja wohl nicht.

[neo4a]

Zitat:

Zitat von mkinzler (Beitrag 1144407)

Bei SQLite und Firebird embedded muss keine weitere Software installiert sein, es handelt sich ja nur um Dlls, die man auch ins Programmverzeichnis ablegen kann.
Zudem gibt es Lösungen, welche die Dll in die Exe einlagern.

SQLite kann man in der Tat mit einkompilieren, aber bei FB embedded bin ich mir da nicht so sicher, da zumindest bis R2.1 oder so noch mehr als eine Dll, sondern sogar noch feste Verzeichnisstrukturen nötig waren. Gibt es da etwa Fortschritte?

[Trigger2003]

Noch ein Vorschlag:

NexusDB Embedded.
Braucht nicht einmal .dlls, kann in die .exe mit einkompiliert werden, ist kostenlos und kann wie Firebird bei Bedarf auf Client/Server umgestellt werden (dann allerdings kostenpflichtig).

http://www.nexusdb.com/support/index.php?q=FreeEmbedded

Gruß
Markus

[Bernhard Geyer]

Zitat:

Zitat von generic (Beitrag 1144405)

Um die Liste der Kollegen hier zu erweitern:
Es gibt auch noch MSSQL Compact Edition.

>Es darf kein Server verwendet werden und keine zusätzliche Software.
Das ist wohl eine Anforderung die *alle* übersehen haben.

Du wohl am meisten :-) MSSQL Compact Edition läuft nur mit installierten .NET Framework. Ist zwar bei vermutlich 95-98% der PC Weltweit der Fall, aber da man nicht weiß ob evtl. die 2-5% das Hauptziel sind ...

Zitat:

Zitat von generic (Beitrag 1144405)

Für die die meisten genannten Produkte wird du zumindest die Engine (Treiber-Dlls etc.) nutzen müssen.
Mit Delphi Bordmitteln würde mir nur die Client-Datasets einfallen bzw. via ADO Client-Datasets erstellen.

Viele Desktop-DB's für Delphi wie Absolute Database oder TurboDB liegen als 100% Pascal-Code vor. D.h. nix mit DLL's und Co.

[Jackie1983]

da gab es ja schon einige Antworten.

Zu den fragen.
- Unser Dienst greift alleine auf die DB zu.
- Das suchen erfolgt in einem anderem Programm, Datenaustausch per socktes.
- Es sollte keine Anwendung / Server / Dienst installiert werden. Dll etc ist egal.
- file of myRecord habe ich auch schon probiert, allerdings ist die suche nicht gerade so toll und aufwendig.
- wir wollen ein db system nehmen, damit wir einfacher suchen / filtern können.

Werde mir mal sqlite anschauen.

[MrSpock]

Firebird embedded halte ich auch für die beste Lösung. Wenn es aber nur wenige Daten sind, kannst du ja mal die Geschwindigkeit von MyBase testen, wenn du nicht XML als Speicherformat, sondern binary benutzt.

[stahli]

Ich würde wohl auch Firebird embedded nehmen.
Ist einfach anzusprechen und mitzugeben und ist lizenzrechtlich unproblematisch.

[Iwo Asnet]

Wozu überhaupt ne DB?
Hier ein paar Alternativen:

TJanSQL ist eine Komponente, die in Textdateien per SQL suchen kann (auch JOIN über mehrere Textdateien). Sehr charmant.

TMyLogClass in eine TObjectList mit Streaming. Wäre imho auch schnell genug.

TStringList wäre auch ein Kandidat (ziemlich generisch). Ich packe da die Loginformation im CSV-Format rein und kann mit dem hier erhältlichen TCSVReader dann sehr schnell auf die Informationen zugreifen.

[DeddyH]

Gegenfrage: wieso keine DB? Damit muss man das Rad nicht neu erfinden und kann auch später ggf. hinzukommenden Anforderungen vergleichsweise gelassen entgegensehen.

[jobo]

Ich mags ja auch gern mit DB. Aber Logging ist eine sehr spezifische Aufgabe, die im Zweifel vor allem dazu dient, Fehler in der Anwendung zu finden.
Dazu sollten minimale Voraussetzungen ausreichen, es muss robust und performant sein.

Mein Lieblingsbeispiel ist eine Log Tabelle eines DB Anwendung, die den Eintrag "Kein Speicherplatz" aufnehmen soll.

[Furtbichler]

Zitat:

Zitat von DeddyH (Beitrag 1144456)

Gegenfrage: wieso keine DB?

Wir entwickeln auch Anwendungen für XP Embedded, wo man mit minimalem Footprint auskommen sollte, nach dem Motto "Wo viel wie nötig, so wenig wie möglich"

[BUG]

Zitat:

Zitat von jobo (Beitrag 1144466)

Dazu sollten minimale Voraussetzungen ausreichen, es muss robust und performant sein.

Also wenn es um gute Auswertbarkeit geht mit einer relativ robusten Datenbank geht, würde ich sqlite zumindest in Betracht ziehen.
Und die Geschwindigkeit sollte für deine 2-4 Inserts pro Sekunde ausreichen. Das ist könnte man auch mal testen.

[p80286]

Zitat:

Zitat von Jackie1983 (Beitrag 1144444)

- Unser Dienst greift alleine auf die DB zu.
- Das suchen erfolgt in einem anderem Programm, Datenaustausch per socktes.

Da stimmt etwas nicht.
Entweder greift eine Anwendung exclusiv auf einen Datenbestand zu, dann gibt es (zur Laufzeit) keine Möglichkeit auf den Datenbestand von einem anderen Programm aus zuzugreifen, oder aber es gibt mehr als ein Programm die auf den Datenbestand zugreifen. Dann ist aber Essig mit Embedded.

Eine weitere Möglichkeit wäre es allerdings, wenn mehrere Programme abwechselnd zugreifen.
Dann könnte man auch gleich bei der Textdatei als Logdatei bleiben und für die Auswertung mit einer/einem Kopie/Datenbankimport arbeiten.

Gruß
K-H

[Sir Rufo]

Das mit

Zitat:

Zitat von Jackie1983 (Beitrag 1144444)

- Es sollte keine Anwendung / Server / Dienst installiert werden. Dll etc ist egal.

verstehe ich das richtig, dass keine Fremd-Anwendung/-Server/-Dienst installiert werden soll?

Ich würde dann einmal (schon wieder ;) ) mORMot in den Raum werfen.

SQLite-basiertes ORM und hat packt alles in eine Anwendung. Keine DLL.

Und der Clou, im Handumdrehen auch als Client-Server-Lösung fertig (den Server baut man sich selber)!

[sh17]

HAb jetzt hier nicht alles durchgelesen, aber wenn es nur ums schreiben von Datensätzen geht, wäre BigTable auch eine Alternative. Ist u.a. in mORMot enthalten und kann separat genutzt werden. Das sollte genug Geschwindigkeit sein.

Zitat:

Zitat von Sir Rufo (Beitrag 1144564)

Ich würde dann einmal (schon wieder ;) ) mORMot in den Raum werfen.

Warum machst Du eigentlich ständig Werbung dafür ? :)

[Jackie1983]

Zitat:

Zitat von p80286 (Beitrag 1144557)

Da stimmt etwas nicht.
Entweder greift eine Anwendung exclusiv auf einen Datenbestand zu, dann gibt es (zur Laufzeit) keine Möglichkeit auf den Datenbestand von einem anderen Programm aus zuzugreifen, oder aber es gibt mehr als ein Programm die auf den Datenbestand zugreifen. Dann ist aber Essig mit Embedded.

Ähm wieso nicht? Programm eins greift auf die DB. Programm zwei greift auf die Daten per sockets die im Programm 1 enthalten sind. Also greift nur ein Prog. auf die DB :).

Was ist festgestellt habe, wenn die DB größer wird (beim test gerade mal 50mb, was nichts ist) wird das öffnen etwas dauern. Genauso wird viel speicher zu verfügung gestellt je größer die DB wird...

[Furtbichler]

Wenn die Daten wirklich live ausgewerten werden sollen (und nicht auf Knopfdruck zwischendurch irgendwann), müsste man eine richtje DB in Betracht ziehen. Euer Service wird sich dann exklusiv auf die DB setzen (z.B. mit Firebird embedded, SQLite o.ä.).

Queries kommen als SQL-Befehl per Socket durch, werden ausgeführt und das Ergebnis zurückgeschicht.

Da ist zwar jetzt nicht so der Unterschied zu einem DB-Server (weil es ja eigentlich einer ist, den ihr da schreibt), aber WTF. Wenn die Vorgabe so ist.

Man könnte auch ein FB/SQL-CE...

Zitat:

Zitat von Wikipedia

...Ein Anwendungsgebiet sind z. B. Programme zur Analyse von Logdateien. Diese lesen eine Logdatei ein, zerlegen sie und speichern sie intern als Datensätze in einer Tabelle. Durch den Zugriff mittels SQL auf die Daten ist ein nahezu beliebiges Sortieren und Filtern möglich.

SQL CE wird von Microsoft kostenlos angeboten und verfügt über eine native 64-Bit Unterstützung.

[Mavarik]

Hallo!

hmm... Leute,Leute...

Warum wollt Ihr immer mit Kanonen auf Spatzen schiessen?

2-3 Inserts pro Sekunden... Lächerlich....

Datenrecords speichern mit Blockwrite... Und kleinen BTree Index selber aufbauen...
Bischen RAM, bischen QSort, ggf. bischen Thread - in einer Stunde zusammen "gehackt"...
Und schon kann man paralell noch das Apfelmänchen berechnen... :stupid:

Grüsse Mavarik

[Furtbichler]

Hi Mavarik,
Das ist keine produktive Vorgehensweise, denn man ist nicht in der Lage, innerhalb einer Stunde etwas zusammenzuhacken, das auch garantiert funktioniert. Wie hältst Du es mit der Freispeicherverwaltung (alte Datensätze werden kontinuierlich gelöscht), dem Schutz gegen Ausfall, Datenkonsistenz?

Etwas heute in einer Stunde zusammenzuhacken bedeutet, das man morgen eine Woche investiert, um den Müll zu entwanzen.

Du kannst das vielleicht (entweder bist Du ein begnadeter Programmierer oder hast genügend Zeit), andere nicht.

Wir sollten uns darauf konzentrieren, etwas von der Stange zu nehmen.

Einige Messgerätehersteller (unsere Zulieferer) loggen ihr ganzes Zeugs in einer Access-DB (Singleuser) oder einem SQL-Server (Express). Wieso die Leute keine Open Source DB nehmen, weiss ich nicht.

Wenns ein Service ist, der exklusiv auf die Logdateien zugreift, würde ich zu einer Embedded-Version tendieren, wobei ich einen Kanal für SQL-Befehle jeglicher Art reservieren würde, um ggfs. mit einem DBAdmin-Tool Änderungen an den Rohdaten durchführen zu können.

[mkinzler]

Ab Firebird 2.5 kann man ja auch bei der embedded Varinate parallel auf eine Datenbank zugreifen.

[Furtbichler]

Genau, das wars. irgendwas war doch bei der neuesten Firebird obergeil.

[p80286]

Zitat:

Zitat von Furtbichler (Beitrag 1144774)

Einige Messgerätehersteller (unsere Zulieferer) loggen ihr ganzes Zeugs in einer Access-DB (Singleuser) oder einem SQL-Server (Express). Wieso die Leute keine Open Source DB nehmen, weiss ich nicht.

Weil es von Microsoft kommt ist es auch in Ordnung und darf etwas kosten. Ausserdem steht ein Weltkonzern dahinter, der ein ausgereiftes performantes Produkt unterstützt.

(und die Welt ist eine Scheibe und der Klapperstorch bringt die Kinder)

Gruß
K-H

[Bernhard Geyer]

Zitat:

Zitat von Furtbichler (Beitrag 1144774)

Einige Messgerätehersteller (unsere Zulieferer) loggen ihr ganzes Zeugs in einer Access-DB (Singleuser) oder einem SQL-Server (Express). Wieso die Leute keine Open Source DB nehmen, weiss ich nicht.

Weil man z.B. bei Verwendung von MS-Entwicklungsumgebunden diese DB's seit Jahr(zehnten) sehr gut unterstützt wird.
Und der MS SQL-Server ist nunmal keine schlechtes DBMS und bist 10 GB als Express-Version auch kostenlos zu verwenden.

[Furtbichler]

Zitat:

Zitat von p80286 (Beitrag 1144838)

Weil es von Microsoft kommt ist es auch in Ordnung...

Kindskopf.
Es ist vielleicht eher so, das OS-Produkte nicht sonderlich bekannt sind und die Programmierer keine Zeit haben, sich mit Alternativen zu beschäftigen.

[Peter Pohmann]

Hi,

eine maximal integrierte Datenbank ist TurboDB. Ist in Delphi geschrieben und wird als dcus ausgeliefert, d.h. es gibt nicht mal ne DLL. Umstieg auf Server, wenns denn wäre, mit minimalem Aufwand.
Kostet aber.

-Peter

[Bummi]

Zitat:

Weil es von Microsoft kommt ist es auch in Ordnung und darf etwas kosten

um MDB's zu erstellen und zu verwenden braucht man kein Access somit ist es wie SQL Express ebenfalls kostenlos und würde von mir jederzeit bevorzugt.