Hallo Zusammen,
ich suche eine performante Embedded Datenbank (Datenbank, die ohne Server läuft).
Momentan muss ich mein Programm stark zügeln,
da MS Access nur ca 270 Insert Anweisungen pro Sekunde verarbeiten kann.
Ich habe folgende Datenbanken gefunden:
SQL Server Compact 3.5
MySQL Embedded Server 5.1
SQLite
Habt ihr noch weitere Vorschläge und welche ist in Sachen Performance zu empfehlen?
//Edit
Die Datenbank sollte genauso wie Access ohne Installation auskommen
und muss nicht zwingend mehrfach User fähig sein.
Gruss
mrdjoker
Hallo mrdjoker,
ich persönlich hab bisher ganz gute Erfahrungen mit Firebird gemacht...
Gibt es als Installations- und Embeddedvariante und man kann ohne viel Aufwand einfach zwischen beiden wechseln je nach Anforderung....einfach mal schauen, ob das deinen Anforderungen entspricht 😉
Grtz HiGHteK
Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.
"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"
Danke euch beiden.
Die Performance von Firebird werde ich morgen testen.
Ein kleine Test Datenbank mit Firebird anzulegen scheint etwas Zeitaufwändiger zu sein.
Und danke für den Link mit den Datenbank Empfehlungen.
Ich hatte zwar die Forensuche bemüht nur leider findet man bei Datenbanken sehr viele Beiträge.
Inwzischen habe ich MS Access mit SQL Server Compact 3.5 verglichen:
Die Testdatenbanken bestanden aus einer Tabelle, welche 2 Spalten hatte.
Eine Spalte mit einem Autowert/Sequenz und eine Spalte mit Text.
1 Thread mit 1000 inserts:
Access: 46 Sekunden
Compact: 27 Sekunden
64 Thread mit jeweils 100 Inserts:
Access:** 5 Minuten**
Compact: **:::
Hallo,
warum hast du beim Test 64 Threads verwendet? Auf einem Rechner mit n Kernen können nur n Threads wirklich parallel arbeiten. Bei mehr Threads (und das ist immer der Fall da auch andere Programme laufen) teilt der Scheduler die Prozessorzeit zu.
Weiters hast du geschrieben
und muss nicht zwingend mehrfach User fähig sein.
mit den Threads simulierst du aber gerade die mehrfachen Zugriffe. Wenn das so gewollt ist dann erwähne das auch.
Interessant wäre auch noch zu wissen mit welcher Technologie die Datenzugriffe erfolgten. Außerdem sollte immer mehrfach getestet werden, da beim 1. Aufruf/Ausführung die "Kaltstartproblematik" greifen könnte. D.h. verwirf den 1. Durchlauf und nimm die Daten vom 2. - besser noch von mehreren und diese statistisch auswerten.
Dann wäre das Testbild abgeschlossen. Dies ist als Hinweis für zukünftige Messungen gedacht 😉
Aber das Testergebnis zeigt trotzdem den qualitativen Unterscheid - und nur dieser soll entscheidend sein - indem eine "richtige" Datenbank performanter ist.
Danke für das Ergebnis.
mfG Gü
Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.
"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"
Hallo,
64 Threads habe ich verwendet, da mein Programm mehrere WMI Queries
über das Netzwerk schickt und diese dann in der DB logg
und das geht mit mehreren Threads nun mal schneller.
Interessant wäre auch noch zu wissen mit welcher Technologie die Datenzugriffe erfolgten.
Ich habe eine OleDbConnection verwendet.
da beim 1. Aufruf/Ausführung die "Kaltstartproblematik" greifen könnte
Die Kaltstartproblematik wurde im Test bereits berücksichtigt.
Gruß
mrdjoker
und das geht mit mehreren Threads nun mal schneller.
Das ist ein weitverbreiteter Irrtum. Threads haben nichts mit Geschwindigkeit zutun, sondern mit der parallelen Ausführung von einer oder vielen Aufgaben! Geschwindigkeit kommt erst zum Tragen, wenn die Hardware auch paralleles verarbeiten unterstützt (Mehrkern CPUs).
Das Problem bei Multithread auf SingleCore ist das Betriebssystem, dass nun mehrere Threads gerecht auf einem Core verteilen muss. Das Berechnen und die Verteilung/Verwaltung kostet allerdings auch wieder CPU-Zeit. Der größte Happen ist allerdingsc dabei der Context-Switch.
Somit läuft eine Singlethread-Anwendung auf einem SingleCore immer schneller als eine Mulithread-Anwendung(gleicher Hardware). Genauso eine Anwendung mit 2 Threads auf einem DoubleCore läuft schneller als mit 4 Threads!
Das nächste große Problem neben der Hardware, ist die entsprechende Synchronisierung der Threads innerhalb deiner Anwendung. Viele und auch falsche Locks bremsen die Verarbeitung extrem aus, da ein oder mehrere Threads ständig darauf warten, dass ein zweiter Thread die entsprechende Ressource wieder freigibt.
Stichwort Deadlocks, die deine Anwendung nicht gerade bedienerfreundlich macht, bzw. auch deswegen falsche oder unvollständige Ergbnisse liefert.
Wo hingegen Multithread Sinn macht - auch auf SingelCores - sind beispielsweise Server-Anwendungen (Webserver), wo es darum geht, dass gleichzeitig sich mehrere Clients verbinden bzw. gleichzeitig mehrere Requests and den Server gestellt werden.
Es gibt 3 Arten von Menschen, die die bis 3 zählen können und die, die es nicht können...
Ist es nicht besser, Threading zu benutzen, wenn man lange auf etwas warten muss?
Z.B. wenn man 500 Rechner anpingen möchte.
Mit einem Thread und einem Timeout von 200ms braucht man maximal 100 Sekunden.
Mit 64 Threads und dem gleichen Timeout braucht man rechnerisch 1,56 Sekunden.
Wenn man zu den 1,56 Sekunden noch etwas Schedulingzeit hinzufügt ist man
trotzdem um einiges schneller als hätte man einen Thread verwendet.
Korrigiert mich, wenn ich falsch liege.
Hallo mrdjoker,
Du solltest dir die Frage stellen wo es wirklich sinn macht. Ein Ping auf Rechnern ist nicht das gleiche wie auf eine lokale Datenbank zu schreiben. Und sogar im Netzwerk würde ich nicht mehr als 4 Threads parallel laufen lassen.
Wenn du 270 Inserts pro Sekunde hast, dann könntest du das ganze auch über eine Queue laufen lassen, aber ich würde hier kein Threading beim Zugriff auf eine Datenbank durchführen.
Hallo zusammen,
bevor nun das in einen Multithreading Krieg ausbricht folgende Aussagen:
Es ist richtig, dass ein Prozessor nur einen Thread bearbeiten kann.
Es ist also auch folgerichtig, dass gleichzeitig nur so viele Threads laufen können wie es Prozessoren gibt.
Es ist aber meiner Meinung nach überhaupt nicht gegeben, dass eine Anwendung langsamer läuft, wenn sie nicht genauso viele Threads wie CPU's verwendet (also mehr oder weniger). Das hängt ganz stark davon ab, was der Thread macht, in wie weit es atomare Operationen sind und ob Threads nicht sich selbst schlafen legen etc.
Wenn wir schon beim Besipiel Ping sind. Es ist durchaus denkbar (alles Theorie, also nicht nachgewiesen oder überprüft), dass ein Thread damit startet, den Ping abzusetzen, sich dann aber bis zu einer Antwort schlafen legt. Nehmen wir mal an, dass eine Ping-Antwort 30 ms dauert. Derweil kann ein Thread-Contextwechsel stattfinden und ein weiterer Ping abgesetz werden. Somit wäre die Theorie, dass Multi-Threading-Anwendungen, die mehr Threads als CPUs verwenden langsamer laufen widerlegt.
Also die Quintessenz ist hier: Multithreading ist ein sau-komplexes Thema, bei dem man nie pauschalisieren kann. Es hängt immer vom Anwendungsfall, von der Hardware und von der implementierten Logik ab.
@mrdjoker: Deshalb mag ich solche Berechnungen von Dauerangaben im Multithreading-Context überhaupt nicht. Einmal der Virenscanner zwischendrin (der in aller Regel eine höhere Priorität hat), und alle Berechnungen sind hinfällig.
So, nun war das Ausgangsthema aber Datenbanken, dachte ich zumindest.
Grüße
Norman-Timo
A: “Wie ist denn das Wetter bei euch?”
B: “Caps Lock.”
A: “Hä?”
B: “Na ja, Shift ohne Ende!”
Ich würd die Inserts auch nicht in den Threads machen lassen. Von meiner denkweise her, würde ich zwar auch mit Threads arbeiten, aber die Threads würden lediglich ihre Aufgabe erledigen (Pingen oder was auch immer) und die erarbeiteten Daten an den Threadholder zurückgeben. Nur der Threadholder schreibt dann die gesammelten Daten in die Datenbank. Das kann dann auch wieder in einem eigenen Thread passieren, damit die Anwendung nicht blockiert wird, aber das muss man abwägen, ob es notwendig ist (wann werden die Daten im, hauptprogramm wieder benötigt, wie lange dauert das schreiben der gesammelten Daten wirklich usw)
Nichts destotrotz wird dennoch Compact SQL schneller sein als Access. Nach meinen Erfahrungen kann man evtl mit Firebird noch ein bisschen mehr rausholen, aber in meinen bisherigen Anwendungen haben sich SQL Compact, Firebird und SQLite gegenseitig nicht viel genommen. SQL Compact hat allerdings in meinen Augen den Vorteil, dass man sehr leicht auf einen SQL Server switchen kann, sollte das mal notwendig werden.
Schonmal 100.000 Datensätze am stück in ne Feierbird DB geschrieben?
Bevor dieses Thema komplett in eine Threaddiskussion abrutscht möchte ich auch noch was sagen zu embedded Datenbanken:
---- SQLite ----
Vorteile:
---- Firebird ----
Vorteile:
---- SQL Server Compact ----
Vorteile:
Liebe Grüße
Preli
SQL Compact hat allerdings in meinen Augen den Vorteil, dass man sehr leicht auf einen SQL Server switchen kann, sollte das mal notwendig werden.
das geht bei Firebird auch und zwar ganz einfach. Einfach die DB auf den Server packen (backup-restore) und den ConnectionString ändern. Fertig!