[MongoDB] JSON과 BSON의 차이 (번역)

JSON vs BSON

JSON 과 BSON은 거의 비슷한 이름에서 유추할 수 있듯이, 가까운 사촌지간이지만, 이들을 나란히 놓고 보면 그 차이를 알 수 없을 것입니다. JSON, 또는 JavaScript Object Notaion은 웹에서 데이터를 교환하는 BSON(Binary JSON) 기반의 광범위하게 인기있는 표준입니다. 우리는 이 각각을 살펴보며 JSON과 BSON의 미스테리에 작은 불을 밝힐 수 있기를 희망합니다: 어떤 차이가 있고, 무엇이 문제가 될까요?

1. JSON이 뭐지?
2. MongoDB JSON 연결
3. MongoDB : JSON vs BSON

What is JSON?

JavaScript Object Notation, JSON으로 더 많이 알려져있는 이것은 비록 2013년까지는 형식이 공식적으로 지정되지 못했지만, 2000년대 초반에 JavaScript 창시자 Douglas Crockford에 의해 JavaScript 언어의 일부로 정의되었습니다.

 

JavaScript 객체는 문자열 key가 value(숫자, 문자열, 함수, 어떤 객체든)에 맵핑되는 단순한 연관 컨테이너입니다. 이 단순한 언어는 JavaScript 객체를 텍스트로 놀랍도록 단순하게 표현할 수 있다는 특성이 있습니다.

  {
    "_id": 1,
    "name" : { "first" : "John", "last" : "Backus" },
    "contribs" : [ "Fortran", "ALGOL", "Backus-Naur Form", "FP" ],
    "awards" : [
      {
        "award" : "W.W. McDowell Award",
        "year" : 1967,
        "by" : "IEEE Computer Society"
      }, {
        "award" : "Draper Prize",
        "year" : 1993,
        "by" : "National Academy of Engineering"
      }
    ]
  }

JavaScript가 client web 개발의 default 언어가 되면서, JSON은 자신만의 삶을 살기 시작했습니다. 기계와 인간 모두 읽기 쉽고, 비교적 다른 언어를 위한 지원을 구현하기 쉽기 때문에, JSON은 빠르게 web page를 넘어서 software 어디에서든 나아가고 있습니다.

 

JSON은 많은 다양한 경우에서 나타납니다.

• APIs
• 설정 파일들
• 로그 메세지들
• 데이터베이스 저장소

JSON은 인간이 읽기에 더 어렵고, 말이 훨씬 더 많고, 현대 프로그래밍 언어에서 사용되는 객체 구조를 표현하기에 이상적으로 적합하지 않고 XML을 빠르게 추월하였습니다.

MongoDB JSON 연결

MongoDB는 현대 어플리케이션 개발을 위한 궁극적인 데이터 플랫폼이 되기 위한 시초(inception)로부터 고안되었습니다. JSON의 ubiquity는 MongoDB의 혁신적인 document data model에서 데이터 구조를 표현하는 것을 명확한 선택으로 만들어줍니다.

 

그러나, 데이터베이스 내에서 사용할 때 JSON을 이상에 미치지 못하게 만드는 몇가지 이슈가 있습니다.

1. JSON은 텍스트 기반의 형식이고, 텍스트 파싱은 매우 느리다.
2. JSON의 읽기 쉬운 형식은 다른 데이터베이스가 고려하는 공간 효율과는 거리가 있다.
3. JSON은 오직 제한된 몇가지 기본적인 데이터 타입만을 지원한다.

MongoDB JSON을 우선으로 쓰지만 여전히 고성능과 일반적인 목적으로 하기 위해, 그 갭을 메우기 위해 발명되었습니다: 성능, 공간, 유연성까지 최적화하여 데이터를 JSON 형식으로 저장하기 위해 바이너리로 표현합니다. 접근성 측면에서 protocol buffers, thrift와 같은 다른 교환 형식들과는 전혀 비슷하지 않습니다.

What is BSON?

