ODBC vs. JDBC-Leistung

Lesezeit: 6 Minuten

Benutzeravatar von user3213918
Benutzer3213918

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

Benutzeravatar von Dennis Jaheruddin
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.

Benutzeravatar von Davos
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.

Diagramm, das die Laufzeiten von Java- und C-Apps zeigt und die festen JIT-Startkosten von Java veranschaulicht

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.

1432500cookie-checkODBC vs. JDBC-Leistung

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy