SPRINT2.1버젼 MongoDB 스키마, FlowChart시각화 및 분석

[LDEV4966]

SPRINT2 회의 기반으로 MongoDB 스키마 구성과 FlowChart 시각화

Task 번호 : #70

• MongoDB 스키마

• FlowChar

• 분석 내용 :

현재 DB 스키마를 분석하면서 생각한 점을 말해보겠다.

1. Mongo의 도큐먼트 구조는 크게 2가지가 있다. 임베디드(Embedded) 방식, 레퍼런스(References) 방식으로 나누어 진다. 현재 프로젝트 스키마를 보면 project 컬렉션 아래 project 도큐먼트의 필드값으로 metadata_list를 가지는 전형적인 임베디드(Embedded) 방식이다.
   그래서 임베디드(Embedded) 방식의 특징을 살펴보면, 임베디드(Embedded) 방식은 반정 규화 모델로서 데이터의 정합성 문제에 민감하다. 즉, 지금과 같은 구조로는 한 환자의 metadata가 여러 프로젝트에 존재할때 특정 project에서만 metadata의 수정이 있을 시 전체 DB에서 정합성이 깨지는 문제가 발생 할 수 있다.

2. 도큐먼트의 최대 크기는 16 MByte이며 최대 크기 이하로 도큐먼트를 관리해야 한다. 그런데 지금과 같은 구조는 metatdata를 한 project document 내에서 처리하기에 metatdata_list의 양이 늘어나 도큐먼트의 최대 크기를 넘어버리는 경우가 발생 할 수 있다.

3. 반면 좋은 점으로는 임베디드(Embedded) 방식은 레퍼런스(References) 방식과 달리 참조를 통해 접근하지 않기에 조회 시 성능이 비교적 좋다.

문제점을 정리하자면,

1. 한 환자의 metadata가 project마다 존재할때, 수정시 데이터의 정합성에 문제가 생긴다.
2. 현재 스키마 구조는 임베디드(Embedded) 방식으로 구성되며 도큐먼트에 포함하는 데이터가 증가할수록 도큐먼트의 크기도 증가하여 디스크 I/O (수정,삭제)시 성능 저하 발생 및 도큐먼트의 최대 크기를 초과 시 저장이 불가능할 수 있음

• 해결방안에 대한 생각 :

1번 문제)
환자의 metadata를 project 별로 관리 하는 것이 아니라, patient collection에서 관리하고 project에서는 patient_id로 patient에 저장된 metadata를 참조하는 방식으로 바꾼다면 문제 해결 가능 할 것이라 생각 됨. 그런데 참조 방식으로 인해 조회 성능 저하 발생 예상됨.

2번 문제)
1번문제 해결방안에서 제시했듯이 메타데이터를 환자 컬렉션에서 관리하면 환자 아이디만 metadata_list에 저장되기에 도큐먼트 최대 용량은 안넘을 것이라 생각되긴 하지만 혹시 걱정되면 metadata_list를 정규화(분리) 시켜 줄 필요가 있다고 생각함

[Jungwon-Lee]

@leeseungmin4966 임베디드 방식과 레퍼런스 방식의 성능차이가 많이 심한가요?

수정하는 기능이 추가되려면 레퍼런스 방식이 관리가 더 쉽긴하겠네
+) 메타데이터 수정하는 일이 그렇게 자주 일어나지는 않을 것 같은데, 자주 일어나지 않으면 기존의 방식으로 해도 문제 없지않을까

[BEOKS]

현재 DB 스키마를 분석하면서 생각한 점을 말해보겠다.

Content & Problem

1. Mongo의 도큐먼트 구조는 크게 2가지가 있다. 임베디드(Embedded) 방식, 레퍼런스(References) 방식으로 나누어 진다. 현재 프로젝트 스키마를 보면 project 컬렉션 아래 project 도큐먼트의 필드값으로 metadata_list를 가지는 전형적인 임베디드(Embedded) 방식이다.
   그래서 임베디드(Embedded) 방식의 특징을 살펴보면, 임베디드(Embedded) 방식은 반정 규화 모델로서 데이터의 정합성 문제에 민감하다. 즉, 지금과 같은 구조로는 한 환자의 metadata가 여러 프로젝트에 존재할때 특정 project에서만 metadata의 수정이 있을 시 전체 DB에서 정합성이 깨지는 문제가 발생 할 수 있다..

1. 한 환자의 metadata가 project마다 존재할때, 수정시 데이터의 정합성에 문제가 생긴다.

Answer

아래 그림처럼 메타데이터와 프로젝트는 일대일 대응 관계이므로 하나의 동일한 메타데이터가 여러 프로젝트에 존재할 수 없다.
단, 같은 PatientID(ex.'1234567')가 여러 프로젝트에 존재 할 수 있는데, 이건 허용한다. 허용하면 발생하는 문제로, 한 프로젝트에서 1234567의 Dicom 파일을 삭제하면 다른 프로젝트에도 영향을 미칠 수 있는데 이는 현재 유저의 책임으로 정의하고 따로 다루지 않는다. (필요시 추후, 추가 예정)

Content & Problem

도큐먼트의 최대 크기는 16 MByte이며 최대 크기 이하로 도큐먼트를 관리해야 한다. 그런데 지금과 같은 구조는 metatdata를 한 project document 내에서 처리하기에 metatdata_list의 양이 늘어나 도큐먼트의 최대 크기를 넘어버리는 경우가 발생 할 수 있다.

2. 현재 스키마 구조는 임베디드(Embedded) 방식으로 구성되며 도큐먼트에 포함하는 데이터가 증가할수록 도큐먼트의 크기도 증가하여 디스크 I/O (수정,삭제)시 성능 저하 발생 및 도큐먼트의 최대 크기를 초과 시 저장이 불가능할 수 있음

Answer

이를 해결하기 위해선, 위에서 언급한 아래 그림처럼 저장하도록 수정해야 할 것 같다. 이를 위해선 API를 변경해야 하는데 예를 들어, POST : /MetaData API는 POST : /MetaData/{:ProjectID}식으로 수정해야 한다.