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でやってみた方がもっと分かりやすいかも知れません。
前提条件と数字は、そのうち公開します。。