[클린아키텍처|요약정리] 30장 데이터베이스는 세부사항이다.

30장 데이터베이스는 세부사항이다

소프트웨어 시스템 아키텍처 : 데이터베이스 = 건물 아키텍처 : 문 손잡이

소프트웨어 시스템의 아키텍처와 데이터베이스의 관계는 건물 아키텍처와 문 손잡이 정도이다. 아키텍처 관점에서 데이터베이스는 엔티티가 아닌 세부사항이며, 데이터에 접근할 방법을 제공하는 유틸리티(=소프트웨어) 일 뿐인 것이다.

(엔티티 : 애플리케이션의 핵심적인 Business Rule을 담고 있는 객체로서 메서드/데이터 구조/함수 집합일 수 있다)

 

관계형 데이터베이스

Magnetic Disk

디스크에서 1바이트 읽기 위해서는 Heads를 적절한 Track으로 옮기고 Sector가 돌아올 때 까지 기다린 후, 해당 섹터에서 4K를 모두 RAM으로 읽어 들여야 한다. 그리고 RAM 버퍼의 색인을 찾아서 필요한 바이트를 가져온다. 이 과정은 밀리초 단위의 시간이 걸린다. → 오래 걸리는 거임.

 

그래서 이러한 지연 시간을 완화하기 위해 색인/캐시/쿼리 최적화를 할 수 있는 접근 및 관리 시스템 필요해진 것이다. 그리고 시간이 지나며 뚜렷하게 구분되는 2가지의 유형(파일 시스템과 데이터베이스 시스템)으로 분리되었다. 이 두 시스템은 데이터를 디스크에 체계화해서 효율적으로 데이터를 저장/검색하게 한다.

 

파일 시스템 : 문서 기반, 이름 기준 검색/저장 👍  , 내용 기준 👎 데이터베이스 시스템(DBMS) : 내용기반, RDBMS : 정형화된 문서 👍  , Document-oriented DB : 비정형 문서 👍

 

디스크는 RAM으로 대체되고 있고 시간이 지나며 디스크는 플로피 디스크, CD처럼 소멸될 것이다. 하지만 디스크가 모두 사라지고, 모든 데이터가 RAM에만 저장된다면 데이터를 어떻게 체계화할 것인가? 이미 우리는 파일 시스템, RDBMS 뿐만 아니라, 연결 리스트, 트리, 해시 테이블, 스택, 큐 등의 데이터 구조와 포인터나 reference를 사용하여 데이터 구조를 변경하여 사용 중이다.

 

이처럼 데이터베이스가 세부사항인 이유는 시간이 지나며 데이터에 접근하는 방식들은 변화하게 되기에 그저 데이터에 접근하는 메커니즘에 불과하기 때문이다. 그래서 아키텍처의 관점에서는 데이터가 어떤 데이터의 형태인지, 더해 디스크의 존재 자체도 인식해서는 안된다.

 

성능은?

아키텍트 관점에서 성능은 저수준의 관심사

 

결론

체계화된 데이터 구조와 데이터 모델은 아키텍처적으로  중요하다.

데이터는 중요하다. 하지만 데이터베이스의 종류는 세부사항이다.