NoSQL 용 ORM인 hibernate-ogm을 소개합니다.

OOP 와 RDBMS 의 매핑을 위해 탄생한 ORM ( Object Relational Mapping ) 이 있다면, OOP 와 NoSQL 의 매핑을 위한 OGM ( Object Grid Mapping ) 이 탄생하는 것은 자연스러운 현상이겠죠^^
ORM의 대표 주자인 JBoss 의 hibernate 를 기반으로 OGM 용 라이브러리인 hibernate-ogm 이 있습니다. 현재 4.0.0 Beta 2 까지 나왔고, 공식 대상 NoSQL은 EhCache, Infinispan, MongoDB 이고, 비공식적으로는  Redis, HBase, Cassandra 도 지원 또는 개발 중입니다.

hibernate-ogm 의 장점 중에 또 한가지는 hibernate-search 도 결합하여, lucene의 인덱스 정보를 no-sql 에 저장이 가능하도록 했습니다. 이렇게되면, 검색 서비스도 분산 환경에서는 확실히 확장성을 보장해 주겠지요.

다음 발표자료를 보시면 좀 더 잘 아실 수 있을 겁니다.


Spring-data 에서도 NoSQL 을 위한 다양한 라이브러리가 있지만, 제가 hibernate 의 heavy user 이라서, no-sql을 사용할 때도 hibernate 를 그대로 사용할 수 있으면 좋겠다 싶었는데, 작년부터 알게되었지만, 이제사 제대로 사용하게 되었습니다.

혹시 관심있으신 분들도 한번 시도해보시기 바랍니다. No-SQL 에서 relation 관련 기존 관습을 타파하지 못해 적용하는데 실패하는 경우도 많고, 실전으로 사용하는데, 신뢰가 없을 때 pilot 으로 시도해 볼 수도 있을 겁니다.

한가지 아쉬운 점은 JBoss 가 너무 자기중심적으로 Infinispan 을 미는 게 확산에 걸림돌이 되지 않나 싶네요^^.
하지만 곧 7월에 책 (Pro Hibernate and MongoDB) 도 나오니, 좀 더 확산이 되지 않을까 싶네요.

Spring 을 이용한 hibernate 환경설정

진부한 내용일 수 있지만, Spring 을 이용해 hibernate 에 대한 환경 설정에 대한 정보가 대부분 단편적이거나, 하나의 DB에 대해서만 설명한 글이 대부분이라...
hibernate 가 여러 DB를 동시에 만족 시킬 수 있음을 강조하고, 솔루션을 만들 때 여러 DB에 대해 만족할 수 있도록 테스트를 쉽게 하기 위해 간단하게나마 hibernate 설정을 spring 의 @Configuration을 이용하여 제작해 보았습니다.

우선 모든 DB에 대해 공통적으로 적용되는 부분에 대해 다음과 같이 정의했습니다.


public SessionFactory sessionFactory() {...} 함수가 가장 중요하고, 나머지는 뭐 별로...
당연히 hibernate 설정 클래스이니까... ㅎㅎ
sessionFactory를 만드는데, 여러가지 필요한 설정들을 지정하게 하는데, 미리 정의된 부분도 있고, 사용자가 더 필요한 부분은 "setupSessionFactory(factoryBean)" 위임 메소드를 이용하여, 추가로 정의 할 수 있도록 했습니다.

그럼 대표적으로 사용하는 DB인 HSQL, MySQL, PostgreSQL 에 대한 기본 환경설정 클래스를 보겠습니다.

1. HSql 메모리 DB 사용 (단순 테스트시 유용)

2. MySQL

3. PostgreSql

4. PostgreSql with pgpool-II

과 같다.

아주 사소한 port 번호 같은 것은 기본 값을 사용했다.
뭐 각각 다른 것은 DB명, ConnectionString, Dialect 등이다. 별 차이 없지만, 이렇게 구조적으로  상속체계를 해 놓으면, 실전에서 아주 편리하다.

실제 사용하는 예는 HSql 과 PostgreSql 의 예를 들어보자.

1. HSql 메모리 DB를 이용한 환경 설정 (2nd 캐시도 적용됨)


2. PostgreSql 의 "HAccess" DB 를 이용한 환경 설정 (2nd Cache도 적용됨)

이 것으로 끝나는게 아니고, Application 용 환경설정에서는 다음과 같이 위의 두 가지 환경설정 Class 를 입맛에 따라 Import 해서 테스트를 수행하면 된다.

정말 쉽죠?

이제 실제 단위 테스트 클래스에서 AppConfig를 지정해서 테스트를 수행하시면 됩니다^^

ORM의 장점 중에 여러 DB에 대해 일관된 작업이 가능하므로, 솔루션을 만들때는 최선의 선택이라 생각하는지라, 위와 같은 설정으로 개발을 수행합니다. (비록 한가지 DB만을 대상으로 하는 시스템이라도... 향후 어떻게 될지 모르고, 코드 재활용성도 생각하고^^)

hibernate 가 identity column을 clustered index 로 만들지 않는 이유

오랜만에 글을 쓰네요...
요즘 프로젝트 문서 작성을 주로 하는 바람에 글을 쓸 밑천이 없었네요 ㅎㅎ
이런 얕은 내공이라구...

오늘은 그동안 궁금했던 "왜 SQL Server 는 primary key가 clustered index 인데, PostgreSQL, MySQL 등은 clustered index 가 아닌가?" 에 대해 그냥 RDBMS 마다 속 사정이 있겠지... 하고 넘어갔었는데, hibernate 로 매핑을 수행하던 도중에 혹시나 하는 마음에 구글링을 해 봤습니다...

이런 논의가 hibernate 에서도 진행되었었네요...

원문( https://hibernate.onjira.com/browse/HHH-3305 ) 을 보면, Clustered Index 자체가 성능이 좋긴 하고, SQL Server 는 Primary Key가 기본으로 Clustered Index 지만

1. 다른 DB들은  Primary Key가 Clustered Index 가 아니다.
2. 유지 관리에 애로점이 있다.
3. SQL Server 는 DBA 기술이 없는 작은 조직에 초점이 맞춰져있다.
4. Clustered Index 를 삭제하고자 할때에는 부가적인 작업이 필요하다.

흠 이런 이유 때문인지는 모르지만, SQL Server 는 hiberante mapping test 시에 association으 변경 될 때 drop 시 실패하는 경우가 다반사입니다. oracle, postgresql은 괜찮구요. 물론 drop cascade 를 지원하기 때문이기도 하구요...

그동안 습관적으로 Primary Key는 Clustered Index 여야만 해!!! 라는 고정관념을 깨게 되었습니다.

뭐 꼭 필요하다면, DBA 가 튜닝 단계에서 적용해주는게 합당하겠죠^^