표준화되지 않은 엑셀 데이터를 데이터베이스에 저장하는 방식에 대한 고찰

💡이 글은 회사의 신규 프로젝트 설계 과정에서 생긴 이슈에 대한 의사 결정 과정을 정리한 것이다.


요구사항
 여러 단체로부터 회원 명단이 적혀있는 엑셀 데이터를 업로드받고 해당 엑셀 데이터를 기반으로 기본적인 관리 페이지(회원 명단 중 서비스에 가입한 회원에 대한 통계 등)를 제공해야 한다. 


필수 조건
 엑셀 데이터에 어떤 컬럼이 들어가는지는 알 수 없고 정해져 있지도 않지만 반드시 회원의 이름과 휴대전화 번호는 들어가야 한다.


정리
 기획 단계에서 여러 이야기가 오고 갔는데 결론적으로 사용자들의 서비스 경험을 향상시키기 위해 엑셀 데이터의 양식을 표준화하지 않기로 결정했다. 따라서 단체별로 양식이 다른 엑셀 데이터를 업로드받고 그대로 파싱 하여 데이터베이스에 저장해야 한다.

 엑셀 데이터의 양식을 표준화하지 않으면 데이터베이스의 스키마를 미리 정의할 수 없는 문제가 발생한다. 따라서 관계형 데이터베이스를 사용할 때의 장점인 인덱싱이나 쿼리 등의 사용이 제한적이게 될 수 밖에 없다. 이 문제를 고려하기 전에도 데이터를 어떻게 저장할 것인가에 대한 근본적인 문제를 생각하지 않을 수 없다.

 팀원들과 이야기하고 구글링, chatGPT 등을 사용하여 고려한 해결 방법은 크게 네 가지가 있었다. 해결 방법에 대해 생각해보면서 최종적으로 어떤 데이터베이스를 선택지에 두고 고민하게 되었는지까지 정리해 보겠다.

 

문제 요약 

1. 표준화되지 않은 여러 양식의 엑셀 데이터를 데이터베이스에 저장해야 한다.
2. 회원 명단이 들어있는 엑셀 데이터이기 때문에 기본적으로 회원의 이름과 휴대전화는 들어있어야 한다. 이름과 휴대전화를 이용하여 해당 회원이 서비스에 가입을 했는지 체크할 것이기 때문이다.

 

방법 1) EAV 모델로 저장

EAV 모델에 대한 블로깅은 이 링크를 클릭하면 된다.

장점 

• 다양한 유형의 속성을 저장하는 방식임으로 유연성이 좋다.(단순 저장만 고려하면 JSON 형식에 비해 좋다.)
• 데이터베이스 수준에서 데이터 검증 및 무결성을 보장하기가 JSON 형태로 저장하는 것보다는 낫다.(별 의미는 없다)

단점 

• 복잡한 쿼리를 작성해야 하며 인덱싱 등에서 성능 문제가 발생할 가능성이 높다.
  • 끔찍한 조회 쿼리가 예상된다...

 

방법 2) JSON 형태의 컬럼을 사용하여 저장

장점 

• 간결한 데이터 구조를 제공하면서 유연성을 유지한다.
  • 특정 컬럼에 JSON 형식으로 다 때려박으면 되기 때문.
• EAV와 비교하여 비교적 간결한 쿼리로 데이터를 조회하거나 필터링할 수 있다.(읽기 성능이 좋음)
• 기관마다 서로 다른 컬럼을 한 데 모아 하나의 열에 JSON 형태로 저장하고 필수 데이터(이름, 전화번호) 등을 따로 컬럼으로 빼내서 저장하여 데이터 구조를 관리한다면 EAV 모델과 비교했을 때의 동적 속성 저장에 대한 단점을 어느 정도 보완하는 것도 가능하다. → 하이브리드 형식

단점 

• 데이터 검증과 무결성을 데이터베이스 수준에서 처리가 불가능하다.(하이브리드 형식은 일부 가능)
• JSON 데이터의 검증은 애플리케이션에서 수행해야 한다.(검증을 위한 추가 코드를 작성해야 한다.)

 

방법 3) 기관별로 테이블을 생성, 각 테이블에서 엑셀의 컬럼명과 구조에 맞게 데이터 저장

장점

• 기관별 정확한 데이터 검증 및 무결성 문제 방지 가능
• 데이터 구조를 기관에 맞게 유지함으로써 정확하고 빠른 데이터 관리 가능

결론 → 포기

• 우선 기관마다 어떤 구조를 가지고 있는지 모르는 상태에서 파싱을 통해 데이터를 파악해야 함.
• 상용이 된다면 수많은 클럽이 생성될 예정이므로 클럽마다 테이블을 만드는 것은 비현실적임.

 

 

방법 4) NoSQL 데이터베이스 사용

NoSQL을 선택할 경우 장단점(RDBMS와 비교하여)

장점 

• 유연한 데이터 모델
  • 다양한 데이터 유형 및 동적인 스키마를 더 쉽게 관리할 수 있다.
  • 테이블 구조 변경이 발생해도 쉽게 대처할 수 있다.
• 확장성
  • 일반적으로 수평적 확장이 용이하여 데이터가 늘어날 때 더 쉽게 관리할 수 있다.
