Question

最近我开始学习Hibernate，在浏览时我遇到了这个网站：Hibernate Vs JDBC。

该链接显示有2个表格 - User＆amp; Contract每个用户有3个合同。 User中的记录数为100,000，Contract表中的记录数为300,000。

现在，当我们有数十万的记录时，链接已经举例说明它如何影响性能。

我在我的机器上运行代码，而普通的JDBC代码仅用486 ms来获取User＆amp; Contract加入两个表的详细信息。

现在如果我们使用Hibernate进行相同的操作，那么它需要相当长的时间，如下所示：

// Using Fetch mode as **@Fetch(FetchMode.SUBSELECT)**
test1 : 11

// Using Fetch mode as **@Fetch(FetchMode.SELECT)**
test2 : 50

// Using Fetch mode as **@Fetch(FetchMode.JOIN)**
test3 : 45
// Using HQL query using **join fetch** option
test4 : 7
// Using Hibernate native SQL query
test4 : 3

这里的数字以秒为单位。

那么这是否意味着Hibernate仅适用于小型项目？

如果我的数据库有大约几十万的记录，我们应该使用普通的JDBC吗？我认为拥有这个范围的记录对于许多应用程序来说很常见，那么开发人员在这种情况下如何使用hibernate呢？

Answer 1

那么你的表可能包含数十万个条目，但是批处理（当你加载那么多条目时你正在这样做）最好用JDBC完成，或者至少不能加载所有条目不考虑你加载那么多条目的条目。

另请参阅：JPA: what is the proper pattern for iterating over large result sets?

Answer 2

Hibernate不会优化性能。没有魔力。它（充其量）可以像原始JDBC一样快。每当有人抱怨它时，我都会提醒他们调整。一切都需要调整。甚至数据库本身：索引和分区。开箱即用的性能（默认情况下一切）仅适用于POC。

Hibernate做了什么，顺便说一句，你应该使用标准的JPA，而不是直接使用Hibernate，它可以避免编写繁琐的映射和其他易于变成意大利面条的管道代码。这些可维护性问题会在任何性能问题上更快地杀死您的项目。

优化Hibernate包括正确的延迟与急切联接等。顶部避免N + 1选择问题，以及索引和分区。您应该100％清楚地将其查询转换为原始SQL。当你看到你不喜欢的东西时调整它。

现在，如果您有大量数据集：数十亿和数万亿的遥测或统计数据记录，您应该查看列存储NoSQL数据库又名大表。目前Cassandra是最快的。它基本上是一个巨大的分布式索引。

我们不应该将hibernate用于大型数据库

2 个答案: