HSQLDBでSELECT(Hibernate vs JDBC)

上の続き。

• CUSTOMER(id int, name varchar(16))
• ITEM(id int, name varchar(16), price double)
• ORDERS(id int, customer_id int, item_id int, quantity int)

っていうテーブル構成だったとして、ここからデータをSELECTするのに、HibernateとJDBCどっちが速いかってのをやってみました。Hibernate側は、OrdersからCustomer、Itemにそれぞれmany-to-oneの関連をつけてみました。

<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC
        "-//Hibernate/Hibernate Mapping DTD 3.0//EN"
        "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">


    
        
            
        
        
    

    
        
        
	
    

    
        
            
        
        

        
        
    

JDBC側は、まあ普通にINNER JOINして、以下のようなSQLを書いてみました。

SELECT
	c.NAME
	,i.NAME
	,i.PRICE
	,o.QUANTITY
FROM
	CUSTOMER c
	,ITEM i
	,ORDERS o
WHERE
	c.id = o.customer_id
	AND i.id = o.item_id

すると、なんと件数によっては、Hibernateの方が速いという結果に。件数と速度の相関関係としては、各テーブルに100件程度(100 x 100 x 100 = 1,000,000[records])でほぼ互角で、それ以上になるとHibernateの方が速いという結果になりました。
JDBCではINNER JOINしているのに対し、HibernateではOrdersテーブルをSELECTし、CustomerテーブルとItemテーブルをそれぞれレコード数分だけSELECTしているので、とりあえずJDBCでも同じようにやってみることにしました。

SELECT ID, CUSTOMER_ID, ITEM_ID, QUANTITY FROM Orders
SELECT ID, NAME FROM CUSTOMER WHERE ID = ?
SELECT ID, NAME, PRICE FROM ITEM WHERE ID = ?

すると、あっさりHibernateより速くなってしまいました。。
どうやら、JOIN操作でのメモリ不足かなにかで、性能劣化していたみたいです。う〜ん、HSQLDBの扱いって相当難しいのかも。In-Processモードってのも性能に影響を及ぼすのかしら？むしろこの結果からすると、HSQLDBはO/R Mapperと相性が良いのかも知れませんね。
いずれにしても、HSQLDBの特性にひっぱられているところが大きいようなので、Hibernate vs JDBCという意味では、別のDBMSでやってみた方がもっと分かりやすいかも知れません。
前提条件と数字は、そのうち公開します。。