Database-Design
Derby、H2 或 SQLite 會比 HSQL 提供更快的載入時間和/或更小的文件大小嗎?
我有一些帶有以下列的平面文件;3 個整數、3 個實數和 1 個 varchar(20)。對於查詢,我需要一個包含 1 個整數列和 varchar 列的索引。每個文件大小約為 1.8GB,行數約為 3800 萬。
目前我正在使用 HSQL(Standalone) 數據庫來載入文件進行處理;每個文件一個數據庫。當使用以下選項創建數據庫時,載入文件非常慢(120+ 分鐘)並導致 4.7GB 的數據庫文件。
"Properties" -> { "check_props" -> "true", "shutdown" -> "true", "hsqldb.default_table_type" -> "cached", "sql.syntax_mss" -> "true", "hsqldb.log_data" -> "false", "hsqldb.inc_backup" -> "false" }
該文件分批讀取 100k 條記錄。讀取速度非常快(幾乎是即時的),所以我不認為是讀取速度減慢了速度。關閉與數據庫的連接也需要很長時間。
我可以選擇使用 Derby、H2 或 SQLite。在這種情況下,這些是否會導致更快的載入時間和/或更小的數據庫文件大小?如果是這樣,應該使用哪些連接字元串選項來實現此目的?或者,是否有不同的連接字元串選項可以與 HSQL(Standalone) 一起使用,以減少載入時間和/或數據庫文件大小?
添加了驅動程序資訊。
JDBCDriver[ "Name" -> "HSQL(Standalone)", "Driver" -> "org.hsqldb.jdbcDriver", "Protocol" -> "jdbc:hsqldb:file:", "Version" -> 3.1, "Description" -> "HSQL Database Engine (In-Process Mode) - Version 2.3.3 - This ...", "Location" -> "C:\... "]
我可用的其他選項的驅動程序資訊。
德比
JDBCDriver[ "Name" -> "Derby(Embedded)", "Driver" -> "org.apache.derby.jdbc.EmbeddedDriver", "Protocol" -> "jdbc:derby:", "Version" -> 3.1, "Description" -> "Derby Database Engine (Embedded Mode) - Version 10.12.1.1 - This...", "Location" -> "C:\... "]
H2
JDBCDriver[ "Name" -> "H2(Embedded)", "Driver" -> "org.h2.Driver", "Protocol" -> "jdbc:h2:", "Version" -> 3.1, "Description" -> "H2 Database Engine (Embedded Mode) - Version 1.3.176 - This...", "Location" -> "C:\... "]
SQLite
JDBCDriver[ "Name" -> "SQLite", "Driver" -> "org.sqlite.JDBC", "Protocol" -> "jdbc:sqlite:", "Version" -> 3.1, "Description" -> "SQLite using Zentus-derived JDBC Driver - Version 3.8.11.2", "Location" -> "C:\..."]
其他變體包括以下內容。但是,我需要它在客戶端的電腦上執行。我相信這不包括伺服器和網路伺服器模式。
{"Derby(Embedded)", "Derby(Server)", "H2(Embedded)", "H2(Memory)", "H2(Server)", "HSQL(Memory)", "HSQL(Server)", "HSQL(Standalone)", "SQLite", "SQLite(Memory)"}
您需要更大的 Java 記憶體分配和更大的 HSQLDB 記憶體記憶體大小,以便更快地將數據載入到大型表中。
hsqldb.cache_rows=4000000
將和添加hsqldb.cache_size=1000000
到新數據庫的啟動配置中。http://hsqldb.org/doc/2.0/guide/dbproperties-chapt.html#dpc_db_file_mem