H2 (DBMS)

1. 개요

H2는 2004년에 개발이 시작되어 2005년에 첫 버전이 출시된 자바 기반의 오픈 소스 관계형 데이터베이스 관리 시스템(DBMS)이다. SQL 표준의 하위 집합을 지원하며, JDBC, Hibernate, ODBC 등 다양한 인터페이스를 통해 접근할 수 있다. 내장 모드와 클라이언트-서버 모드 모두 지원하며, 인 메모리 및 암호화 데이터베이스를 생성할 수 있다. 또한, 클러스터링, 분산 트랜잭션, 전문 검색, 고가용성 등의 기능을 제공하며, 특히 정전과 같은 상황에서 데이터베이스의 내구성에 영향을 미칠 수 있는 문제점에 대한 정보를 제공한다.

2. 역사

H2 데이터베이스 엔진의 개발은 2004년 5월에 시작되었으며 첫 판은 2005년 12월에 출시되었다. 데이터베이스 엔진은 토마스 뮐러(Thomas Mueller)가 작성하였다. 그는 자바 데이터베이스 엔진 하이퍼소닉 SQL(Hypersonic SQL)을 개발하였다. 2001년, 하이퍼소닉 SQL 프로젝트는 중단되었고 HSQLDB 그룹이 창설되어 하이퍼소닉 SQL 코드에 대한 작업을 계속해나갔다. H2라는 이름은 하이퍼소닉 2(Hypersonic 2)를 뜻하지만 H2는 하이퍼소닉 SQL 또는 HSQLDB와 코드를 공유하지 않는다. H2는 완전히 새로 개발된 것이다.

3. 주요 기능

H2는 SQL 표준의 일부를 지원한다. 주요 프로그래밍 API는 SQL과 JDBC이지만, PostgreSQL ODBC 드라이버를 사용하여 PostgreSQL 서버처럼 작동하도록 할 수도 있다.

* JDBC, Hibernate, ODBC 등에서 접근할 수 있다.
* 내장 모드와 클라이언트-서버 모드 모두에서 작동한다.
* 순수 자바로 작성되어 GIJ나 IKVM.NET에서도 작동한다.
* 크기가 약 1MB로 작다.
* 다중 버전 동시성 제어(MVCC)를 지원한다.
* 인 메모리 데이터베이스, 암호화 데이터베이스를 만들 수 있다.
* 클러스터링과 분산 트랜잭션(2단계 커밋)을 지원한다.

3.1. 테이블 유형

H2는 인메모리 테이블과 디스크 기반 테이블을 모두 생성할 수 있다. 테이블은 영구적이거나 일시적일 수 있다. 인덱스 타입은 인메모리 테이블의 경우 해시 테이블 또는 트리 형태를 사용하며, 디스크 기반 테이블에는 B 트리를 사용할 수 있다. 모든 데이터 조작은 트랜잭션 기반으로 이루어진다. 테이블 수준 잠금 및 다중 버전 동시성 제어(MVCC)가 구현되어 있다. 2단계 커밋 프로토콜도 지원하지만, 분산 트랜잭션을 위한 표준 API는 구현되어 있지 않다.

3.2. 트랜잭션

H2는 인메모리 테이블과 디스크 기반 테이블을 모두 생성할 수 있으며, 테이블은 영구적이거나 일시적일 수 있다. 인메모리 테이블의 인덱스 타입은 해시 테이블이나 트리로 사용 가능하며, 디스크 기반 테이블에는 B 트리를 사용할 수 있다. 모든 데이터 조작은 트랜잭션에 기반하며, 테이블 수준의 잠금과 다중 버전 동시성 제어(MVCC)가 구현되어 있다. 2단계 커밋 프로토콜도 지원하지만, 분산 트랜잭션을 위한 표준 API는 구현되어 있지 않다.

3.3. 보안 기능

H2는 역할 기반 접근 권한, SHA-256을 사용한 비밀번호 암호화, AES 또는 Tiny 암호화 알고리즘인 XTEA를 사용한 데이터 암호화를 제공한다. 암호화 기능은 데이터베이스 내부 함수로도 사용할 수 있다. 클라이언트-서버 모드와 콘솔 애플리케이션에서 SSL/TLS 연결을 지원한다.

H2는 매개변수화된 구문 사용을 강제하여 SQL 주입에 대한 보호를 지원한다. H2에서는 이 기능을 '리터럴 비활성화'라고 부른다.

3.4. 전문 검색

H2에는 네이티브 구현과 Lucene을 사용하는 구현, 이렇게 두 가지 전문 검색 구현이 포함되어 있다.

3.5. 고가용성

