MongoDB의 히스토리

2007년 중반 뉴욕에 위치한 10gen이란 신생 기업이 웹 애플리케이션을 호스트 하고 필요하면 확장할 수 있는 애플리케이션 서버와 데이터베이스로 이뤄진 서비스로서 소프트웨어 플랫폼에 대한 개발을 시작했습니다. 여기서 구글의 AppEngine과 같이 10gen의 플랫폼은 하드웨와 소프트웨어 인프라 관리의 확장성을 자동으로 처리를 하고 그에 따라 자사의 개발자들이 앱 코드에 더 집중을하게 하려는 목적으로 설립된 DB입니다. 여기서, 기술 계층을 제어할 수 없는 점을 대부분의 개발자들이 불편하다는 사실을 알게 되어, 사용자들은 새로운 DB를 원했고 거기에서 10gen이 개발을 한 모델이 mongodb입니다. 추가적으로 회사 이름도 MongoDB로 바꾸고 오픈 소스 프로젝트로서 DB 개발을 계속 지원을 하고 있습니다.

현대 데이터 저장 기술 관계형 데이터베이스의 현황과 새로운 패러다임의 도전

비교적 나는 최근에 웹 개발에 대한 영역을 알게 되었고, DB와의 연동, 프로토콜 SSL인증서 등 다양한 영역을 찍먹을 하며 공부를 하고 있습니다. 여기서 1차원적으로 웹 개발의 영역을 살펴 본다면, 퍼블리싱과 DB 그리고 여러 API를 이용한 범용성 넓은 연결과 통신정도로 볼 수 있겠네요 만약에 이 글을 읽는 당신이 SQL에 친숙할 정도로 숙련도가 있다면 정규화가 잘된 데이터 모델의 유용함과 트랙잭션의 필요성 그리고 견고한 저장 엔진을 통해 얻는 확신에 대해 잘 인식을 하고 있을 것입니다.

간단하게 말해서 관계 데이터 베이스는 이미 충분히 잘 발전이 되고 잘 알려져있는 기술인데요, 개발자들이 데이터 저장 기술의 대안에 관하여 말하기 시작을 할 때에, 이 새로운 기술들의 실현 가능성과 유용성에 대한 의문점이 생길 것이라고 봅니다. 새로운 데이터 저장 시스템은 관계형 DB를 대체할 수 있을까란 의문점과 그리고 누가 왜 실제 서비스 상에서 이를 이용한 퍼포먼스를 보여 줄 지 기대를 하고 있는 사람도 있겠죠

비관계 데이터 베이스 어떤 장단점이 있을까?

이런 질문들에 대한 답을 얻기 위해선, 우선 이 해답을 찾으면 됩니다. 왜 개발자들이 몽고 DB에 대한 관심도가 높을까? MongoDB는 웹 애플리케이션과 인터넷 기반을 위해 설계된 데이터 베이스 관리 시스템입니다.

데이터 모델과 지속성 전략이 높은 읽기 및 쓰기 효율을 통한 확장의 용이성을 염두에 두고 만들어진 점을 생각 하시면 편해요, 애플리케이션에 대한 필요한 DB는 Node가 1개이거나 혹은 그 이상이 되어도 상관이 없이 MongoDB는 좋은 퍼포먼스를 보여줍니다. 관계형 데이터 베이스를 확장을 하는대에 어려움을 겪었던적이 있다면 몽고DB는 당신에게 좋은 퍼포먼스를 가져다줍니다.

하지만, 모든 경우에는 확장만이 필요한것이 아니라, 단 하난의 데이터 베이스 서버만 필요한 경우도 있을 것입니다. 예를 들어 단 1개의 서버만 운영하는 서비스를 할 경우 Docker의 사용은 투머치하다는 의견과 동일하게 적용이 되는 것일까요? 이 부분은 개발자들이 단순히 확장성 때문에 사용하는 것이 아니라 직관적인 데이터 모델을 좋게 보기 때문입니다. MongoDB는 데이터를 행(row) 대신에 도큐먼트에 저장을 하기 때문이죠

도큐먼트 예시 

{
  "_id": ObjectId("615b6d0c82aacc3e4f92b587"),
  "name": "John Doe",
  "age": 30,
  "email": "john.doe@example.com",
  "address": {
    "street": "123 Main Street",
    "city": "Some City",
    "state": "Some State",
    "zipcode": "12345"
  },
  "interests": ["reading", "hiking", "cooking"],
  "isVIP": true
}

