몽고DB: 두 판 사이의 차이
편집 요약 없음 |
편집 요약 없음 |
||
| (같은 사용자의 중간 판 4개는 보이지 않습니다) | |||
| 1번째 줄: | 1번째 줄: | ||
[[JSON]] 방식 문서 기반의 [[NoSQL]] 데이터베이스. 2007 10gen에서 개발을 시작해서 2009년에 오픈소스로 공개되었고, 10gen은 아예 회사 이름을 MongoDB Inc.로 바꾸었다. 완전 무료인 커뮤니티 에디션과 유료 지원을 받을 수 있는 엔터프라이즈 에디션 두 가지로 나뉜다. | [[JSON]] 방식 문서 기반의 [[NoSQL]] 데이터베이스. 2007 10gen에서 개발을 시작해서 2009년에 오픈소스로 공개되었고, 10gen은 아예 회사 이름을 MongoDB Inc.로 바꾸었다. 완전 무료인 커뮤니티 에디션과 유료 지원을 받을 수 있는 엔터프라이즈 에디션 두 가지로 나뉜다. | ||
[[NoSQL]]이라는 말이 뜻하는 것처럼 [[관계형 데이터베이스]]가 아니다. 일단 테이블이 없다. 관계형은 기본 구조가 [[데이터베이스]] → 테이블이라면 몽고DB는 데이터베이스 → 컬렉션으로 되어 있다. 이 컬렉션을 테이블과 같은 것으로 생각하기 쉽지만 개념이 많이 다르다. 일단 테이블은 그 안의 스키마가 고정되어 있으며, 같은 테이블에 저장되는 레코드는 같은 스키마를 가져야 한다. 설령 어떤 레코드에게는 무의미한 키라고 해도 어쨌든 Null 값이든 0이든 키와 값이 존재한다. 또한 테이블의 각 속성은 데이터 유형이 정의되어 있으므로 다른 유형을 넣을 수 없다. | [[NoSQL]]이라는 말이 뜻하는 것처럼 [[관계형 데이터베이스]]가 아니다. 일단 테이블이 없다. 관계형은 기본 구조가 [[데이터베이스]] → 테이블이라면 몽고DB는 데이터베이스 → 컬렉션으로 되어 있다. 이 컬렉션을 테이블과 같은 것으로 생각하기 쉽지만 개념이 많이 다르다. 일단 테이블은 그 안의 스키마가 고정되어 있으며, 같은 테이블에 저장되는 레코드는 같은 스키마를 가져야 한다. 설령 어떤 레코드에게는 무의미한 키라고 해도 어쨌든 Null 값이든 0이든 키와 값이 존재한다. 또한 테이블의 각 속성은 데이터 유형이 정의되어 있으므로 다른 유형을 넣을 수 없다. 테이블 안에 테이블이 들어갈 수는 없으며 각각 다른 테이블로 놔 둔 다음 JOIN 연산과 같은 방법으로 연결해서 써야 한다. | ||
반면 컬렉션은 단순히 문서를 모아놓은 컨테이너에 불과하다. 즉 같은 컬렉션 안에 있는 문서(관계형 데이터베이스에서는 레코드)라고 해도 키와 값은 일관성 없이 제각각일 수 있다. 또한 각 키에 대한 값에 미리 데이터 유형이 정해져 있는 것도 아니다. 여기에 더해서 컬렉션은 트리 구조를 가질 수도 있다. 즉 테이블은 스키마의 정의라는 강력한 권한을 가지지만 컬렉션은 그런 거 없다. 이러한 구조는 [[NoSQL]] 답게 데이터 구조의 일관성을 강제하지 않아서 데이터 구조가 굉장히 유연하다. 관계형 [[데이터베이스]]는 테이블을 일단 짜 놓고 데이터가 쌓이면 이 구조를 고치는 게 좀 까다로운 반면, 몽고DB는 그야말로 막 할 수 있다. 예를 들어, 어떤 컬렉션에 새로운 문서를 하나 집어넣으면서 전에는 정의되어 있지 않던 키를 쓸 수도 있다. 그렇다고 기존의 컬렉션에 있던 문서에 이 키가 전부 생기는 것도 아니다. 물론 이러한 유연함은 손쉽게 독이 되는데, 관계형 데이터베이스는 스키마 정의를 통해서 데이터의 유효성과 일관성을 어느 정도 확보할 수 있지만 몽고DB는 프로그래머가 스스로 신경쓰지 않으면 정말로 개판이 될수 있다. | |||
몽고DB 데이터 질의가 간단한 건 정말 단순해 보이지만 질의문을 무조건 [[JSON]] 형태로 만들어야 하기 때문에 조금만 복잡해지면 [[SQL]]과는 비교도 안 되게 알아보기 힘들어진다. 이를 보완하기 위해서 몽구스를 많이 쓴다. 몽구스는 스키마를 정의함으로써 관계형 | 정형화 되지 않은 데이터가 폭발적으로 늘어나는 [[빅데이터]] 시대가 되면서 다른 [[NoSQL]] 데이터베이스와 함께 급부상하고 있다. 아니, 급부상 정도가 아니라 [[NoSQL]]의 선두주자라고 해도 과언이 아니다. 현재 DB 시장 점유율을 보면 금방 드러난다. 2017년 1월에 DB-Engines.com이 발표한 순위를 봐도 [[오라클]], [[MySQL]], MS SQL서버에 이어서 4위를 차지하고 있을 정도다! 위의 세 가지와 비교하면 훨씬 역사가 짧은 몽고DB가 이 정도의 입지를 가지고 있는 것은 놀라운 일. <ref>그 다음에 나오는 [[NoSQL]]은 7위를 기록하고 있는 [[아파치]]의 [[카산드라]]다. </ref> | ||
하지만 금융 거래와 같이 데이터의 안전성이나 정확성이 절대 중요한 분야에는 적합하지 않다. | |||
모든 데이터는 [[JSON]] 형식으로 입출력되며, 이를 '문서'라고 한다. JSON이 [[자바스크립트]] 쪽에서 나온 것인 만큼 [[자바스크립트]]와 궁합이 좋다. 물론 [[루비]], [[PHP]]를 비롯한 어떤 언어에도 붙여 쓸 수 있지만 [[Node.js]]에 붙여서 쓰는 [[NoSQL]] [[데이터베이스]]로는 가장 많이 쓰이고 있다. 일단 [[하둡]]이나 [[카산드라]] 같은 다른 [[NoSQL]] [[데이터베이스]]에 비해서 진입장벽이 낮고 [[자바스크립트]]를 알고 있으면 [[JSON]]도 능숙하게 다룰 수 있기 때문. 아예 [[자바스크립트]] 언어 한 가지로 프론트엔드-백엔드-[[데이터베이스]]까지 퉁칠 수 있는 대표 기술들을 [[MEAN 스택]]으로 묶어서 웹 개발 플랫폼으로 사용하는데 여기서 'M'에 해당하는 것이 몽고DB다.<ref>E는 Express.js, A는 [[AngularJS]], N은 [[Node.js]]를 뜻한다.</ref> 자세한 것은 해당 항목 참조. | |||
몽고DB 데이터 질의가 간단한 건 정말 단순해 보이지만 질의문을 무조건 [[JSON]] 형태로 만들어야 하기 때문에 조금만 복잡해지면 [[SQL]]과는 비교도 안 되게 알아보기 힘들어진다. 이를 보완하기 위해서 몽구스를 많이 쓴다. 몽구스는 스키마를 정의함으로써 [[관계형 데이터베이스]]와 비슷한 형태의 모델을 만들어 쓸 수 있도록 돕는다. 또한 한 가지의 질의는 단일 컬렉션 안에서만 할 수 있는 몽고DB의 한계를 어느 정도 보완해서 여러 컬렉션을 묶은 질의도 할 수 있다. 그렇다고 [[관계형 데이터베이스]]와 똑같이 몽고DB를 다룰 수 있는 것은 절대 아니며, 몽고DB에서 원래 안 되던 것을 몽구스를 사용해서 무리하게 하다 보면 성능 저하가 심각하게 일어날 수 있다. | |||
{{각주}} | {{각주}} | ||
[[Category:데이터베이스]] | [[Category:데이터베이스]] | ||
2020년 11월 25일 (수) 10:36 기준 최신판
JSON 방식 문서 기반의 NoSQL 데이터베이스. 2007 10gen에서 개발을 시작해서 2009년에 오픈소스로 공개되었고, 10gen은 아예 회사 이름을 MongoDB Inc.로 바꾸었다. 완전 무료인 커뮤니티 에디션과 유료 지원을 받을 수 있는 엔터프라이즈 에디션 두 가지로 나뉜다.
NoSQL이라는 말이 뜻하는 것처럼 관계형 데이터베이스가 아니다. 일단 테이블이 없다. 관계형은 기본 구조가 데이터베이스 → 테이블이라면 몽고DB는 데이터베이스 → 컬렉션으로 되어 있다. 이 컬렉션을 테이블과 같은 것으로 생각하기 쉽지만 개념이 많이 다르다. 일단 테이블은 그 안의 스키마가 고정되어 있으며, 같은 테이블에 저장되는 레코드는 같은 스키마를 가져야 한다. 설령 어떤 레코드에게는 무의미한 키라고 해도 어쨌든 Null 값이든 0이든 키와 값이 존재한다. 또한 테이블의 각 속성은 데이터 유형이 정의되어 있으므로 다른 유형을 넣을 수 없다. 테이블 안에 테이블이 들어갈 수는 없으며 각각 다른 테이블로 놔 둔 다음 JOIN 연산과 같은 방법으로 연결해서 써야 한다.
반면 컬렉션은 단순히 문서를 모아놓은 컨테이너에 불과하다. 즉 같은 컬렉션 안에 있는 문서(관계형 데이터베이스에서는 레코드)라고 해도 키와 값은 일관성 없이 제각각일 수 있다. 또한 각 키에 대한 값에 미리 데이터 유형이 정해져 있는 것도 아니다. 여기에 더해서 컬렉션은 트리 구조를 가질 수도 있다. 즉 테이블은 스키마의 정의라는 강력한 권한을 가지지만 컬렉션은 그런 거 없다. 이러한 구조는 NoSQL 답게 데이터 구조의 일관성을 강제하지 않아서 데이터 구조가 굉장히 유연하다. 관계형 데이터베이스는 테이블을 일단 짜 놓고 데이터가 쌓이면 이 구조를 고치는 게 좀 까다로운 반면, 몽고DB는 그야말로 막 할 수 있다. 예를 들어, 어떤 컬렉션에 새로운 문서를 하나 집어넣으면서 전에는 정의되어 있지 않던 키를 쓸 수도 있다. 그렇다고 기존의 컬렉션에 있던 문서에 이 키가 전부 생기는 것도 아니다. 물론 이러한 유연함은 손쉽게 독이 되는데, 관계형 데이터베이스는 스키마 정의를 통해서 데이터의 유효성과 일관성을 어느 정도 확보할 수 있지만 몽고DB는 프로그래머가 스스로 신경쓰지 않으면 정말로 개판이 될수 있다.
정형화 되지 않은 데이터가 폭발적으로 늘어나는 빅데이터 시대가 되면서 다른 NoSQL 데이터베이스와 함께 급부상하고 있다. 아니, 급부상 정도가 아니라 NoSQL의 선두주자라고 해도 과언이 아니다. 현재 DB 시장 점유율을 보면 금방 드러난다. 2017년 1월에 DB-Engines.com이 발표한 순위를 봐도 오라클, MySQL, MS SQL서버에 이어서 4위를 차지하고 있을 정도다! 위의 세 가지와 비교하면 훨씬 역사가 짧은 몽고DB가 이 정도의 입지를 가지고 있는 것은 놀라운 일. [1]
하지만 금융 거래와 같이 데이터의 안전성이나 정확성이 절대 중요한 분야에는 적합하지 않다.
모든 데이터는 JSON 형식으로 입출력되며, 이를 '문서'라고 한다. JSON이 자바스크립트 쪽에서 나온 것인 만큼 자바스크립트와 궁합이 좋다. 물론 루비, PHP를 비롯한 어떤 언어에도 붙여 쓸 수 있지만 Node.js에 붙여서 쓰는 NoSQL 데이터베이스로는 가장 많이 쓰이고 있다. 일단 하둡이나 카산드라 같은 다른 NoSQL 데이터베이스에 비해서 진입장벽이 낮고 자바스크립트를 알고 있으면 JSON도 능숙하게 다룰 수 있기 때문. 아예 자바스크립트 언어 한 가지로 프론트엔드-백엔드-데이터베이스까지 퉁칠 수 있는 대표 기술들을 MEAN 스택으로 묶어서 웹 개발 플랫폼으로 사용하는데 여기서 'M'에 해당하는 것이 몽고DB다.[2] 자세한 것은 해당 항목 참조.
몽고DB 데이터 질의가 간단한 건 정말 단순해 보이지만 질의문을 무조건 JSON 형태로 만들어야 하기 때문에 조금만 복잡해지면 SQL과는 비교도 안 되게 알아보기 힘들어진다. 이를 보완하기 위해서 몽구스를 많이 쓴다. 몽구스는 스키마를 정의함으로써 관계형 데이터베이스와 비슷한 형태의 모델을 만들어 쓸 수 있도록 돕는다. 또한 한 가지의 질의는 단일 컬렉션 안에서만 할 수 있는 몽고DB의 한계를 어느 정도 보완해서 여러 컬렉션을 묶은 질의도 할 수 있다. 그렇다고 관계형 데이터베이스와 똑같이 몽고DB를 다룰 수 있는 것은 절대 아니며, 몽고DB에서 원래 안 되던 것을 몽구스를 사용해서 무리하게 하다 보면 성능 저하가 심각하게 일어날 수 있다.
