[H2] H2 DB의 특징과 사용에 대한 고찰

H2 Database란?

Java SQL Database

주요 기능

• 빠르고 오픈소스인 JDBC API
• In Memory DB(인 메모리 DB)*
• Embedded mode(내장모드) & Server mode(서버모드) 지원
• 브라우저 기반 콘솔 프로그램
• 2MB정도의 적은 용량으로 설치 가능
• ANSI 표준 SQL로 여러 호환성 모드 지원
  • DB2, Derby, HSQLDB, MS SQL Server, MySQL, Oracle, PostgreSQL, Ignite
  • 단, 다른 DB와 각기 차이점이 있기 때문에 잘 비교해서 사용하는 것이 중요하다.
    
    • 실제 예로 H2에서는 AutoIncrement 값을 여러 테이블에서 이용하도록 설정이 가능했지만, MySQL은 불가능했다.
      - H2는 Column Default로 LAST_INSERT_ID() 지정 가능 / MySQL은 불가

Embedded Mode vs Server Mode

• Embedded mode(내장모드) : Application 서버 실행 종료시 데이터 모두 휘발
  
  • H2를 Application과 동일한 JVM을 이용하여 구동, Application이 종료되면 Data가 모두 손실(휘발) - 영속적이지 않음
  • JVM에서 데이터 연산에 사용되는 쓰레드를 인터럽트 하지 않을 수 있어, I/O 수행 시 I/O Handler가 닫히면서 데이터 손상이 일어날 수 있음
  • 테스트 코드 실행시 휘발성으로 동작시키는 경우가 많으므로 해당 모드를 많이 사용했음
• Server mode(서버모드) : Application 서버 종료시에도 지속적으로 해당 데이터를 사용
  • 별도의 JVM을 이용하여 구동 (localhost:9092) - 영속적으로 사용할 수 있음
  • 여러 Application이 해당 H2에 동시 접근 가능
  • Application과는 TCP/IP 통신
    • 내부적으로는 Embedded mode와 동일한 실행 방식을 갖지만, TCP/IP 통신으로 속도가 상대적으로 느림

---

H2를 썼을 때의 장점

1. 가볍고 설치가 쉽고, 관리가 편하다.
   • 프로젝트 초기에 DB에 대한 고민을 조금 덜어줄 수 있다.
2. Unit Test를 할 때 용이하다.
   • 하지만 이 부분은 Mock을 이용하는 것이 더 좋을 것 같긴 하다.
   • 왜냐하면 통합테스트의 경우엔 H2를 쓰지 않는 것이 좋다고 생각하기 때문이다. (아래 내용 참고)

운영에서 H2를 썼을 때의 단점

1. 대규모 프로젝트에서는 안정성과 성능이 부족
2. 백업, 복구 등에 대한 기능 부족

운영이 아닌 경우에만, H2를 썼을 때의 단점

1. H2에서는 지원되지만, 사용하는 DB에서는 지원하지 않는 기능이 있을 수 있음.
   • 기능이 지원되지 않을 수도 있지만, 문법이 다를 수도 있음(호환성 모드가 100% 모두 지원하는 것은 아닌 듯)
   • 이를 H2가 아닌 운영환경(Dev, Real) DB에 배포해보거나, 쿼리를 날려서 확인해봐야 알 수 있음
2. 멀티 DB를 사용하는 경우, 부분만 H2를 사용하면 JPA Create DDL을 이용하기 어려울 수 있고, 잘못 이용하는 경우 원하지 않은 데이터 유실이 될 수 있음
3. 운영에서 H2를 사용하지 않은 경우, 통합 테스트를 H2를 사용하는 것이 옳은 방식인지에 대한 고민
   • 실제 DB로는 테스트하지 않았는데, 이러면 통합 테스트의 의미가 있는지
   • 유닛 테스트 시에 용이하다고 하는데, 그럼 차라리 Mock을 사용하는 것은 어떤지

 

 토이 프로젝트를 할 때는 편리하기도 하고, 고려해야 할 부분도 더 적어서 H2를 자주 사용하곤 했었는데 이것저것 고려하다보니 과연 H2를 사용하는 것이 항상 좋은가, 앞으로도 사용할 것인가에 대한 고민이 생겼다.
 H2를 사용하다가 중간에 호환되지 않거나 불편해서, 혹은 가볍게 사용하려 했지만 오히려 설정이 더 많아지고 번거로워져서, 통합 테스트를 위해 등 여러가지 이유로 MySQL 등으로 전환을 하고 나니 무조건 H2로 시작하는 것이 아닌 꼭 필요한 곳에만 사용해야겠다는 생각마저 들었다.
 물론 토이프로젝트 할 때 편한 것은 부정할 수 없는 사실이다.
 뭔가 사용할 때, '항상 사용했었으니까'가 아닌, '이걸 여기에 써야 좋은 게 맞는 걸까'라는 고민을 하면서 사용하는 개발자가 되고 싶다. 항상 잊지 말고 생각하기!

---

참고

In Memory DB (인 메모리 DB) *

• 디스크가 아닌 주 메모리에 모든 데이터를 가지고 있는 데이터베이스
• 장점) 디스크 검색보다 자료 접근이 훨씬 빠름
  • 디스크 방식에서 데이터의 양이 많아졌을 때, 응답 속도가 떨어지는 문제를 해결하는 대안
    • 디스크 방식 : 디스크에 저장된 데이터를 대상으로 쿼리
    • 인 메모리 방식 : 메모리상에 색인을 넣어 이를 통해 빠르게 검색
• 단점) 휘발성, 전원이 꺼지는 경우 삭제됨
  • 보통은 로그인 세션처럼 데이터가 날아가도 괜찮은 임시 데이터에 주로 쓰임
  • 빠른 속도를 위해 사용하기 때문에 보통 압축을 하지 않음
  • DB에 따라 Durability(영속성)을 보장하기 위해 CUD(INSERT-UPDATE-DELETE)를 디스크에 로그로 기록하여, 재구축하기도 함
• 고려해야할 점
  • 데이터만큼의 메모리(RAM)를 확보하지 않는 경우, 가상메모리를 사용하게 되어 역효과가 일어나기도 함
  • Memory는 Disk보다 고비용
  • 기존 DBMS의 제품들도 인 메모리 DB를 사용할 수 있는 옵션을 제공하는 경우가 있음 (예 - MySQL/MariaDB의 memory엔진)
• 종류
  • Memcached, Redis, ...

•