DB 전문가가 이야기 하는 DBMS선택 방법..

듣기 버전 : https://youtu.be/gee37PXME2E?si=F3hsUPq9ptJ-Uidz

DB 전문가가 이야기 하는 DBMS선택 방법.. 

많은 개발자 분들이 DBMS선택 방법에 대해서 동영상을 올려드리는데, 

DBMS엔진에 대해 정확하게 알지 못하는 상태에서 개략적인 정보만으로 올리시는 분들이 많은 것 같아서 오히려 DBMS를 선택하는데까지의 충분한 도움이 안되는 것 같아서 DB전문가가 DB를 선택하는 방법을 알려드리겠습니다. 

만약 DB전문가라는 사람이 당연히 오라클이죠.. 라던가 MySQL만큼 좋은게 없어요 라던가 하나만 밀고 있는 사람이라면 그 사람은 DB전문가가 아니라 그 제품 하나만 알고 있는 평범한 사람이라고 보시면 됩니다. 

다양한 RDBMS의 특징을 모르면 뭐가 왜 좋은지 알 수 없잖아요.. 그리고 상황 및 데이터 타입 등등 다양한 환경에 따라 달라지는데 하나만 최고가 될 수가 있나요? 

제가 있던 시절의 RDBMS는 DBase(HBase아님), Cybase, Infomix등등 다양한 RDBMS가 판치던 시절이었습니다. 

이 때에는 Index 알고리즘도 B-Tree index뿐만 아니라 Bitmap index도 있었지요. 

Bitmap index는 Cardinality가 낮은 데이터, 즉 1 이나 0 처럼 종류가 적을 수록 속도가 빠른 인덱스도 있었으나, 

대부분의 데이터가 Cardinality가 높은 경우가 많아져 SQL Server도 6.5부터는 B-Tree index를 사용하게 되었지요. 

그래서 MySQL, SQL Server, ORACLE등의 메이저 RDBMS의 엔진 성능도 엇비슷해 진 듯이 보입니다.. 

많은 곳에서 MySQL이 최고라면서 증거를 들이밀고, SQL서버가 최고라면서 데이터를 들이미는 곳이 있는가 하면 ORACLE이 최고라면서 발표하기도 합니다. 

다들 거짓말을 하는 걸까요? 

아닙니다!

그들이 하는 말은 맞지만, 

가장 중요한 것은, 

자기네 제품이 가장 좋은 환경을 만들어서 발표한다는 것이지요. 

그래서 DB전문가가 제대로 이야기를 해주려고 합니다. 

MySQL은 2GB이하의 데이터 내에서 Random Access가 모든 RDBMS 중에서 가장 빠릅니다!

많은 데이터는 2GB이하의 경우가 많고, 순차 읽기보다는 랜덤읽기가 많기 때문에 작은 사이즈의 데이터를 다룬다 하면 MySQL을 능가할 수가 없지요.. 엔진이 가볍기 때문에 양이 적을 때는 최적입니다. 

혹자는 100GB에서도 잘만 돌아가! 라고 하시는데요.. 

제 고객 중에 2TB를 MySQL로 돌리시는 분도 계셨습니다. 제가 말씀 드리는 것은 2GB를 넘으면 못한다가 아니고 HW성능대비 효율이 안나온다는 것이지요. 2TB를 돌리시는 고객은 512GB메모리에 최고 스펙의 머신으로 커버하고 있었으니까요.. 

MySQL은 고용량으로 갈 수록 타 RDBMS대비 리소스 비용이 급격하게 늘어나는 단점을 가집니다 .

SQL Server, 한국에서는 MS SQL이라고 많이 하는데 대부분의 해외에서는 sql server가 정식 명칭이라고 하더라구요.. 

sql server는 동일 성능의 서버에 모든 RDBMS를 설치해서 비교한 결과 1Transaction당 Cost가 가장 저렴했다고 합니다. 

sql server는 MySQL과는 달리 라이선스 비용이 듬에도 불구하고 일정 이상의 데이터를 처리하는 경우는 MySQL이 HW에 비용을 써야 성능 저하를 막지만, SQL Server의 경우는 동일한 스펙에서도 고성능을 낼 수 있기 때문에 라이선스 비용을 포함해서도 1Trn 당의 비용이 줄어 들어 가장 적은 코스트의 처리가 가능한 RDBMS입니다. 

보통 2GB에서 2TB이내에는 적합한 RDBMS입니다. 

ORACLE은 64코어 탑재 HW에서 가장 성능이 좋습니다. 

일단. 64Core로 HW를 올리면 다른 모든 RDBMS는 최대 사용코어를 넘어섭니다. 

하지만 ORACLE은 64코어에서도 병렬 연산이 가능하지요. 즉, 엔진 자체가 무거워 저 코어에서는 느리기 때문에 다른 RDBMS가 지원하지 않는 64코어에서만 비교를 한 것이지요.. 

