실무에서 DB를 샤딩할 때 주로 어떤 DB를 사용하나요?

Question

DB를 스케일링 할 때, DB에 저장된 데이터의 개수가 매우 많아지면 단순 레플리카를 만드는 수준으로는 감당이 안되기에, DB를 샤딩해야하는 것으로 알고 있습니다.그래서 샤딩을 하는 방식에 대해 여러모로 찾아보았는데 MongoDB같은 NoSQL형 DB는 DB 수준에서 샤딩을 지원하는 경우가 많은 반면 MySQL같은 관계형 DB는 DB 수준에서 샤딩을 지원하지 않기에 어플리케이션 레벨에서 샤딩을 직접 구현해야한다고 들었습니다.즉 샤딩을 위해선 샤딩을 지원하는 NoSQL을 선택하던가, 그게 아니면 MySQL 같은 관계형 DB의 샤딩을 직접 구현하던가 둘 중 하나인 것인데, 그렇다면 실무에선 어떤 방식으로 샤딩을 구현하는지가 궁금합니다.처음엔 단순히 &#34;테이블간의 관계가 중요한 도메인에선 관계형 DB에 직접 샤딩을 구현하지 않을까?&#34;하고 생각했으나, 사실 데이터를 샤딩하는 순간부터 테이블간의 관계를 처리하는 게 상당히 어렵지 않을까 하는 생각이 들어서 그러면 차라리 애초부터 MongoDB같은 NoSQL을 선택하는게 낫지 않나하는 생각도 들고... 여러가지 생각이 듭니다만 실제로 기업에서 어떤방식으로 샤딩을 하는지 알 수가 없으니 답을 내릴수가 없네요.관련 내용에 대한 지식이나 경험을 갖고 계신분이 계신다면 답변 부탁드리겠습니다.

DEVVY2 · Answer

Youtube의 경우 MySQL sharding 솔루션으로 Vitess(자체 개발 open source)를 활용하고 있습니다. MySQL의 NDB cluster도 확인해보시면 좋을 것 같아요

우주로가고 · Answer

이런 문제로 많은 스타트업들이 몽고DB를 사용합니다.돈 인력 있으면 모든게 가능한데, 스타트업이 샤딩 솔루션 비용과 운영 비용을 감당을 못 합니다.많은 고객의 트래픽을 핸들링 하는 서비스가 아니면 필요 없기도 하고요.그나마 설계로 풀어보자면 microservice를 구축하는 방법도 있습니다.예를들면 order service는 서버와 디비를 완전 하나의 소규모 서비스로 분리 시켜버리는 겁니다.그러면 여기서 이미 어느정도 디비 부하가 쪼개집니다.한국이면 사는 지역별로 디비를 쪼개서 관리해도 됩니다.microservice-order-seoul, microservice-order-busan처럼요.그런데 이런 복잡한 설계 필요없이 몽고디비는 키 하나만 박아 넣으면 끝난다는게..스타트업 서비스들은 일부는 서버부하는 강하게 버텨내는데 DB부하에서 막혀서 서비스가 느려지는 경우가 아주 많아요.서버 부하는 솔직히 최초 설계 상관없이 손쉽게 '돈'만 지출하면 분산이 되는데 디비로 들어오는 부하는 설계적인 완성도가필요한 영역이라..어느 회사가 어떻게 구현하냐는 정말 말 그대로 천차만별입니다.

실무에서 DB를 샤딩할 때 주로 어떤 DB를 사용하나요?

2개의 답변

Q&A 목록