brunch

You can make anything
by writing

C.S.Lewis

by 신현묵 May 26. 2017

Node.js 기반 백엔드 시스템,#5

Node.js와 DBMS, MongoDB등의 연관관계!

다시 설명해봅니다. Node.js는 SPA형태의 '단일 스레드 이벤트 루프'형태의 개발에 매우 적합합니다. 조금 번거롭기는 하지만, 각각의 프로세스를 개별적으로 구현하는 것이 최선이기는 합니다. 하지만, 실제 개발이 그런 상황으로만 연장될 리가 없습니다.


실제 개발을 하다 보면 만나는 4가지의 형태입니다. RESTful API의 호출이 매우 다양하게 얽히게 될 것입니다. 그리고, DB는 점점 복잡해지는 형태를 띨 것이며, 서비스를 진행하면서 특정 웹 트랜잭션( 사용자 호출 )에 대응하는 Query가 매우 느려지는 현상이 반복되면서 서비스는 점점 버거워지게 되는 것이 현실입니다.


특히, MySQL과 같은 DB의 문제에 좀 더 집중해보겠습니다.

분명한 것은 MySQL만 사용해도 대부분의 서비스는 처리가 가능합니다. 특히, 1억 row이하의 쓰기가 많지 않은 데이터 형태를 갖추고 있다면, MySQL은 대부분의 비즈니스의 구현에 적합합니다. 다만, '게임'의 형태의 경우에는 이런 DB의 구성만으로는 만들 수 없습니다.


최종적으로 만들어진 게임들의 구성 형태를 보면 결제정보나 정합성이 필요한 영역에서만 DBMS를 사용하고, 대부분의 다른 게임 정보들이나 비즈니스 정보들은 MongoDB나 확장성이 풍부한 데이터 저장 방식들을 사용합니다.


물론, RDBMS를 잘 다루는 전문가나 숙련자가 있다면, 적절한 쿼리 튜닝을 통해서 성능을 향상하거나, Read-only 리플리케이션을 잘 나누어서, 처리 속도를 증가시키고, 샤딩전략으로 그 형태를 확장하는 방법도 가능합니다.


최근에는 구글 스패너와 같은 환경의 New-SQL도 만들어지고 있으니, 데이터 처리 방식은 가장 숙련된 사람이 빠르게 적용할 수 있으면 그만인 것 같습니다.


하루 방문자 수가 10만 명 이하라면, 냉정하게 MySQL로도 어지간한 게임이나 앱 서비스들은 커버가 가능합니다. 적장 한 캐시 전략만으로도 충분하죠.


그럼에도 불구하고, 웹서비스나 게임의 경우에는 MongoDB를 많이 추천합니다. 스키마와 인덱스가 자유롭고, 스키마의 완성과 관계없이 서비스가 확장되면서 늘려나가는 구조 확장 형태는 스타트업이거나 초기 개발에 매우 적합합니다.


특히, MongoDB의 경우 2차원 인덱스를 다루는 것에 매우 탁월한 성능을 보입니다. KNN쿼리는 위치정보로 주변 거리 정렬로 N개의 결과물을 얻는 형태로 사용될 때에 매우 적합합니다.


그래서, 데이터베이스를 사용하더라도 위치정보를 사용하게 된다면, 웬만하면 MongoDB를 혼용해서 사용하라고 권장할 정도입니다.


앱이나 게임 서버에서 '위치'가 중요하다면, 사실 MongoDB가 매우 적합합니다.


더군다나, Node.js와 궁합도 좋을뿐더러, 자바 스크립트 객체 그 자체를 넣고 쿼리까지 가능하다는 점은 정말 MongoDB와 Node.js를 혼용하게 되는 큰 이유이기도 합니다.


대부분의 Node.js프로젝트들은 이처럼 MySQL과 MongoDB를 적절하게 혼용하여 사용하는 경우가 많습니다.



매거진의 이전글 Node.js 기반 백엔드 시스템,#4
작품 선택
키워드 선택 0 / 3 0
댓글여부
afliean
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari