2012-04-24 64 views
2

我有一個應用程序必須將約1300萬行約10個平均長度的字符串插入到嵌入式HSQLDB中。我一直在調整的東西(批量大小,單線程/多線程,緩存/非緩存表,MVCC事務,log_size/no日誌,定期調用checkpoint,...),它仍然需要7個小時的16核心, 12 GB的機器。HyperSQL(HSQLDB):大量插入性能

我選擇了HSQLDB,因爲我覺得如果我把所有這些內核都用得很好,我可能會有很大的性能提升,但我真的開始懷疑我的決定。

任何人都可以看到我的銀彈嗎?

+2

要冒險猜測(不是HSQLDB專家)並說主要阻止程序在您的IO(磁盤)上。 – hkf 2012-04-24 07:26:32

+0

是的,我認爲CPU百分比並不是完全通過屋頂。從多個線程進行批量插入有什麼好處,或者在這種情況下,我應該堅持單線程嗎? – 2012-04-24 07:31:47

+0

可能不會,除非您可以實施基於SSD的解決方案。 – hkf 2012-04-24 07:34:48

回答

1

檢查你的應用程序正在做什麼。首先要看taskmanager(或特定操作系統)和visualvm中的資源利用情況。

爲造成了不良的性能不錯的候選人:

  • 磁盤IO
  • 垃圾收集
0

H2Database可以給你比HSQLDB(同時保持語法兼容)表現略好。

在任何情況下,您都可能想嘗試使用較高的延遲時間同步到磁盤以減少隨機存取磁盤I/O。 (即SET WRITE_DELAY <num>

希望你正在做批量INSERT報表,而不是每行一個插入。如果沒有,那麼儘可能做到這一點。

根據您的應用程序要求,您最好使用鍵值存儲而不是RDBMS。 (您是否經常需要插入1.3 * 10^7個條目?)

您的主要限制因素是隨機訪問磁盤操作。我非常懷疑你正在做的任何事情都是CPU限制的。 (看看top,然後將其與iotop比較!)

0

有了這麼多的記錄,也許你可以考慮切換到NoSQL數據庫。當然,這取決於您需要存儲的數據的性質/格式。

5

使用CACHED表時,磁盤IO大部分時間都用完了。由於您插入到同一個表中,因此不需要多個線程。顯着提高性能的一件事是重用單個參數化的PreparedStatment,爲每個行插入設置參數。

在您的機器上,通過對內存映射IO使用較大的NIO限制,可以顯着提高IO性能。例如SET FILES NIO SIZE 8192。 64位JVM對於較大的尺寸需要有效。

http://hsqldb.org/doc/2.0/guide/management-chapt.html

爲了減少IO爲大容量插入使用SET FILES LOG FALSE的持續時間和直到所述插入件的端部不執行檢查點。細節在這裏討論:

http://hsqldb.org/doc/2.0/guide/deployment-chapt.html#dec_bulk_operations

更新:1600萬行的插入測試下方產生了1.9千兆字節。數據文件,並只花了幾分鐘的時間,平均2核處理器和7200轉的硬盤上。關鍵是大的NIO分配。

connection time -- 47 
complete setup time -- 78 ms 
insert time for 16384000 rows -- 384610 ms -- 42598 tps 
shutdown time -- 38109 
+0

這是什麼操作系統?我發現在OS X上大批量插入操作相當快,而在Windows上(在各種硬件配置上)速度很慢。插入108,000行大約需要1分鐘,在2007年中期的Mac Mini上使用內置硬盤驅動器。新型非虛擬化Windows服務器需要大約15分鐘的時間,而在2006年的非虛擬Dell 750 Windows服務器上需要大約15分鐘(大約20分鐘後取消)。 – 2013-04-24 22:03:32

+0

沒關係 - 問題原來是索引相關的。當我添加索引時,問題已修復。 – 2013-05-07 14:44:50