我們不應該在大型數據庫中使用hibernate

最近我開始學習Hibernate，並在瀏覽時遇到了這個站點：Hibernate Vs JDBC。我們不應該在大型數據庫中使用hibernate

該鏈接表示有2個表格 - User & Contract其中每個用戶有3個合同。 User中的記錄數爲100,000，Contract表中的記錄數爲300,000。

現在鏈接給出了一個例子，說明當我們的記錄在十萬個範圍內時，它對性能的影響。

我跑我的機器上的代碼和普通的JDBC代碼只花了486 ms通過連接這兩個表中得到User & 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？

來源

2015-06-18 user3181365

您是否嘗試過使用Criteria？只是好奇.. –

@ user1354678，不，我只是按照我提到的鏈接給出的例子。 – user3181365

也許只是缺少一個索引？ – Seelenvirtuose

嗯，你的表可能包含數十萬個條目，但批處理（和你正在做的，當你加載多個條目）可能是更好的使用JDBC完成或裝載至少不是所有的項目沒有考慮到你加載了很多條目。

參見：JPA: what is the proper pattern for iterating over large result sets?

來源

2015-06-18 16:58:17 user140547

該鏈接講述了hibernate的分頁概念，如果我們有更多的數據，它是唯一的解決方法嗎？ – user3181365

還有'ScrollableResults'與無狀態會話。無論如何，我認爲使用JDBC進行批處理和使用Hibernate進行OLTP並沒有什麼「錯誤」。 – user140547

@ user140547數據庫的大小並不重要。這完全取決於您在內存中加載的數據量以及用於加載它們的查詢數量。在內存中加載10萬用戶所需的用例非常少見。您通常會加載1個用戶或一些用戶。 –

Hibernate不優化性能。沒有魔法。它（最好）可以像原始JDBC一樣快。每次有人抱怨，我都會提醒他們調整。一切都需要調整。即使是數據庫本身：索引和分區。開箱即用的性能（默認設置）僅適用於POC。

Hibernate是幹什麼的，順便說一句，你應該使用標準的JPA，而不是直接使用Hibernate，它可以使你避免編寫繁瑣的映射和其他管道代碼，這些代碼有可能變成意大利麪條混亂。這些可維護性問題會以任何性能問題快得多的速度殺死您的項目。

優化Hibernate包括適當的懶惰與渴望連接等。top避免N + 1 Select問題，如索引和分區。您應該將其查詢轉換爲原始SQL的方式100％清晰。當你看到你不喜歡的東西時調整它。

現在，如果您有大量數據集：一些遙測或統計數據的數十億和數萬億記錄，您應該查看列存儲NoSQL數據庫（又名Big Table）。目前Cassandra是最快的。它基本上是一個巨大的分佈式索引。

來源

2015-06-18 17:00:43

感謝您的回答。這些表已經有主鍵，所以索引在那裏，那麼在這種情況下如何提高性能，我無法根據您的答案理解？你能澄清一下嗎？ – user3181365

我們不應該在大型數據庫中使用hibernate

回答

相關問題