ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • MongoDB ( vs Mysql )
    NoSql/MongoDB 2021. 4. 8. 15:08
    반응형

    특징

    MongDB 는 일반적인 Document 기반의 Nosql 이다. Nosql 을 쓰는 이유는 간단하게는 아래와 같다. 

    - 유연성

    -확장성

    -고성능

    -고가용성 

    이전에 couchbase 를 사용해봤을때 느낀것이지만 Nosql 에서 뭔가 디테일하고 빡빡한 기능들을 사용한다면 여러가지를 고려했을때 기존 RDBMS 를 사용하는것만큼의 리소스가 소모 된다고 생각한다. 여기서 리소스는 개발기간, 유지보수, 단순 성능등 여러가지를 종합한것을 말한다 

    비교 

    기능 비교

    mysql 은 데이터베이스를 새로 만들고 그다음 테이블을 생성할때 컬럼과 타입을 명시해 줘야 한다. 하지만 Document 기반인 MongDB 경우 데이터베이스를 새로 만들어주고 collection 을 생성 해주면 사용 준비가 마무리 된다. 

    - mysql 같은 RDBMS 와 달리 릴레이션에 대한 설계가 없이도 사용이 가능하기 때문에 쉽고 빠르게 구축이 가능하다 

    - 스케일링 관리 기능을 제공하여 클라우드 형태로 사용하기 쉽다 ( 클러스터링 구조 사용 ) 

    - 관계형 데이터베이스는 구조 변경시 큰 오버헤드가 발생하지만 구조에 대한 유연성이 있어 쉽게 변경이 가능하다 

    - 몽고 디비는 기본 형태가 document 자체를 객체로 매핑하기가 쉽기 때문에 복잡한 매핑 계층을 사용하지 않아도 된다 ( ex : ORM ) 

    - Mysql 경우 특정 코어 갯수 부터는 성능 향상이 미비 함. ->MongoDB는 고가용성을 지향함

    - Mysql 경우 일반적은 마스터-슬레이브 구조를 사용하며 복제를 이용한 확장형태로 증설이 가능 ->MongoDB 데이터를 분산하여 저장함. 그리고 클러스터 구조이기 때문에 모든 노드는 동일한 데이터를 가지고 있고 쉽게 스케일아웃이 가능함.

    장단점

      mysql mongdb
    장점 - 데이터 무결성을 보장, 스키마가 정의 되있기 때문 
    - 데이터는 중복없이 한번만 저장
    - 유연성 , 필요할경우 언제든지 필드 추가가 가능함 
    - 일반적으로 서비스에서 필요한 구성으로 저장이 가능하기때문에 조회시 가공할 여지가 적어저 읽기 속도가 빠름 
    - 서버의 수평확장이 가능하여 손쉽게 증설이 가능 
    단점 - 유연성이 없다
    - join이 많아질수록 복잡
    - 서버의 수평 확장이 힘듬
    -유연성 , 데이터구조에 따른 혼란이 올수 있음
    -여러개의 레코드가 변경되면 그에 따라 컬랙선과 document 도 같이 업데이트 해야함 
    역할 - 관계가 중요하고 데이터가 자주 수정되는 데이터에 강점 
    - 스키마나 테이블 구성이 변경의 여지가 없을경우 
    - 정확한 데이터가 없거나 변경/확장이 가능할경우
    - 읽기 위주 이며 , 업데이트가 별로 없을 경우 
    - 처리 데이터 량이 많을 경우 

    사용

    MongoDB

    일단 기본부분이기때문에 설치 부분은 생략 하고 기본적인 명령어들만 간단하게 정리 해놓으려고 한다. 실제로 mysql 에서 사용하는 방식보다는 좀더 직관적이고 쉬운 커맨드를 제공 한다. 

    • db 생성 : use TestDatabase
    • db 확인 : show databases or show dbs
    • db 삭제 : db.dropDatabase()
    • collection 확인 : show collection
    • document 확인 : db.testCollection.find() or db.testCollection.find({"name":"test"})
    • document 삭제 : db.testCollection.remove() or db.testCollection.remove({"name":"test"})

     

    총 평 

    둘다 이게 낫다 저게 낫다의 단계는 최근 넘어간지 오래 된거 같다. 용도에 맞게 쓰는게 맞고 요즘엔 당연하게 두개를 혼용해서 사용한다. 왜냐면 두가지 방식이 가능 장점을 다 가져가고 서로 단점을 서로 커버해서 사용하도록 구성하면 베스트한 서비스 구성이 가능하기 때문이라고 생각한다. 개인적으로는 관계형 데이터베이스를 기본적으로 사용하고 서비스의 도메인의 성격에 따라 일부는 nosql 을 사용하는것이 맞는거 같다. 통계같은 집계 를 하겠다고 할경우 물론 mongodb 나 그외 수많은 nosql 들이 지원은 다해주고 있지만 복잡도가 높아질수록 그것을 사용하기 위한 난이도는 높아지고 투자비용이 늘어나게 된다. 그렇다면 MongoDB에 모아놓은 데이터들을 다시 관계형 데이터베이스에 적절하게 가공하여 집어넣고 좀더 손쉽게 데이터를 제공가능하다면 이런 방식도 충분히 고려해봄직 하다고 생각한다 

    MongoDB이든 mysql 이든 각자 잘하는 분야가 있고 그것에 따라 적절하게 사용하는게 서비스 설계 과정에서 어떤 기술을 도입할것인가란 물음의 중요한 요점이 아닐까 생각이 든다. 지금 만들고 있는 프로젝트는 MongoDB와 AWS RDS를 사용 중이고 지금마음가짐으로 접근중이다.무엇인가를 비교시 너무 이분법적 사고방식 보다는 어떤것이 더 적합하냐라는 목적에 집중하는게 중요한거 같다.

     

    반응형

    'NoSql > MongoDB' 카테고리의 다른 글

    Mongo DB - 대량 데이터 Insert 성능 ( feat. mongoengine )  (0) 2021.11.24
Designed by Tistory.