그럼 ORACLE이 제일 안좋으냐? 

그건 아니지요. 대규모 시스템을 사용한다면 그만큼 많은 성능이 필요하지만, 오라클은 그걸 코어 수로 얼마든지 커버할 수 있기 때문에 고성능을 위해서라면 돈은 얼마든지 상관 없다면 ORACLE을 쓰게 되는 것이지요. 

데이터양이 늘어나고 데이터의 관계성이 복잡해짐에 따라 다른 RDBMS는 퍼포먼스 저하를 보이지만, 오라클은 어느 정도까지 데이터가 늘어도 퍼포먼스 저하가 크지 않기 때문에 대규모 데이터 처리에서는 오히려 성능이 좋게 나옵니다.

그 동안 이런 식으로까지 비교한 사람들이 없었죠?

더 재밌는 것을 말씀해드려야지요?

MySQL은 4000TPS부터는 급격하게 성능이 저하됩니다. 그걸 막기 위해서는 다른 RDBMS에 비해서 많은 HW리소스를 요구하지요. 

PostgreSQL은 MySQL과 많이 비교하지요? MySQL이 올라간 서버에 WAS나 AS등이 올라가면 성능이 좋지만, 

대부분의 시스템이 WAS와 RDBMS는 분리하잖아요? 이렇게 분리된 구성에서는 PostgreSQL이 MySQL보다 다섯배 빨라집니다. 

즉, MySQL는 네트워크로 나가서 다른 서버랑 통신을 위한 handshaking 및 connector의 성능이 많이 떨어진다는 이야기 입니다. 

SQL Server는 6000TPS에서부터 성능이 천천히 떨어집니다. 

그리고 ORACLE은 12000TPS까지도 성능에 문제가 없습니다. 그 위로 올리면 엔진 성능 저하보다는 OS에서 커넥션 한계를 넘겨서 못받기도 하기 때문에 설정을 민감하게 조절해주셔야 합니다. 

처리 성능 이외에도 여러가지 특장점들이 있지요.. 

MySQL은 이젠 MyISM은 안쓰고 INNODB를 사용하잖아요? 그럼으로서 데이터의 file IO성능이 비약적으로 발전을 하긴 했는데요, 역시 가장 성능이슈가 나는 곳이 파일IO이기 때문에 용량이 늘어난다면 가급적 테이블 단위로 파일을 나누거나 파일이 너무 커지면 샤딩등으로 파일을 나누어 주는 것을 추천합니다. 파일 사이즈는 요즘은 어떨지 모르겠지만 예전까지는 OS의 File system의 성능 때문에 테이블당 2GB미만으로 주로 놓는 편이었지요. 이렇게 잘만 파일을 쪼개 놓는다면 꽤 큰 용량까지 커버가 가능해 집니다. 

SQL Server는 테이블, DB등의 파일을 쉽게 분산할 수 있는 설정이 있기 때문에 운영중에 Disk IO패턴에 따라서 조절이 그때그때 가능합니다. 게다가 메뉴에서 Shrinking 도 가능한데요, 요즘은 제가 Azure SQL을 사용하다보니 아주 저렴하게 그리고 Shrinking 신경도 안쓰고 운영을 하고 있긴 합니다. Azure SQL의 경우 용량 및 DTU당 과금이다보니 하드웨어 리소스 포함 월 3만원 정도부터 사용할 수 있어서 경제적이네요.. 게다가 Auto Tuning을 사용하면 SQL패턴에 따른 인덱스 생성 및 삭제를 멋대로 해주기 때문에 튜닝을 신경 안써도 됩니다. 

튜닝하면서 맨날 하는 얘기인데요, 

똑같은 게시판이라고 해도 데이터가 쌓이는 패턴에 따라 튜닝 방법이 달라집니다. 

한국의 경우는 자기가 잘났기 때문에 댓글보다 답변이 많이 달리는 경우도 많고 글을 올리는 사람이 굉장히 많습니다. 안그런다구요? 일본을 잠깐 보면 하나의 글에 댓글이 수만개가 달리지요. 

일본의 특성상 자기가 주제를 올리지 않고 남의 말에 동조하거나 반대 하는 정도만 하거든요.. 

이런 경우 한국의 게시판은 글과 답글을 효율적으로 보여주는 튜닝을 하게 됩니다. 

하지만, 일본의 게시판의 경우는 코멘트를 카운트 하는 것조차 비정규화를 하고, 코멘트 위주로 튜닝을 하기 때문에 인덱스 생성 방법등이 달라지는 것이지요. 

때문에 튜닝은 매년 데이터가 축적되는 패턴을 보고 해야 하는데, 

많은 분들이 튜닝하러 들어와선 과거에 해놓은 것을 보고 욕하시는 분들이 많습니다. 