BSON은 "Binary JSON"을 말하는데, 바로 이것이 BSON이 발명된 이유가 된다. BSON의 이진 구조는 훨씬 더 빠르게 파싱될 수 있도록 type과 길이에 대한 정보를 encode합니다.

 

이 초기 공식(formulation) 덕분에, BSON은 MongoDB가 지원하는 가치를 잃어버릴 수 없도록, 몇가지 optional한 non-JSON-native 데이터 타입들을 추가하는 방향으로 확장되고 있습니다.

 

복잡한 수학적 지원을 하는 어떤 종류의 언어들은 전형적으로 다른 사이즈의 정수(integer)타입을 갖고 있거나, 다양한 레벨의 소수 정밀도가 있습니다(float, double, decimal 128 등).

 

MongoDB에 저장된 데이터의 이러한 구별을 표현할 수 있다는 점이 유용할 뿐 아니라, 어플리케이션 코드를 소비하는 것을 용이하게 만드는 방법으로 데이터에 직접적으로 비교와 계산까지도 이루어지도록 할 수 있습니다.

Does MongoDB use BSON, or JSON?

MongoDB는 내부에, 그리고 네트워크를 통해 BSON 형식으로 데이터를 저장하지만, 이것이 MongoDB가 JSON 데이터베이스로 쓸 수 없다는 뜻은 아닙니다. JSON으로 표현할 수 있는 어떤 것이든 MongoDB에 native하게 저장될 수 있고, JSON처럼 쉽고 편하게 가져올 수 있습니다.

 

다음은 몇가지 예제 documents들이고(JavaScript / Python 스타일 문법으로 이루어진), BSON 표현식과 상응합니다.

"hello": "world"} →
\x16\x00\x00\x00           // total document size
\x02                       // 0x02 = type String
hello\x00                  // field name
\x06\x00\x00\x00world\x00  // field value
\x00                       // 0x00 = type EOO ('end of object')

{"BSON": ["awesome", 5.05, 1986]} →
 \x31\x00\x00\x00
 \x04BSON\x00
 \x26\x00\x00\x00
 \x02\x30\x00\x08\x00\x00\x00awesome\x00
 \x01\x31\x00\x33\x33\x33\x33\x33\x33\x14\x40
 \x10\x32\x00\xc2\x07\x00\x00
 \x00
 \x00

JSON을 단순히 string-encoded로 저장하는 시스템이나 binary-encoded blobs와는 달리, MongoDB는 이 산업에서 가장 강력한 인덱싱과 쿼리 기능을 웹의 가장 사용성 있는 데이터 형식으로 제공하기 위해 BSON을 씁니다.

 

예를 들어, 개발자들은 MongoDB를 통해 JSON/BSON document에서 특정한 key를 이용하여 쿼리를 하고, 심지어는 record 내의 많은 레이어들로 인해 깊고 중첩된 documents에서도 많은 객체들을 만들 수 있고, 동일한 키와 값으로 고성능 인덱스를 만들 수 있습니다.

 

어떤 언어에서 MongoDB 드라이버를 쓸 때, 그 언어에서 추상화된 레벨에서 BSON 데이터에 접근한다는 것을 아는 것은 여전히 중요하게 작용합니다.

 

첫째, BSON 객체는 아마 순수 JSON에서는 native하게 표현되지 않는 Date나 Binary 객체를 포함하고 있을 것입니다. 둘째, 각각의 프로그래밍 언어는 그들 자신만의 객체 구조를 갖고 있습니다. JSON 객체는 순서가 있는 키를 가지는데, 예를 들어 Python 딕셔너리(JavaScript 객체와 유사한 가장 native에 가까운 데이터 구조)는 순서가 없는 반면에, 숫자와 문자열 데이터 타입 사이의 차이점도 작용할 수 있습니다(while differences in numeric and string data types can also come into play.). 셋째, BSON은 JSON에 native하지 않고, 각각의 언어마다 다르게 표현하는 다양한 숫자 타입을 지원합니다.

 

