Laden...

performante Alternative zu MS Access

Erstellt von mrdjoker vor 14 Jahren Letzter Beitrag vor 14 Jahren 2.683 Views
M
mrdjoker Themenstarter:in
125 Beiträge seit 2008
vor 14 Jahren
performante Alternative zu MS Access

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

H
114 Beiträge seit 2007
vor 14 Jahren

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

6.911 Beiträge seit 2009
vor 14 Jahren

Hallo,

Empfehlungen für SQL-Datenbank gesucht könnte von Interesse sein.

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!"

M
mrdjoker Themenstarter:in
125 Beiträge seit 2008
vor 14 Jahren

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: **:::

6.911 Beiträge seit 2009
vor 14 Jahren

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!"

M
mrdjoker Themenstarter:in
125 Beiträge seit 2008
vor 14 Jahren

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

3.971 Beiträge seit 2006
vor 14 Jahren

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...

M
mrdjoker Themenstarter:in
125 Beiträge seit 2008
vor 14 Jahren

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.

1.457 Beiträge seit 2004
vor 14 Jahren

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.

4.506 Beiträge seit 2004
vor 14 Jahren

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!”

199 Beiträge seit 2006
vor 14 Jahren

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.

F
10.010 Beiträge seit 2004
vor 14 Jahren

Schonmal 100.000 Datensätze am stück in ne Feierbird DB geschrieben?

343 Beiträge seit 2007
vor 14 Jahren

Bevor dieses Thema komplett in eine Threaddiskussion abrutscht möchte ich auch noch was sagen zu embedded Datenbanken:

---- SQLite ----
Vorteile:

  • schnell mit kleinen Datenmengen
  • wirklich einfach (weit verbreitet = viel Doku)
  • schnell bei kleinen Datenmengen und einfachen Abfragen
  • sehr kleine Bibliothek (Dateigröße)
    Nachteile:
  • nicht geeignet für große Datenmengen
  • bestimmte Abfragen sind unverhältnismäßig langsam (z.B. synchronisierte Subselects)
  • nur eine Transaktion gleichzeitig

---- Firebird ----
Vorteile:

  • Funktionalität (Triggers, Stored Proz., ...)
  • Wechsel zu Datenbankserver einfach möglich
    Nachteile:
  • laut meinen Benchmarks in den meisten Fällen eine Spur langsamer als SQLite und SQL Compact

---- SQL Server Compact ----
Vorteile:

  • sehr schnell beim Auslesen
    Nachteile:
  • Dateigrößenbeschränkungen von 4GB
  • Datenbankdatei braucht meist mehr Speicherplatz als SQLite und Firebird mit identen Daten

Liebe Grüße
Preli

[- www.saftware.net -](http://www.saftware.net/)
906 Beiträge seit 2005
vor 14 Jahren

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!