데이터베이스를 지탱하는 기술 - (1) 데이터베이스가 없으면 무엇이...

데이터베이스를 지탱하는 기술 - (1) 데이터베이스가 없으면 무엇이...

데이터베이스가 없으면 무엇이 곤란한가?

1. 대량의 데이터 중에서 필요한 것을 빨리 반환할 수 없다.

대량의 데이터를 어떻게 관리하면 좋을까? 텍스트 파일? 엑셀 시트 등으로 관리하면 좋을까? 이와 같은 방식으로 관리하면 원하는 데이터가 어디에 있는지 즉시 알 수 없기에 하나씩 샅샅이 조사해야 한다. 이럴 경우 데이터 양에 비례한 시간이 걸리게 된다. 100만 건이라면 10만 거의 10배, 1000만 건이라면 10만 건의 100개가 걸린다. 따라서 효율적인 데이터 구조로 관리해야 한다. 이것은 Search(탐색)이라는 기술 영역으로 알려져 있으며, 고속으로 액세스 하기 위해서 B+Tree 인덱스나 해시 인덱스와 같은 데이터 구조로 레코드를 관리할 필요가 있다.

2. 대량의 데이터를 메모리내에서만으로는 취급할 수 없다.

Java의 HashMap 클래스는 키와 값의 쌍으로 데이터를 관리할 수 있으며, 키를 지정하면 초고속으로 값을 취할 수 있다. 하지만 이러한 기초적인 유틸리티 라이브러리에 의해 관리되는 인덱스는 메모리 내에서밖에 사용할 수 없다. 메모리의 크기는 한정되어 있기 때문에 대량의 데이터를 관리하는 데는 무리가 있다. 이보다 더 큰 문제는 메모리는 휘발성이기 때문에 시스템 다운 등이 일어나면 데이터가 날아갈 수 있다. 날아간 데이터를 어떻게 복구할 까? 이것도 중요한 문제이다. 정기적으로 디스크에 기록해두면 될까? 정기적으로 기록한다고 해도 기록한 후와 그다음 기록 사이에 시스템 충돌이 발생한다면? 문제가 생길 수밖에 없다. 또한 디스크로의 기록 시간도 문제이다. 즉 메모리만으로 모든 데이터를 갖는 것 자체는 무모한 아키텍처로 디스크를 활용하는 것을 전제로 하는 데이터 구조가 필요로 하게 된다. 데이터베이스는 이러한 전개로부터 만들어졌다.

3. 장애가 발생했을 때 바른 복구가 어렵다.

데이터베이스가 사용되는 이유 중에 가장 현실적인 이유는 성능면에서의 이유와 여기서 설명할 장애 대책이다. 1분만 정지해도 수백만의 손실이 발생하는 수준의 기업 내 시스템은 이에 대한 대책을 철저히 할 필요가 있다. 장애 대응 방법과 수준은 다양하다. 복구 노력이라는 관점에서 큰 요인이 되는 것은 데이터가 사라졌는지에 대한 여부이다. 웹 서버나 캐시 서버처럼 자체적으로 데이터를 갖고 있지 않는 것에 대해서는 기본적으로 다시 시작하거나 증설하거나 해서 서비스를 계속 수행할 수 있으므로 장애 대응의 수고는 그리 곤란하지 않은 수준이다. 한편 필요한 데이터가 소실되는 경우도 있다.

이런 경우 일반적인 복구방법은 백업이다. 하지만 단순히 백업만으로는 다음과 같은 문제가 발생할 수 있다.

1. 최종 백업 이후에 업데이트 된 결과를 되돌릴 수 없다.

2. 백업 데이터를 다시 되돌리는 처리에도 시간이 걸리고, 그 기간 동안 다운 타임이 된다.

3. 백업 중에 섣불리 업데이트를 하면 백업이 손상될 위험이 있다.

백업을 복원하는 뿐만 아니라 백업을 만들기 위해서도 데이터의 양에 비례한 시간이 필요하다. 백업 취득 중에 업데이트가 발생하는 경우는 그 백업의 내용이 일관성이 잇는지에 대한 여부에도 신경을 쓸 필요가 있다.

이러한 무결성 관리를 제대로 하려면 트랜잭션이라는 개념을 구현할 필요가 있다. 이를 애플리케이션 로직으로 구현하려면 어려움이 있지만 데이터베이스를 사용해 이러한 무결성 관리를 담당시킬 수 있다.

괜찮은 시스템에서는 이에 더하여 동일 데이터가 있는 서버의 복제(replication)을 갖게 하는 구성을 많이 취하고 있다. 백업을 하는 경우든 복제를 하는 경우든 서비스는 멈추지 않고 실행해야 한다.

4. 병렬성 제어가 어렵다.

병렬성 제어는 많은 사람들이 동시에 액세스 하는 환경에서 필수적인 기능이다. 이를 처리하는 가장 단순한 형태는 Lock File을 사용하는 방식이다. 하지만 Lock File을 이용하는 방식은 동시에 한 명만이 갱신 액세스를 할 수 있기 때문에 실행 성능 면에서 매우 큰 제약이 생기게 된다. 그래서 다른 레코드에 동시에 업데이트할 수 있는 행 수준의 범위를 갖게 하고 싶기도 하다. 이렇게 되면 단순한 파일로서의 제어가 어렵다. 데이터베이스를 사용하면 이러한 배타 제어도 간단히 할 수 있다.

배타 제어를 실시하지 않으면 일관성이 무너져버리고, 배타 제어의 범위가 넓으면 병렬성이 떨어지고 속도 면에서 실용성이 줄어든다. 특히 최근 멀티 코어가 대두되고 있음에도 동시에 하나의 처리밖에 실행할 수 없다는 것은 한 개의 코어만을 사용해야 한다는 것이기도 하여 코어 수의 증가가 있더라도 전혀 효과가 없게 된다.

5. 데이터 무결성을 보장하는 것은 어렵다.

병렬성 제어와도 강하게 연관된 요소가 있는데 데이터 자체가 불일치를 일으키지 않게 하는 구조를 만드는 것은 매우 중요하다. ex 사용자 ID의 경우 다른 사람에 대해 동일한 ID가 생성되지 않도록 고유의 값으로 할당할 필요가 있다. 동시에 액세스가 발생했을 때 동일한 ID를 할당하지 않도록 상호 배제하는 것은 필수이며, 시스템이 멈춰서 다시 시작하는 경우에도 과거의 할당된 ID를 다시 할당하지 않도록 이력 관리가 필요하다. 이는 쉽게 보일 수 있지만 의외로 대단히 힘든 것이다. 상당수의 데이터베이스 제품은 이러한 영속성이 있는 고유 ID를 빠르게 할당하는 기술을 가지고 있다.

from http://jinukix.tistory.com/102 by ccl(A) rewrite - 2021-11-18 04:28:17