사용하는 언어에서 MongoDB에 접근할 때 혼란을 막을 수 있는 최적의 방법을 이해하기 위해, 그리고 최고의 MongoDB 경험을 위해 driver documentation을 확인해보세요.

 

JSON vs BSON

	JSON	BSON
인코딩	UTF-8 String	Binary
데이터 지원	String, Boolean, Number, Array	String, Boolean, Number (Integer, Float, Long, Decimal128...), Array, Date, Raw Binary
가독성	인간과 기계	Only 기계

JSON 그리고 BSON은 사실 가까운 사촌지간으로 디자인되었습니다. BSON은 더 광범위한 어플리케이션을 위해 특정 확장자와 함께 JSON 데이터를 binary로 표현하도록 고안되었고, 데이터 저장과 복구에 최적화되어있습니다.

 

BSON이 JSON과 구별되는 하나의 특정한 방법은 좀 더 진보된 데이터 타입들에 대한 지원입니다. JavaScript로 예를 들면, integer(반올림 숫자)와 부동소수(다양한 정밀도를 가진 실수)를 구분하지 않습니다.

 

대부분의 server-side 프로그래밍 언어들은 효율적인 수학적 연산을 위해 이것의 최상의 사용법을 가진 더 정교한 숫자 타입(integer, float라고 알려진 단정밀도, double이라고 알려진 배정밀도, 그리고 boolean 값)을 가집니다.

Schema Flexibility and Data Governance

JSON & BSON 데이터 모델과 함께 데이터베이스를 사용하는 개발자들에게 크게 매력적인 것들 중 하나는 이들이 제공하는 동적이고 유연한 스키마입니다. 관계형 데이터베이스에 의한 딱딱한 테이블 데이터 모델과 대조되는 점입니다.

 

첫 번째로, JSON documents는 다형성입니다. - fields는 하나의 collection(관계형 데이터베이스에서 테이블과 비슷) 내에서 document마다 달라질 수 있습니다. Documents는 개발자들이 다양한 레코드 속성들을 모델링하는 것을 쉽게 만들어주고, 어떤 구조에서도 쉽게 우아하게 다뤄질 수 있게 만듭니다.

 

두 번째로, 데이터베이스에 documents의 구조를 선언할 필요가 없습니다. documents는 자기설명적입니다(self-describing). 개발자들은 코드 작성을 시작할 수 있고, 객체를 그들이 생긴대로 유지할 수 있습니다.

 

세 번째로, 새로운 필드가 document에 추가되어야 한다면, 이것은 중앙 시스템 카탈로그를 업데이트 하지 않고도, 데이터베이스가 오프라인이 되지 않고도, 컬렉션 내에 다른 모든 documents들에 영향을 주지 않고도 생성될 수 있습니다. 만약 데이터 모델을 바꿀 필요가 있다면, document 데이터베이스는 업데이트된 객체를 비용이 큰 ALTER TABLE 연산(또는 더 나쁜 경우에, 스키마를 처음부터 다시 디자인해야하는 경우도 있다.)을 수행할 필요 없이 저장할 수 있습니다.

 

이러한 장점을 통해, document 데이터 모델의 유연성은 현대 어플리케이션 개발 실무의 수요와 잘 맞습니다.

 

유연한 스키마가 강력한 기능인 반면에, 데이터 구조와 document의 내용을 더욱 컨트롤하길 원하는 상황들이 있습니다. 대부분의 document 데이터베이스들은 이러한 컨트롤을 개발자들에게 어플리케이션 코드에서 구현하기를 강요합니다. 그러나 더 진보된 document 데이터베이스들은 MongoDB에 의해 채택된 IETF JSON Schema standard와 같은 접근 방식을 사용하는 스키마 유효성을 제공합니다.

 

더 많은 정보를 원한다면, 아래의 관련된 정보들을 확인해보세요.

• JSON Schema Examples Tutorial
• BSON types
• MongoDB Extended JSON and BSON
• Modeling Monetary Data in MongoDB
• Advantages of MongoDB
  • What are the advantages of using a database like MongoDB? Learn more about the top reasons managing your database doesn't have to be a headache.