이 예시에서 각 필드는 도큐먼트의 속성을 나타냅니다:

id: 모든 도큐먼트는 고유한 식별자인 ObjectId를 가집니다. name, age, email: 사용자의 기본 정보를 저장하는 필드입니다. address: 내부 도큐먼트로, 주소 정보를 객체 형태로 저장합니다. interests: 취미를 배열로 저장합니다. isVIP: 불리언 값으로 특정 조건을 나타냅니다. 이와 같은 구조로 데이터를 저장함으로써, MongoDB는 유연성과 확장성을 제공하며, 복잡한 계층 구조를 표현할 수 있습니다.

MongoDB의 도큐먼트 형식은 임의의데이터 구조를 저장을 한은 스키마로 잘 알려진 Json을 기반으로 합니다. Json의 구조는 키와 값으로 나누어져 있습니다. 파이썬의 딕셔너리와 비슷하게 보이죠? 여기서 도큐먼트 기반의 데이터 모델은 풍부하고 계층적인 구조의 데이터를 표현할 수 있습니다. 따라서 관계형 데이터베이스에 필요한 여러 테이블 간의 복잡한 조인 연산이 없어도 되는 이점을 가지고 있어요 예를 들어, 우리가 온라인 쇼핑몰 운영을 위해 상품 모델링을 데이터로 저장을 한다고 생각을 해봅시다. 완전히 정규화된 데이터 모델에서 한상품의 정보는 여러개의 테이블로 나누어 각각의 속성에 알맞게 저장이 될 것입니다. 여기서 DB Shell에서 한 상품에 대한 레코드를 얻기 위해선 조인 연산으로 가득 찬 복잡한 Sql쿼리를 이용을 해야 한다는 강제성도 부여가 되겠죠

도큐먼트 기반의 데이터 저장의 장점

하지만 상품 정보를 하나의 도큐먼트로 표현할 수 있다면 어떨까요? MongoDB의 JS 셸을 열어서 상품 정보를 조회를 해보면 Json과 같은 형태의 계층 구조를 통해 보다 더 가독성이 좋게 이해가 됩니다. 그와 더불어 도큐먼트에 대한 수정도 보다 명확하게 나눌 수 있으며 쉽게 표현할 수 있습니다. MongoDB의 쿼리 언어 기능은 특별히 도큐먼트 구조의 조작을 위해 설계가 되었고, 특히 결과적으로 관계 데이터 베이스로부터 MongoDB로 옮겨 온 사용자들이 관계 데이터베이스와 비슷한 수준의 쿼리 언어 성능으로 즐길 수 있게 되는거에요

그렇다면 MongoDB의 핵심적인 기능은?

데이터베이스의 많은 부분이 데이터 모델에 의해 정의가 된다는 사실은 잘 알고 계실거라 생각합니다. 우선적으로 핵심적인 기능은MongoDB는 유연한 스키마를 가지며, 데이터를 고정된 형식으로 미리 정의할 필요 없이 저장할 수 있습니다. 이것은 데이터 모델을 더욱 유연하게 다룰 수 있게 해줍니다. 데이터는 JSON 형식의 문서로 저장되며, 중첩된 데이터와 복잡한 구조도 쉽게 다룰 수 있습니다. 대량의 데이터를 처리하기 위해 데이터를 여러 서버로 분산하여 저장할 수 있는 수평적 확장 기능을 갖추고 있습니다.

다양한 유형의 인덱스를 지원하여 데이터 검색 속도를 높여줍니다.데이터 분석과 집계 작업을 위한 프레임워크를 제공하여 복잡한 작업을 효율적으로 처리할 수 있습니다. 레플리카 세트를 통해 데이터의 복제본을 유지함으로써 시스템 가용성을 높여줍니다. 자동 샤딩을 통해 대량의 데이터를 처리하면서도 성능을 유지할 수 있습니다. 데이터 보안 기능과 암호화를 통해 데이터를 안전하게 보호할 수 있습니다. 지리 정보 데이터를 저장하고 검색할 수 있는 기능을 제공합니다.

도큐먼트 데이터 모델

우선적으로 거듭 강조가 되지만, 다른 DB와는 다르게 도큐먼트를 중점적으로 사용하는 데이터베이스입니다. 여기서 의미하는 도큐먼트의 개념이 다소 생소할 수 있기 때문에 예를 들어 쉽게 설명을 한다면 Json도큐먼트는 숫자 값을 제외한 모든 곳에서 ("") <- 이것이 필요합니다. 여기서 쌍따옴표가 필요 없는 Json도큐먼트의 자바스크립트 버전의 예시를 보겠습니다.

