MariaDB에서 PostgreSQL로 데이터를 마이그레이션 하는 이유
1. 기존 서비스에서 사용하던 데이터를 재활용 할 수 없는 상황
기존 서비스를 단기간에 화면을 만들기 위해 이전 개발자가 워드프레스로 서비스를 개발 해두웠는데 업데이트가 불가능 할정도의 많은 플러그인들 설치해두었고
개발자라면 조금만 들여다보면 보이는 각종 취약점들을 수정 조차 할 수 없는 상황이여 불가피하게 처음부터 다시 만드는 고도화 작업이 필요했습니다.
백엔드는 Node.js/NestJS로 프론트는 ReactJS로 만들면 되었지만 워드프레스의 데이터 저장 방식이 문제가 되었습니다.
워드프레스 만의 규칙으로 만들어진 데이터들을 그대로 재사용 하는 방법을 사용하면 개발 기간을 단축 할 수 있겠지만 어떠한 Table에도 index가 걸려 있지 않아 많은 데이터를 불러와야 하는 페이지들은 엄청난 로딩시간 (10초에서 20초)을 불러왔고 이는 사용자의 입상에서 최악의 상황이죠
2. 어떤 DB를 사용할 것인가?
우선 고도화를 진행할 서비스는 음악 B2C 판매 플렛폼으로 다루는 데이터는 크게 3가지로 구분했습니다.
- 유저 정보
- 작곡가 정보
- 음악 정보
음악 테이블과 다른 테이블간 복잡한 관계의 설계가 진행되었습니다.
음악의 다양한 정의는 다양한 종류의 태그를 지원해야됬고 클라이언트의 요청에 듣기 전용 음악과 다운로드 음악을 분리 하길 원했습니다.
또한 주간 인기곡 TOP 20과 유사곡 추천 기능을 추가해야됐습니다.
기업에서 곡을 제공하는 형태가 되어야 됐기에 작곡가의 정보는 노출 되지 않지만 어떤 작곡가의 곡인지 정산을 위해 데이터를 수집해야 되어 음악 테이블 조회에 많은 최적화가 필요했습니다.
핵심 구현 기능
- 제목 검색
- 태그 검색
- 유사곡 추천
- TOP 20
- 앨범
- 음악 감상 플레이어
무슨 DB가 잘 어울릴까?
중요 기능을 나열 하고 어떤 DB가 가장 어울릴지 팀원들과 많은 회의 끝에 다음과 같은 추천 목록이 만들어졌습니다.
- PostgreSQL
- MySQL
- MongoDB
| 데이터베이스 | 특징 | 장점 | 단점 | 어울리는 상황 |
|---|---|---|---|---|
| PostgreSQL | 관계형 데이터베이스 (RDBMS), SQL 사용, 엄격한 스키마, 수평 및 수직 확장 가능, ACID 준수, 고도화된 트랜잭션 관리 (MVCC 지원), 다양한 데이터 타입 지원 | 고성능 트랜잭션 처리, 확장 가능한 아키텍처, 다양한 데이터 타입 지원, 고급 보안 기능, 활발한 커뮤니티 | 설정 및 튜닝 복잡, 높은 학습 곡선, 리소스 소모 가능성 | 금융 및 은행 시스템, 데이터 분석 및 비즈니스 인텔리전스, 복잡한 쿼리 및 높은 데이터 무결성 요구 시스템, GIS |
| MySQL | 관계형 데이터베이스 (RDBMS), SQL 사용, 유연한 스키마, 수평 및 수직 확장 가능, 대부분의 경우 ACID 준수, 기본적인 트랜잭션 지원 | 설치 및 설정 간편, 빠른 읽기 성능, 널리 사용되어 자료 및 도구 지원 많음, 큰 커뮤니티 지원 | 복잡한 트랜잭션 처리 성능 제한, 기능 제한 가능성, 완전한 ACID 준수 필요 시 한계 | 웹 애플리케이션, 전자상거래, 읽기 작업이 많은 애플리케이션, 간단한 트랜잭션 처리 시스템 |
| MongoDB | 비관계형 데이터베이스 (NoSQL, 도큐먼트 지향), BSON 사용, 스키마 없음, 수평 확장 유리, 부분적 ACID 준수, 단일 도큐먼트 내 트랜잭션 지원 | 유연한 스키마, 대규모 데이터 처리 용이, 수평 확장 용이, 활발한 커뮤니티 | 복잡한 쿼리 작성 어려움, 스키마 설계 어려움, 트랜잭션 기능 제한 | 빅데이터 분석, 콘텐츠 관리 시스템, 실시간 데이터 처리 및 저장, 분산 데이터베이스 시스템 |
빠른 읽기 성능 하나만으로 MySQL을 채택 했을 경우를 가정하고 코드를 조금 작성 하였을 때 태그 항목의 큰 묶음으로 카테고리, 장르, 분위기로 구별해 놓은 항목을 제 정렬하는데 복잡한 로직이 만들어졌고 재활용 가능한 코드를 작성한는데 있어 장애물이 되어 채택되지 못 하였고
MongoDB의 경우 Json 상태로 문서 저장을 할 수 있다는것에 큰 장점으로 보여졌으나 검색과 가장큰 난관인 유료 서비스인 점이 단점으로 채택 되지 못 하여 PostgreSQL으로 채택 되었습니다.
3. 마이크레이션 할 데이터 정리
다행인지 불행인지 모르겠지만 어드민 페이지에서 각종 곡 정보를 보기 어려워 엑셀 시트에 모든 곡의 정보를 업데이트를 해두어 이후 진행은 일사천리로 진행됐습니다.
xlsx를 사용해 엑셀을 읽어 json 형태로 불러와 typeORM으로 데이터베이스에 입력하는 작업을 거쳐 사람이 직접 적어 옮기는 작업을 생략하여 작업시간을 아꼈습니다.
아래는 xlsx사용의 간단 예시입니다.
const XLSX = require('xlsx');
// 엑셀 파일 경로
const filePath = './example.xlsx';
// 파일을 불러오기
const workbook = XLSX.readFile(filePath);
// 첫 번째 워크시트의 이름을 가져오기
const sheetName = workbook.SheetNames[0];
// 첫 번째 워크시트를 가져오기
const sheet = workbook.Sheets[sheetName];
// 워크시트의 데이터를 JSON 형태로 변환
const data = XLSX.utils.sheet_to_json(sheet);
// 데이터 콘솔에 출력
console.log(data);
곡을 제외한 다른 테이블의 경우 기존과 전혀 다른 형태로 테이블 재설계를 해 재사용해야 될 데이터와 사용하지 않게 된 데이터를 분류하는 불가피한 추가 작업을 하였습니다.
기존 DB의 데이터를 백업하고 필요한 데이터를 읽어 새로운 DB로 옮기는 작업을 했습니다. (코드를 보여주고 싶었으나.. 퇴사하여 없습니다...)
끝, 작업 후기
데이터를 수작업으로 옮겼다면 많은 작업 시간을 소요했어야 될 작업이라는것을 알았습니다.
데이터를 저장할 서비스를 고도화 하거나 DB를 변경해야 할 때 재사용 할 수 있도록 설계해야 한다는 것을 알았습니다.
그리고 DB를 변경할 일이 없도록 최초 설계시 시간이 조금 더 걸리더라도 클라이언트에게 요구사항과 이후 추가될 수도 있는 요구사항을 파악해 설계해야 나중에 탈이 없다는 것도 알았습니다.
2주간 작업이 이루어졌는데 가장 큰 난관은 워드프레스의 플러그인들이 서로 데이터를 취급하는 형태가 모두 달랐고 필요한것 처럼 만들어진 더미 데이터를 판별하는 작업이 가낭 오래걸렸습니다.
중요한 데이터가 아니라면 백업 후 삭제 하는것이 이후 개발자들에게 이롭다는것을 배우는 시간이 되었네요.