과거는 과거에 가장 적합했다고 생각하는 튜닝을 했을 것이고, 

지금은 지금에 맞는 튜닝을 해주면 되는 것이지 과거를 왜 욕하는지 모르겠어요.. 

그리고 튜닝은 지속적으로 유저의 행동 패턴을 읽어가면서 해줘야 하는 것입니다. 

또 샜네요.. 

오라클의 경우는 아주 자잘하게 캐시 메모리나, 버퍼캐시, 자주쓰는 소팅 캐시나, 자주 안쓰는 가비지 컬렉션 등등, 

게다가 OS의 캐시 영역 과 SGA, PGA의 영역등을 아주 자잘하게 나누어야 한다는 단점이 있는 대신 잘만 쓰면 위 RDBMS의 한계를 넘어서 OS에서 제공하는 모든 메모리를 아주 효율적으로 사용할 수 있습니다. 

 즉, 튜닝하는 사람의 능력을 가장 잘 알 수 있는게 오라클 튜닝이 될 수 있습니다. 

대형으로 넘어갈 수록 ORACLE은 RAC나 EXA같은 것들이 붙으면서 말도 안되는 분량을 고속 처리하는 기술이 있습니다. 

EXA는 랙 하나가 하나의 노드로도 붙일 수 있고, 노드 10개를 하나의 테이블로 붙일 수도 있습니다. 

그리고 SQL Server에도 있지만 Indexed View같은 view자체를 물리 데이터로 만들어 매번 파싱하지 않기 때문에 고속으로 테이블 처럼 읽어 낼 수도 있지요. 

DB를 사용할 때는 Procedure를 사용해야 빨라진다! 

라고 다들 알고 있었잖아요? 

저도 그렇게 알고 있다가 당한게.. 

MySQL은 모든 Procedure는 실행할 때마다 파싱을 새로 한다고 공식 문서에 있더랍니다. 

저도 모르고 Procedure쓰라고 했다가 공식 문서를 들이민 사람이 있어서 보고 사과한 적이 있지요. 

기본적으로 대부분의 RDBMS에서는 Procedure는 한 번 파싱해 두면 다시 파싱하지 않기 때문에 처리가 빨라집니다. 

MySQL만 빼구요.. 

그리고 RDBMS는 Transaction 단위로 움직이기 때문에 Rollback포인트 지정이 가능합니다. 

즉, 중간에 에러뜨면 무조건 Rollback해라 라던가 하는 명령이 아주 쉽습니다. 

그 중에서도 DTC, Distributed Transaction Coordinator라는게 있는데, 

요즘 처럼 복잡한 서비스는 회원DB, 과금DB, 서비스DB를 따로 쓰는 경우가 많잖아요? 

이럴 때 DTC를 걸면 서로 다른 DBMS사이에서의 트랜잭션 중에 문제가 생기면 다른 서버까지 롤백을 해주는 아주 편리한 기능입니다. 

이역시 SQL Server와 ORACLE에는 있지만 MySQL에는 없습니다. 

SQL Server랑 ORACLE쓰는 사람이 왜 MySQL을 DB가 아니라고 하는지 좀 감이 오셨나요?

RDBMS로서의 충분한 성능이 있지만, 전통적인 RDBMS의 강점들이 충분히 들어있지 않다보니 불편한 점이 많지요.. 

그리고 리소스를 극한까지 쓰려는 사람은 ORACLE을 쓰게 되고, 

극한까지 편하게 쓰려는 사람은 SQL서버를 쓰게 되니 MySQL은 초반에 무료다.. 정도 말고는 메리트가 점점 줄고 있지요. 

요즘처럼 클라우드로 소형 RDBMS를 SQL서버가 저렴하게 제공하니 MySQL의 입지는 더더욱 줄어들고 있는 거 같아요.. 

하지만, MySQL의 점유율은 아직도 충분히 높다는 것! 을 인지해 주시면 좋겠습니다. 

RDBMS하나만으로 이렇게 분량이 나와서 Memcached나 Redis같은 메모리DB(?)나  NoSQL은 다음시간에 해야겠군요.. 

이 정보로 보다 전문적인 지식을 가지시길 바랍니다!

memcached랑 Redis는 뭐가 다르고, 이넘들은 어떻게 쓰는게 효율적인지, 잘못쓰는 사례가 어떤게 있는지.. 

MongoDB랑 Cassandra, HBase 등은 구조적으로 뭐가 다르고 어떻게 쓰는게 좋은지 등등이 궁금하시다면 댓글 주세요~

대규모 시스템에서 실전적으로 쓰이고 있는 사례나 잘못쓴 사례등을 짚어드릴 수 있습니다! ^^

giip :: Control all Robots and Devices! Free inter-RPA orchestration tool! https://giipasp.azurewebsites.net/