JSON 도큐먼트의 자바스크립트 버전 예시 

const exampleDocument = {
  _id: 12345, // 프라이머리 키
  tags: ["tag1", "tag2", "tag3"],
  attribute: {
    attributeId: 987,
    attributeName: "Attribute Example"
  },
  comments: [
    {
      commentId: 1,
      text: "This is the first comment."
    },
    {
      commentId: 2,
      text: "This is the second comment."
    }
    // 추가적인 코멘트 객체들...
  ]
};

// 예시 데이터 접근
console.log("_id:", exampleDocument._id);
console.log("Tags:", exampleDocument.tags);
console.log("Attribute:", exampleDocument.attribute.attributeName);
console.log("Comments:");
exampleDocument.comments.forEach(comment => {
  console.log("- Comment ID:", comment.commentId);
  console.log("  Text:", comment.text);
});

첫 번째로, _id 필드는 프라이머리 키 역할을 합니다. 
이 값은 고유한 식별자로서 각 도큐먼트마다 유일하게 지정됩니다. 
tags는 문자열의 배열로서, 여러 태그를 저장하는 데 사용됩니다. 
예를 들어 "tag1", "tag2", "tag3"와 같은 태그들을 포함할 수 있습니다. 
attribute 객체는 또 다른 도큐먼트를 가리키는 속성입니다. 
이 객체는 attributeId와 attributeName 두 가지 정보를 포함하고 있는데
예시로 "Attribute Example"이라는 속성 이름을 가진 객체를 보여주고 있습니다.
comments는 코멘트 객체들의 배열입니다.
각 코멘트 객체는 commentId와 text라는 두 가지 정보를 담고 있는데
이는 해당 코멘트의 고유 식별자와 코멘트 내용을 의미합니다.
예시에서는 두 개의 코멘트 객체를 보여주고 있습니다.
이제 코드 내에서 예시 데이터에 접근하는 방법을 살펴봅시다. 
_id 필드의 값, tags 배열, attribute 객체의 attributeName
그리고 comments 배열 내의 각 코멘트 객체들을 접근하여 출력하고 있습니다.
이렇게 자바스크립트를 사용하여 데이터를 조작하고 활용할 수 있습니다.

스키마가 없는 모델의 장점은 무엇인가?

이렇게스키마가 없다는 것에선 몇가지 장점이 존재합니다. 우선적으로 먼저 DB가 아닌 애플리케이션 데이터 구조를 정한다는 의미입니다.

이것은 DB의 구조가 매번 변경과 수정을 이루는 현업 개발 초기 단계에서 개발 속도를 단축을 시켜주는 장점을 가지고 있습니다. 더 중요한것으론, 스키마가 없는 데이터 모델을 통하여 가볁넉인 속성을 갖는 데이터를 표현할 수 있다는 장점이 존재 하는데요, 예를 들어 전자상거래 상품 카탈로그를 만든다고 생각을 해보면, 하나의 상품이 어떤 속성을 가지게 될지 미리 알 수 없는 상황으로 애플리케이션에는 이런 불안정한 속성을 처리할 수 있게 해주는게 중요합니다.

스키마가 없는 모델을 사용하면 데이터 호환성을 보다 유연하게 관리할 수 있습니다. 예를 들어 다른 버전의 애플리케이션 간에 데이터 구조가 약간 변경되더라도 기존 데이터와 새 데이터를 조화롭게 처리할 수 있습니다.

또한, 스키마가 없는 모델을 사용하면 다른 소스에서 온 데이터를 쉽게 통합할 수 있습니다. 다른 형식이나 구조의 데이터를 유연하게 처리하여 새로운 인사이트나 가치를 얻을 수 있습니다. 그와 더불어 데이터베이스에는 중요하지 않은 정보가 포함될 수 있습니다.

이런 데이터는 스키마가 없는 모델에서 더 쉽게 처리할 수 있으며, 필요한 정보를 추출하고 유용한 인사이트를 얻을 수 있습니다.

만약, 모델과 서버 자체가 달라지는 상황이 발생하면 스키마가 없는 모델을 사용하면 데이터 마이그레이션 과정이 더 간소화됩니다. 새로운 필드를 추가하거나 변경할 때 기존 데이터를 쉽게 변환할 수 있습니다.