• 성능 향상
  • 일반적으로 읽기 및 쓰기와 같은 작업에 높은 성능을 제공한다.

단점 

• 일관성 및 트랜잭션
  • 대부분의 NoSQL 데이터베이스는 RDBMS와 비교하여 데이터의 일관성과 트랜잭션 처리에 한계를 가지고 있기 때문에 복잡한 트랜잭션 처리가 필요한 경우 RDBMS를 사용해야 한다.
• 분산 데이터 관리
  • 일부 NoSQL 데이터베이스는 데이터의 유실 및 복제 지연 등 분산 데이터 관리에 관한 문제가 발생할 수 있다.
• 표준화 부재
  • 쿼리 작성이나 관리도구에 다양성이 있어 학습이 필요하다.

 

1차 결론

• 관리자 웹 페이지를 통해 엑셀 데이터에 대한 정보 제공 기능이 있으므로 조회 쿼리의 사용이 어느 정도 있을 것 같다.
  • 최악의 조회 성능을 보이는 EAV 모델보다는 JSON 형태로 저장하는 방식을 사용하는 게 합리적으로 보인다.
• 그럼 RDBMS와 NoSQL 데이터베이스 중 어떤 것을 선택해야 할 것인가?
  • 이 부분에 대해서는 일단은 데이터베이스 모델을 두고 선택을 고민하는 것이 맞는 것 같아 3 가지 데이터베이스를 두고 고민하게 되었다.

 

MySQL VS PostgreSQL VS MongoDB

MySQL

장점

• 현재 회사에서 메인으로 사용한다.(팀원 모두 익숙함)
• 가장 널리 사용되는 데이터베이스로 커뮤니티가 활성화되어 있고 뛰어난 도구 및 라이브러리가 있다.(정보 찾기 쉬움)
• 개발자 친화적이라 사용 방법이 매우 쉽다.
• 읽기 작업이 많을 때 높은 성능을 제공한다.

단점

• MySQL은 5.7 버전 이상부터 JSON 데이터 타입을 지원하며 JSON 관련 기능이 PosrgreSQL보다 제한적이다.
• 확장성이 제한적이라 큰 규모의 대다수의 읽기 및 쓰기 서버가 필요한 경우 MySQL은 수평 확장이 어렵다.

 

PostgreSQL

장점

• 사용자 정의 함수, 저장 프로시저, 트리거 등 다양한 고급 기능을 제공한다.
• JSON 및 JSONB 데이터 타입을 지원하고 JSON에 대한 강력한 쿼리 및 인덱싱 기능을 제공하여 복잡한 데이터 관리가 용이하다.
• 완벽한 ACID 지원으로 복잡한 트랜잭션 처리 및 데이터의 무결성을 보장한다.

단점

• 간혹 읽기 중심 작업에서 MySQL보다 느린 성능을 보일 수 있다.

 

MongoDB

장점

• Document 지향의 NoSQL 데이터베이스로 JSON 형태의 데이터를 손쉽게 저장하고 관리할 수 있다.
• 수평 확장 및 병렬처리가 뛰어나 대규모 데이터를 처리하는데 용이하다.
• JSON 형태의 데이터 저장 및 쿼리로 개발자가 적응하기 상대적으로 쉽다.

단점

• NoSQL 특성상 트랜잭션 처리에 제약이 있다.
• RDBMS만큼의 데이터 무결성 및 일관성을 제공하지 않는다.

 

2차 결론

• MySQL은 팀원 모두가 익숙하다는 장점 말고는 JSON 데이터를 다루기에 그리 적합해 보이지는 않는다. 간결한 구조와 익숙한 조작법 등을 장점으로 꼽을 수 있겠다. 물론 최선 버전의 MySQL이 어떨지는 잘 모르겠다. PostgreSQL과 별 차이가 없을 수도?
• 트랜잭션 처리, 데이터 검증, 무결성 보장 등을 고려하면 하이브리드 형식으로 PostgreSQL을 이용하는 것이 좋을 것 같다. 만약 나중에 관리 페이지의 기능이 확장되어 보다 복잡한 통계 결과 등을 제공한다거나 할 때에는 PosrgreSQL이 가장 좋을 것 같다. 데이터 처리에 강력하기 때문이다.
• 단순히 JSON 형태로 저장하여 관리하는 데에만 집중한다면 MongoDB 쪽이 좋은 선택일 수 있다. 생각해 보면 회원 명단에서의 잘못된 데이터 입력 등의 문제는 해당 단체의 문제이기 때문에 서비스에서 해줄 수 있는 것이 많지 않을 것 같다. 또한 테이블의 변경에 매우 자유롭다. 다양한 인덱싱과 쿼리 옵션을 제공하기 때문에 데이터 조회도 크게 단점이 아닐 수도 있다.
• 개인적으로는 이번 기회에 NoSQL 데이터베이스를 써보고 싶은 마음이 있기 때문에 MongoDB 쪽이 끌리긴 한다.(그냥 희망사항)
• 아직 완전히 설계가 끝난 것은 아니기 때문에 최종적으로 결정이 되면 글을 업데이트할 예정이다.

 

(추가) 8월 19일 업데이트

이후에 진행 사항은 이 링크를 통해 확인할 수 있다.

 

 

 

참고

chatGPT

뤼튼