단순한 형태의 고가용성이 구현되어 있다. 클라이언트-서버 모드에서 사용 시, 데이터베이스 엔진은 핫 페일오버(일반적으로 클러스터링이라고 함)를 지원한다. 하지만, 클러스터링 모드는 장애 발생 후 수동으로 활성화해야 한다.

3.6. 클라우드 버전

H2 인 메모리 데이터베이스는 버전 1.1.111부터 구글 앱 엔진 내에서 실행할 수 있다.

4. 특징

H2는 SQL 표준의 일부를 지원한다. 주 프로그래밍 API는 SQL과 JDBC이지만, 데이터베이스가 PostgreSQL 서버처럼 동작하도록 PostgreSQL ODBC를 사용하여 지원하기도 한다.

인메모리 테이블과 디스크 기반 테이블을 모두 생성할 수 있으며, 테이블은 영구적이거나 일시적일 수 있다. 인메모리 테이블의 경우 해시 테이블이나 트리 형태의 인덱스를 사용할 수 있고, 디스크 기반 테이블에는 B 트리 인덱스를 사용할 수 있다. 모든 데이터 조작은 트랜잭션 기반으로 이루어진다. 테이블 수준 잠금과 다중 버전 동시성 제어(MVCC)가 구현되어 있다. 2단계 커밋 프로토콜도 지원하지만, 분산 트랜잭션을 위한 표준 API는 구현되어 있지 않다.

5. 관계형 데이터베이스의 내구성에 영향을 미치는 문제점

H2 문서는 기본 하드웨어, 특히 전원 시스템의 문제점이 관계형 데이터베이스의 내구성에 영향을 미칠 수 있는 여러 가지 방법을 자세히 설명한다. 이러한 문제는 DB 엔진 설계뿐만 아니라 스토리지 캐싱 메커니즘과도 관련이 있다.

갑작스러운 정전 시 데이터 보존에 관한 하드웨어적 제한 사항과, 이러한 손실을 방지하기 위해 개발자가 일반적으로 사용하는 접근 방식의 비효율성을 고려할 때, 많은 데이터베이스 엔진은 내구성을 크게 향상시키지 않으면서 시스템 성능을 현저히 저하시키기 때문에 기본적으로 모든 커밋에 대해 `FileDescriptor.sync()`, `FileChannel.force()` 또는 fsync 또는 이에 상응하는 기능을 호출하지 않는다.

HSQLDB 문서에서는 유사한 문제점에 대한 해결책을 다루고 있으며, 마이크로소프트 기술 자료에서는 정전, 쓰기 캐싱 등과 같은 문제가 성능 및 내구성에 미칠 수 있는 영향을 설명하고, 성능과 디스크 쓰기 캐싱의 취약성 간의 상충 관계와 관리자가 이러한 균형을 맞추기 위해 사용할 수 있는 설정을 설명한다.

5.1. 스토리지 캐싱 메커니즘 문제

H2 문서는 DB 엔진 설계뿐만 아니라 스토리지 캐싱 메커니즘과 관련된 문제점도 설명한다. 스토리지 장치는 속도를 높이기 위해 쓰기 캐시를 사용하는데, 정전 시 장치 캐시의 데이터가 손실될 수 있다. 따라서 관리자는 비즈니스 요구 사항에 맞춰 속도와 데이터 손실 위험 사이의 균형점을 평가하고, 중요 서버의 전원 공급 장치 및 UPS 설계를 신중하게 고려해야 한다.

경우에 따라 fsync를 사용하여 스토리지에 자주 또는 즉시 쓰기 캐시를 강제할 수 있다. 이 경우 쓰기 프로세스가 느려지거나, 장치 버퍼의 캐싱으로 인해 정전 시 데이터 손실 위험이 발생할 수 있다는 점을 고려해야 한다. fsync 사용의 효과는 많은 HDD가 공장 기본값으로 쓰기 캐싱을 활성화한다는 사실에 의해 제한된다. 이 경우 데이터베이스 설계나 설정 또는 OS 수준 명령으로 갑작스러운 정전 시 손실되거나 일관되지 않은 데이터의 가능성을 제거할 수 없다. 데이터를 실시간으로 쓰기 위해 모든 캐싱을 비활성화하도록 OS 및 하드웨어 설정을 사용하면, 회전 디스크를 사용할 때 약 100 초당 쓰기 작업만 달성할 수 있으므로 성능에 상당한 영향을 미칠 수 있다.

5.2. `fsync` 사용의 한계

H2 문서는 기본 하드웨어, 특히 전원 시스템의 문제점이 관계형 데이터베이스의 내구성에 영향을 미칠 수 있는 여러 가지 방법을 자세히 설명한다. 이러한 문제는 DB 엔진 설계뿐만 아니라 스토리지 캐싱 메커니즘과도 관련이 있다. 스토리지 장치는 속도를 높이기 위해 쓰기 캐시를 사용하므로 정전 시 장치 캐시의 데이터가 손실된다. 따라서 관리자는 비즈니스 요구 사항에 맞춰 속도와 데이터 손실 위험 사이의 균형점을 평가하고, 중요 서버의 전원 공급 장치 및 UPS 설계를 신중하게 고려해야 한다.

