Ich habe die Aufgabe, Java und C mit einer MySQL-Datenbank zu verwenden, die Ergebnisse zu vergleichen und Gründe für ein solches Ergebnis anzugeben.
No. of Records Execution time (ms)
Records Java C
100 586 76
500 628 216
2000 733 697
5000 963 1056
10000 1469 2178
Wie Sie sehen können, schnitt C(ODBC) besser ab, da weniger Datensätze aus der Datenbank abgerufen wurden. Aber als die Anzahl der Datensätze erhöht wurde, ging Java (JDBC) als Sieger hervor.
Der Grund, an den ich dachte, ist, dass die ODBC-Treiber möglicherweise viel schneller geladen werden als JDBC, aber die Zugriffsgeschwindigkeit von JDBC ist besser als ODBC, daher solche Ergebnisse. Allerdings kann ich nirgendwo eine solche Begründung finden.
Irgendwelche Vorschläge bitte?
Ich bin mir ziemlich sicher, dass es sich um ein Benchmarking-Problem handelt. Richtige Benchmarks zu schreiben ist eigentlich ziemlich schwierig. Können Sie den jeweiligen C- und Java-Code zeigen, den Sie verwenden? Ich bin mir ziemlich sicher, dass die Zahlen fast identisch sein sollten. Außerdem, welche Art von Daten verwenden Sie? 500 ms für 100 Datensätze erscheinen lächerlich hoch. Selbst die 76 ms in C erscheinen etwas hoch. Welche Zeiten erhalten Sie durch den MySQL-Client?
– Mikkel Løkke
17. Februar 2014 um 11:33 Uhr
Dennis Jaheruddin
Erklärungen präsentiert von Mathearbeiten Website, scheinen diese allgemein anwendbar zu sein.
Entscheidung zwischen ODBC- und JDBC-Treibern
Verwenden Sie natives ODBC für:
Schnellste Performance für Datenimporte und -exporte
Speicherintensive Datenimporte und -exporte
Verwenden Sie JDBC für:
Plattformunabhängigkeit, sodass Sie mit jedem Betriebssystem (einschließlich Mac und Linux®), Treiberversion oder Bitanzahl (32-Bit oder 64-Bit) arbeiten können
Verwenden von Database Toolbox-Funktionen, die nicht von der nativen ODBC-Schnittstelle unterstützt werden (z. B. runstoredprocedure)
Arbeiten mit komplexen oder langen Datentypen (z. B. LONG, BLOB, Text usw.)
Tipp:
Auf Windows-Systemen, die sowohl ODBC- als auch JDBC-Treiber unterstützen, bieten reine JDBC-Treiber und die native ODBC-Schnittstelle eine bessere Konnektivität und Leistung als die JDBC/ODBC-Bridge.
Folgende Punkte können helfen:
Multi Thread: – JDBC ist multithreaded – ODBC ist nicht multithreaded (zumindest nicht threadsicher)
Flexibilität: – ODBC ist eine Windows-spezifische Technologie – JDBC ist spezifisch für Java und wird daher von jedem Betriebssystem unterstützt, das Java unterstützt
Leistung : Sie können mit JDBC alles tun, was Sie mit ODBC tun können, auf jeder Plattform.
Sprache: – ODBC ist prozedural und sprachunabhängig – JDBC ist objektorientiert und sprachabhängig (spezifisch für Java).
Schwere Ladung: – JDBC ist schneller – ODBC ist langsamer
ODBC-Einschränkung: Es ist eine relationale API und kann nur mit Datentypen arbeiten, die in einem rechteckigen oder zweidimensionalen Format ausgedrückt werden können. (es funktioniert nicht mit Datentypen wie dem räumlichen Datentyp von Oracle)
APIHinweis: Die JDBC-API ist eine natürliche Java-Schnittstelle und baut auf ODBC auf, weshalb JDBC einige der Grundfunktionen von ODBC beibehält
Danke für die Antwort. Ich wollte nur fragen, ob es einen Unterschied in der Treiberauslastung usw. gibt. Denn das ist das einzige, was die oben angegebenen Ergebnisse rechtfertigen würde.
– Benutzer3213918
15. Februar 2014 um 16:59 Uhr
ODBC ist multithreaded. Es gibt Handler für jede Anweisung und es funktioniert in solchen Umgebungen ohne Probleme.
– Michael Niklas
17. Februar 2014 um 10:57 Uhr
Sprache: Ich verwende JDBC mit Jython und es kann wahrscheinlich von jeder Sprache verwendet werden, die mit JVM funktioniert.
– Michael Niklas
17. Februar 2014 um 11:04 Uhr
Ja, ich bin auch nicht von dem Geschwindigkeitskommentar überzeugt
– Simon Nichols
21. Juli 2017 um 10:44 Uhr
ODBC selbst unterstützt Multithread-Programmierung, aber nicht alle ODBC-Treiber.
– Arana
13. Mai um 20:48 Uhr
Sind Sie sicher, dass Sie Treiber und nicht ganze Umgebungen vergleichen?
Ich sehe, dass Sie für ODBC das C-Programm verwenden. Probieren Sie den ODBC-Treiber mit demselben Programm aus, das Sie zum Testen von JDBC verwenden, aber verwenden Sie jetzt die JDBC-ODBC-Bridge (ich verwende häufig Jython für solche Dinge). Bridge fügt natürlich etwas zusätzliche Zeit hinzu. Denken Sie auch daran, dass JVM JIT verwendet – je länger Ihre Anwendung arbeitet, desto besser ist die Leistung.
Leistung ist wichtig, aber viel wichtiger ist mir die Stabilität der Fahrer. Ich hatte einige Probleme mit verschiedenen ODBC-Treibern und bevorzuge jetzt JDBC-Treiber. Aber selbst ODBC-Treiber können viele Monate lang mit hochbelasteten Multithread-Servern arbeiten.
Ich finde immer diese Art von Diskussionen über ODBC gegen JDBC Leistung ein bisschen daneben, nicht anders als die Diskussionen herum JPA gegen Hibernate.
Eine C++-App, die einen in C geschriebenen ODBC-Treiber verwendet, ist für den kleinen Teil der stattfindenden Datenbankinteraktion wahrscheinlich blitzschnell. In ähnlicher Weise wird ein Java-Programm, das sich mit einer Datenbank verbindet, die einen Treiber eines Anbieters verwendet, der für seine spezielle Datenbank optimiert wurde, ebenfalls verdammt schnell sein.
Betrachtet man jedoch einen Anforderungs-Antwort-Zyklus mit einer Datenbank, ist die Netzwerklatenz, die mit der Anforderung verbunden ist, erheblich größer als der Overhead der API. In ähnlicher Weise ist die Zeit, die zum Durchsuchen einer Datenbank, zum Aktualisieren eines Datensatzes oder zum Halten einer Transaktion benötigt wird, um Größenordnungen bedeutender als die Effizienz, die man durch die Wahl von ODBC erzielen würde JDBC.
Verwenden Sie die Treiber empfohlen vom Anbieter angesichts der Sprache mit dem du dich entwickelst. Und überlassen Sie die Lösung der Leistungsprobleme den Datenbankadministratoren und SQL-Entwicklern. Hier werden Sie Ihre Datenbankengpässe nicht beheben.
Davos
Ziel der Aufgabe war es, Ihnen ein reales Anwendungsbeispiel vorzustellen, das die Leistungsmerkmale einer vorkompilierten Sprache vergleicht C in eine just-in-time (JIT) interpretierte^ Sprache Java.
^Der Unterschied zwischen interpretiertem und kompiliertem Code ist ein pedantisches Argument, wahrheitsgemäß wird der gesamte Code zur Laufzeit interpretiert; Sogar Assembler wird zur Laufzeit in Maschinensprache konvertiert, und Maschinensprache wird in Speicheradressen und CPU-Anweisungen aufgelöst.
Die wichtige Unterscheidung hier ist vorkompiliert vs. JIT. Der Unterschied besteht darin, wie nahe der Code dem Maschinencode zur Build-Zeit im Vergleich zur Laufzeit kommt. C nähert sich der Build-Zeit (größtenteils ignoriert es die jüngsten Fortschritte bei der heuristischen Kompilierung in Java).
Dieses Zuordnungsszenario fügt die realistische Komplikation des Datenbankdatenabrufs hinzu, was teilweise dazu dient, die Zahlen zu erhöhen, damit Sie etwas zum Arbeiten haben, aber hauptsächlich, um zu betonen, dass die Programmzeit aus festen (Start) und variablen (in diesem Fall I /O gebunden) Phasen. Es hätte auch ein CPU-gebundenes Beispiel sein können, das gleiche Muster wäre entstanden.
Es ist einfacher zu sehen, wenn Sie die Werte in einem Diagramm darstellen.
Betrachten Sie die Steigung der beiden Geraden. Ich denke, es ist eine Anomalie, dass in Ihren Zahlen das C-Programm über 4000+ Datensätze langsamer ist, aber das ist nicht wichtig und sollte nicht vom Kernpunkt des Beispiels ablenken.
Die C-App beginnt mit 100 Zeilen in 76 ms, ziemlich nahe am Ursprung bei 0
Die Java-App beginnt bei 586 ms, ziemlich nahe an 500.
Die Startzeit der C-App ist vernachlässigbar und kann daher effektiv ignoriert werden.
Die Startzeit der Java-App beträgt dagegen etwa 500 ms. Es ist der JIT-Compiler, der den Java-Bytecode auf der Java Virtual Machine (JVM) interpretiert; Es handelt sich um feste Startkosten, die Sie für jede Ausführung des Codes zahlen, unabhängig davon, wie viele Daten Sie aus der Datenbank abrufen.
Sie können davon ausgehen, dass 500 ms der wahre Ursprung Ihrer Datenzugriffszeiten sind, und sehen, dass das Programm von diesem 500-ms-Punkt aus linear wächst.
Es sind nicht die Treiber JDBC vs. ODBC an sich, aber der JDBC-Treiber ist auch eine Java-Bibliothek, die effektiv eine Erweiterung Ihres Programms ist und demselben JIT unterliegt, ebenso ist der ODBC-Treiber auch eine vorkompilierte C-Bibliothek, die effektiv ist eine Erweiterung Ihres Programms. Es wäre nicht fair, die Treiber speziell zu beschuldigen (vorausgesetzt, sie sind beide optimiert), es geht eher um den Anwendungskontext als Ganzes.
Ich bin mir ziemlich sicher, dass es sich um ein Benchmarking-Problem handelt. Richtige Benchmarks zu schreiben ist eigentlich ziemlich schwierig. Können Sie den jeweiligen C- und Java-Code zeigen, den Sie verwenden? Ich bin mir ziemlich sicher, dass die Zahlen fast identisch sein sollten. Außerdem, welche Art von Daten verwenden Sie? 500 ms für 100 Datensätze erscheinen lächerlich hoch. Selbst die 76 ms in C erscheinen etwas hoch. Welche Zeiten erhalten Sie durch den MySQL-Client?
– Mikkel Løkke
17. Februar 2014 um 11:33 Uhr