Table of Contents
아키텍처 관점에서 볼 때 데이터베이스는 엔티티가 아니다. 즉, 데이터베이스는 세부사항이라서 아키텍처의 구성요소 수준으로 끌어올릴 수 없다.
데이터베이스는 일개 소프트웨어일 뿐이며 데이터에 접근할 방법을 제공하는 유틸리티다.
아키텍처 관점에서 보면 이러한 유틸리티는 저수준의 세부사항(메커니즘)일 뿐이라서 아키텍처와는 관련이 없다.
그리고 뛰어난 아키텍트라면 저수준의 메커니즘이 시스템 아키텍처를 오염시키는 일을 용납하지 않는다.
관계형 데이터베이스
관계형 데이터베이스의 기술이 얼마나 뛰어나든, 결국은 그저 기술일 뿐이다. 그리고 이는 관계형 데이터베이스가 세부사항임을 뜻한다.
데이터를 테이블에 행 단위로 배치한다는 사실은 아키텍처적으로 볼 때 전혀 중요하지 않다.
유스케이스는 이러한 방식을 알아서는 안 되며 관여해서도 안 된다.
데이터가 테이블 구조를 가진다는 사실은 오직 아키텍처의 외부 원에 위치한 최하위 수준의 유틸리티 함수만 알아야 한다.
데이터베이스 시스템은 왜 이렇게 널리 사용되는가?
데이터베이스가 우위를 차지할 수 있던 이유는 무엇일까? 한마디로 답하자면, 바로 ‘디스크’ 때문이다.
디스크 기술이 지닌 치명적인 한 가지 특성은 바로 느리다는 특성이다.
디스크 때문에 피해갈 수 없는 시간 지연이라는 짐을 완하하기 위해, 색인, 캐시, 쿼리 계획 최적화가 필요하다. 그리고 데이터를 표현하는 일종의 표준적인 방식도 필요했다.
간단히 말해서 데이터 접근 및 관리 시스템이 필요했다.
시간이 지나면서 이러한 시스템은 뚜렷이 구분되는 두 가지 유형으로 분리되었다.
하나는 파일시스템이었고 다른 하나는 관계형 데이터베이스 관리 시스템(RDBMS)이었다.
이들 두 시스템은 데이터를 디스크에 체계화해서, 각 시스템에 특화된 방식으로 접근해야 할 때 가능한 효율적으로 데이터를 저장하고 검색할 수 있도록 한다.
각 시스템은 데이터를 색인하고 배치하는 고유한 전략을 활용한다.
덧붙여 말하자면, 데이터를 빠르게 조작할 수 있도록 결국에는 관련 있는 데이터를 RAM으로 가져온다.
디스크가 없다면 어떻게 될까?
한때는 디스크가 성행했지만, 이제는 소멸 중인 부품이다.
디스크가 모두 사라져서 모든 데이터가 RAM에 저장된다면 데이터를 어떻게 체계화할 것인가?
데이터를 테이블 구조로 만들어 SQL을 이용해 접근할 것이가?
당연히 아니다. 이 데이터들을 연결 리스트, 트리 등 여타 무수히 많은 데이터 구조로 체계화할 것이며, 데이터에 접근할 때는 포인터나 참조를 사용할 것이다.
이것이 프로그래머가 하는 일이기 때문이다.
세부사항
데이터베이스가 세부사항이라고 말하는 이유는 바로 이러한 현실 때문이다.
실제로 데이터베이스는 비트를 담는 거대한 그릇이며, 데이터를 장기적으로 저장하는 공간에 지나지 않는다.
따라서 아키텍처 관점에서 본다면 회전식 자기 디스크에 데이터가 있기만 한다면, 데이터가 어떤 형태인지는 절대로 신경 써서는 안 된다.
디스크 자체가 존재한다는 사실조차도 인식해서는 안 된다.
하지만 성능은?
데이터 저장소의 측면에서 성능은 완전히 캡슐화하여 업무 규칙과는 분리할 수 있는 관심사다.
데이터 저장소에서 데이터를 빠르게 넣고 뺄수 있어야 하는 것은 맞지만, 이는 저수준의 관심사다.
이 관심사는 저수준의 데이터 접근 메커니즘 단에서 다룰 수 있다. 성능은 시스템의 전반적인 아키텍처와는 아무런 관련이 없다.
결론
쳬계화된 데이터 구조와 데이터 모델은 아키텍처적으로 중요하다. 반면, 그저 데이터를 회전식 자기 디스크 표면에서 이리저리 옮길 뿐인 기술과 시스템은 아키텍처적으로 중요치 않다.
데이터를 테이블 구조로 만들고 SQL로만 접근하도록 하는 관계형 데이터베이스 시스템은 전자보다는 후자와 훨씬 관련이 깊다.
데이터는 중요하다.
하지만 데이터베이스는 세부사항이다.