경우에 따라 fsync를 사용하여 스토리지에 자주 또는 즉시 쓰기 캐시를 강제로 사용하도록 할 수 있으며, 이 경우 쓰기 프로세스가 느려지거나, 장치 버퍼의 캐싱으로 인해 정전 시 데이터 손실 위험이 발생할 수 있다는 점을 받아들일 수 있다. fsync 사용의 효과는 많은 HDD가 공장 기본값으로 쓰기 캐싱을 활성화한다는 사실에 의해 제한되며, 이 경우 데이터베이스의 설계나 설정 또는 OS 수준 명령으로 갑작스러운 정전 시 손실되거나 일관되지 않은 데이터의 가능성을 제거할 수 없다. 데이터를 실시간으로 쓰기 위해 모든 캐싱을 비활성화하도록 OS 및 하드웨어 설정을 사용하면, 회전 디스크를 사용할 때 약 100 초당 쓰기 작업만 달성할 수 있으므로 성능에 상당한 영향을 미칠 수 있다.

5.3. 내구성(ACID) 관련 잠재적 문제

H2 문서는 기본 하드웨어, 특히 전원 시스템의 문제점이 관계형 데이터베이스의 내구성에 영향을 미칠 수 있는 여러 가지 방법을 자세히 설명한다.

H2 문서에 따르면 이러한 문제는 DB 엔진 설계뿐만 아니라 스토리지 캐싱 메커니즘과도 관련이 있다. 스토리지 장치는 속도를 높이기 위해 쓰기 캐시를 사용하므로 정전 시 장치 캐시의 데이터가 손실된다. 따라서 관리자는 비즈니스 요구 사항에 맞춰 속도와 데이터 손실 위험 사이의 균형을 평가하고, 중요 서버의 전원 공급 장치 및 UPS 설계를 신중하게 고려해야 한다.

경우에 따라 fsync를 사용하여 스토리지에 자주 또는 즉시 쓰기 캐시를 강제할 수 있으며, 이 경우 쓰기 프로세스가 느려지거나, 장치 버퍼의 캐싱으로 인해 정전 시 데이터 손실 위험이 발생할 수 있다는 점을 받아들일 수 있다. fsync 사용의 효과는 많은 HDD가 공장 기본값으로 쓰기 캐싱을 활성화한다는 사실에 의해 제한되며, 이 경우 데이터베이스의 설계나 설정 또는 OS 수준 명령으로 갑작스러운 정전 시 손실되거나 일관되지 않은 데이터의 가능성을 제거할 수 없다. 데이터를 실시간으로 쓰기 위해 모든 캐싱을 비활성화하도록 OS 및 하드웨어 설정을 사용하면, 회전 디스크를 사용할 때 약 100 초당 쓰기 작업만 달성할 수 있으므로 성능에 상당한 영향을 미칠 수 있다.

H2 문서는 잠재적인 데이터 손실로 인한 내구성(ACID의 일부)과 관련된 잠재적인 문제점을 자세히 설명한다. 정전 시 커밋된 트랜잭션이 발생한다.

갑작스러운 정전 시 데이터 보존에 관한 하드웨어적 제한 사항과, 이러한 손실을 방지하기 위해 개발자가 일반적으로 사용하는 접근 방식의 비효율성을 고려할 때, 많은 데이터베이스 엔진은 내구성을 크게 향상시키지 않으면서 시스템 성능을 현저히 저하시키기 때문에 기본적으로 모든 커밋에 대해 `FileDescriptor.sync()`, `FileChannel.force()` 또는 fsync 또는 이에 상응하는 기능을 호출하지 않는다.

HSQLDB 문서에서는 유사한 문제점에 대한 해결책을 문서에서 참조하고 있다.

마이크로소프트 기술 자료에서는 정전, 쓰기 캐싱 등과 같은 문제가 성능 및 내구성에 미칠 수 있는 영향을 설명한다. 기술 자료에서는 성능과 디스크 쓰기 캐싱의 취약성 간의 상충 관계와 관리자가 이러한 균형을 맞추기 위해 사용할 수 있는 설정을 설명한다.

6. 유틸리티

H2 데이터베이스는 브라우저 기반 콘솔 애플리케이션과 함께 내장된 웹 서버를 포함하고 있으며, 서버 시작 및 중지, 데이터베이스 백업 및 복원, 명령줄 셸 도구를 위한 명령줄 도구도 제공한다.