Java ODBC 与 JDBC 性能
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/21795119/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
ODBC vs JDBC performance
提问by user3213918
I have an assignment to use Java and C with MySQL database and compare the results and give reasons as to why such result.
我有一项任务是将 Java 和 C 与 MySQL 数据库一起使用，并比较结果并给出为什么会出现这种结果的原因。
No. of Records Execution time (ms) Records Java C 100 586 76 500 628 216 2000 733 697 5000 963 1056 10000 1469 2178
As you can see, with less number of records being fetched from the database, C(ODBC) performed better. But as the number of records were increased, Java(JDBC) came out as the winner.
如您所见，从数据库中提取的记录数量越少，C(ODBC) 的性能越好。但是随着记录数量的增加，Java（JDBC）成为了赢家。
The reason that I thought of is that may be the ODBC drivers load much faster than JDBC but the access speed of JDBC is better than ODBC, hence, such results. However, I am not able to find such reasoning anywhere.
我想到的原因可能是ODBC驱动加载速度比JDBC快很多，但是JDBC的访问速度比ODBC好，所以才会有这样的结果。但是，我无法在任何地方找到这样的推理。
Any suggestions please ?
请问有什么建议吗？
回答by soulemane moumie
The following points may help:
以下几点可能会有所帮助：
Multithread: - JDBC is multi-threaded - ODBC is not multi-threaded (at least not thread safe)
多线程： - JDBC 是多线程的 - ODBC 不是多线程的（至少不是线程安全的）
Flexibility: - ODBC is a windows-specific technology - JDBC is specific to Java, and is therefore supported on whatever OS supports Java
灵活性： - ODBC 是 Windows 特定的技术 - JDBC 特定于 Java，因此在任何支持 Java 的操作系统上都受支持
Power: you can do everything with JDBC that you can do with ODBC, on any platform.
强大：您可以在任何平台上使用 JDBC 完成您可以使用 ODBC 完成的所有工作。
Language: - ODBC is procedural and language independent - JDBC is object oriented and language dependent (specific to java).
语言： - ODBC 是过程和语言无关的 - JDBC 是面向对象和语言相关的（特定于 Java）。
Heavy load: - JDBC is faster - ODBC is slower
重负载： - JDBC 更快 - ODBC 更慢
ODBC limitation: it is a relational API and can only work with data types that can be expressed in rectangular or two-dimensional format. (it will not work with data types like Oracle's spatial data type)
ODBC 限制：它是一个关系 API，只能处理可以以矩形或二维格式表示的数据类型。（它不适用于 Oracle 的空间数据类型等数据类型）
API: JDBC API is a natural Java Interface and is built on ODBC, and therefore JDBC retains some of the basic feature of ODBC
API: JDBC API 是一个自然的 Java 接口，建立在 ODBC 之上，因此 JDBC 保留了 ODBC 的一些基本特性
回答by Micha? Niklas
Are you sure you are comparing drivers and not whole environments?
您确定要比较的是驱动程序而不是整个环境吗？
I see that for ODBC you use C program. Try ODBC driver with the same program you use to test JDBC but now use JDBC-ODBC bridge (I often use Jython for such things). Of course bridge adds some additional time. Also remember that JVM uses JIT -- the longer your application works the better performance.
我看到对于 ODBC，您使用 C 程序。使用您用来测试 JDBC 的相同程序尝试 ODBC 驱动程序，但现在使用 JDBC-ODBC 桥（我经常使用 Jython 进行此类操作）。当然，桥接会增加一些额外的时间。还请记住，JVM 使用 JIT——您的应用程序运行的时间越长，性能就越好。
Performance is important but for me much more important is stability of drivers. I had some problems with various ODBC drivers and now I prefer JDBC drivers. But even ODBC drivers can work with high-load multi-threaded servers for many months.
性能很重要，但对我来说更重要的是驱动程序的稳定性。我在使用各种 ODBC 驱动程序时遇到了一些问题，现在我更喜欢 JDBC 驱动程序。但即使是 ODBC 驱动程序也可以在高负载多线程服务器上工作数月。
回答by Dennis Jaheruddin
Statements presented by mathworkswebsite, these appear to be generally applicable.
mathworks网站提供的声明，这些似乎是普遍适用的。
Deciding Between ODBC and JDBC Drivers
在 ODBC 和 JDBC 驱动程序之间做出决定
Use native ODBC for:
将本机 ODBC 用于：
- Fastest performance for data imports and exports
- Memory-intensive data imports and exports
- 最快的数据导入和导出性能
- 内存密集型数据导入和导出
Use JDBC for:
将 JDBC 用于：
- Platform independence allowing you to work with any operating system (including Mac and Linux?), driver version, or bitness (32-bit or 64-bit)
- Using Database Toolbox functions not supported by the native ODBC interface (such as runstoredprocedure)
- Working with complex or long data types (e.g., LONG, BLOB, text, etc.)
- 平台独立性允许您使用任何操作系统（包括 Mac 和 Linux？）、驱动程序版本或位数（32 位或 64 位）
- 使用本机 ODBC 接口（例如 runstoredprocedure）不支持的 Database Toolbox 函数
- 处理复杂或长数据类型（例如，LONG、BLOB、文本等）
Tip:
提示：
- On Windows systems that support both ODBC and JDBC drivers, pure JDBC drivers and the native ODBC interface provide better connectivity and performance than the JDBC/ODBC bridge.
- 在同时支持 ODBC 和 JDBC 驱动程序的 Windows 系统上，纯 JDBC 驱动程序和本机 ODBC 接口提供比 JDBC/ODBC 桥更好的连接性和性能。
回答by Cameron McKenzie
I always find these types of discussions about ODBC vs JDBCperformance a bit off the mark, not unlike the discussions around JPA vs Hibernate.
我总是发现这些关于ODBC 与 JDBC性能的讨论有点不合时宜，与围绕JPA 与 Hibernate的讨论不同。
A C++ app using an ODBC driver written in C will likely be lightning fast for the small portion of the database interaction taking place. Similarly, a Java program connecting to a database using a vendor's driver which has been optimized for their particular database will be pretty darn fast as well.
使用 C 语言编写的 ODBC 驱动程序的 C++ 应用程序对于发生的数据库交互的一小部分可能会快如闪电。同样，使用针对特定数据库优化的供应商驱动程序连接到数据库的 Java 程序也会非常快。
But looking at a request-response cycle with a database, the network latency involved in making the request is significantly greater than the overhead of the API. Similarly, the time it takes to search a database or update a record or hold a transaction alive will be orders of magnitude more significant that any efficiency one would garner from choosing ODBC over JDBC.
但是从数据库的请求-响应周期来看，发出请求所涉及的网络延迟明显大于 API 的开销。类似地，搜索数据库、更新记录或保持事务活动所花费的时间将比选择 ODBC 而非JDBC所获得的任何效率高出几个数量级。
Use the driverrecommended by the vendor given the languageyou are developing with. And leave the performance issues to the database admins and SQL developers to solve. This isn't where you're going to resolve your database bottlenecks.
根据您正在使用的语言，使用供应商推荐的驱动程序。并将性能问题留给数据库管理员和 SQL 开发人员来解决。这不是您要解决数据库瓶颈的地方。
回答by Davos
The point of the assignment was to introduce you to a real application example that compares the performance characteristics of a pre-compiled language Cto a just-in-time (JIT) interpreted^ language Java.
作业的重点是向您介绍一个真实的应用程序示例，该示例将预编译语言的性能特征与C即时 (JIT) 解释语言的性能特征进行比较Java。
^The difference between interpreted and compiled code is a pedantic argument, truthfully all code is interpreted at runtime; even assembly is converted to machine language at runtime, and machine language resolves to memory addresses and CPU instructions.
The important distinction here is pre-compiled vs JIT. The difference is how close the code gets to machine code at build-time vs run-time. C gets closer at build-time ( for the most part, ignoring recent advances in heuristic compilation in Java).
^解释代码和编译代码之间的区别是一个迂腐的论点，老实说所有代码都是在运行时解释的；甚至汇编在运行时也转换为机器语言，机器语言解析为内存地址和 CPU 指令。
这里的重要区别是预编译与 JIT。区别在于代码在构建时与运行时与机器代码的接近程度。C 在构建时越来越接近（在大多数情况下，忽略 Java 中启发式编译的最新进展）。
This assignment scenario adds in the realistic complication of database data retrieval, which partly serves to increase the numbers so you have something to work with, but mostly to accentuate that the program time consists of fixed (start up) and variable (in this case I/O bound) phases. It could also have been a CPU-bound example, the same pattern would have emerged.
这种分配方案增加了数据库数据检索的现实复杂性，这部分是为了增加数量，以便您可以使用一些东西，但主要是为了强调程序时间由固定（启动）和可变（在这种情况下我/O 绑定）阶段。它也可能是一个受 CPU 限制的例子，同样的模式也会出现。
It starts to be easier to see if you graph the values in a chart.
如果您在图表中绘制值，则开始更容易查看。
Look at the slope of the two lines. I think it's an anomaly that in your numbers the C program is slower over 4000+ records, but that's not important and should not distract from the core point of the example.
看两条线的斜率。我认为在您的数字中，C 程序在超过 4000 条记录时速度较慢是一个异常现象，但这并不重要，不应分散示例的核心观点。
- The C app starts with 100 rows in 76ms, quite close to the origin at 0
- The Java app starts at 586ms, quite close to 500.
- C 应用程序在 76 毫秒内从 100 行开始，非常接近原点 0
- Java 应用程序从 586 毫秒开始，非常接近 500。
The C app startup time is negligible so can be effectively ignored.
C 应用程序启动时间可以忽略不计，因此可以有效地忽略。
The Java app startup time, on the other hand, is around 500ms. It is the JIT compiler interpreting the Java bytecode on the Java Virtual Machine (JVM); it's a fixed start-up cost that you pay for each run of the code no matter how much data you retrieve from the database.
另一方面，Java 应用程序启动时间约为 500 毫秒。它是在 Java 虚拟机（JVM）上解释 Java 字节码的 JIT 编译器；无论您从数据库中检索多少数据，您都需要为每次运行代码支付固定的启动成本。
You can consider that 500ms to be the real origin of your data access times, and see that the program grows linearly from that 500ms point.
您可以将 500 毫秒视为数据访问时间的真正来源，并看到程序从 500 毫秒开始线性增长。
It is not the drivers JDBC vs ODBC per say, however, the JDBC driver is also a Java library that is effectively an extension of your program and subject to the same JIT, similarly the ODBC driver is also pre-compiled C library that is effectively an extension of your program. It wouldn't be fair to blame the drivers specifically (assuming they are both optimized) it is more about the application context as a whole.
不是 JDBC 与 ODBC 的驱动程序，但是，JDBC 驱动程序也是一个 Java 库，它实际上是您程序的扩展并受相同的 JIT 约束，同样，ODBC 驱动程序也是预编译的 C 库，有效地程序的扩展。专门责怪驱动程序（假设它们都经过优化）是不公平的，它更多地是关于整个应用程序上下文。
