MongoDB 수업 2일차 - 하악하악!

 

어제의 집중력은 어디갔단 말인가

일이 많아서 힘든게 아니라 할 줄 몰라서 힘든 힘겹던 프로젝트가 끝나고...

MongoDB를 배우기 시작한지 2일차,

 

1일차때는 드디어 프로젝트를 하지 않고 수업을 들을 수 있다는 희망에 집중력이 좋았는데,

2일차가 되자마자 집중력, 기억력이 급감했다. 

 

그리고 어제 저녁 잠시 시간을 내서 머리를 잘랐는데 

5분만에 대충 슉슉자르더니 투블럭은 12000원인데 내가 스스로 옆머리는 바리깡가지고 밀었으니

10000원에 해주겠다고 해주며 생색은 다 내고, 

 

앞머리 옆머리 다 망쳐놓고 드라이기로 머리도 털어주지 않은 미용사덕에 집중력이 떨어졌다.

동네 아주머니도 이렇게는 안하는데 -_-

 

 

Mongo가 몽고 아니다

그래도 힘겹게 힘겹게 질문하며 따라가고 있지만, 

파이널 프로젝트 진행도 같이 해야 한다는 선생님의 말씀...

 

후덜덜덜!!!

 

그래도 MongoDB는 비정형 데이터를 다루는 중요한 DB이기에,

그리고 MongoDB를 배우는데 예전처럼 코드를 따라치는 수준이기에,

 

사치일 수 있지만 책을 잡고 보기로 했다. 

학원 서가에 있던 MongoDB in Action이었다.

 

MongoDB를 만든 회사인 10gen에서 일하는 저자들이 작성한 책이었다.

 

API문서 보는게 힘든 나에게 그나마 이게 나을거라고 생각이 들었다.

 

그런데 가신 님 십리도 못가서 발병나듯

 

20페이지도 못가서 멘붕이 터졌다.

 

MongoDB에서 인덱스는 B-트리(B-tree)로 구현되어 있다. 관계 데이터베이스에서는 기본적으로 제공되는 기능인 이런 종류의 인덱스는 범위를 스캔하거나 정렬을 하는 것과 같이 다양한 쿼리에 대해 최적화되어 있다. 하지만 WiredTiger는 LSM(Log-Structed Merge-Trees)를 지원하며, MongoDB 3.2 정식 배포판부터 이용할 수 있다.

 

대부분의 데이터베이스는 각 도큐먼트 또는 각 행에 기준을 위한 고유의 식별자로서 프라이머리 키를 부여한다. 프라이머리 키는 자동적으로 인덱스되어 각 기준은 유니크 키를 이용하여 효과적으로 기억되며, MongoDB 역시 이와 다르지 않다. 하지만 모든 데이터베이스가 행 또는 도큐먼트에 대한 인덱스 작업을 허용하는 것은 아니다. 이들을 세컨더리 인덱스(secondary index)라 부른다. HBase와 같은 많은 NoSQL 데이터베이스는 키-값 저장소(key-value store)로 간주되는데, 이는 그 어떤 세컨더리 인덱스도 허용하지 않기 때문이다. 이는 MongoDB에서 매우 중요한 특징인데, 여러 개의 세컨더리 인덱스를 허용함으로써 MongoDB는 사용자가 넓은 범위의 쿼리를 최적화하도록 허용한다. 

 

MongoDB에서는 한 컬렉션에 64개까지 세컨더리 인덱스를 만들 수 있다. 오름차순, 내림차순, 고유(unique), 복합 키(compound-key), 해시, 텍스트, 심지어 지리공간적 인덱스와 같이 관계 데이터베이스 시스템에서 볼 수 있는 모든 인덱스가 가능하다. 인덱스에 대해 MongoDB와 관계 데이터베이스는 같은 데이터 구조를 가지므로 어느 한쪽에서 인덱스를 관리하기 위한 권고사항은 다른 쪽에서도 적용할 수 있다.

 

MongoDB in Action 13p

그나마 B-Tree는 낫다.

검색하면 나온다.

 

https://hyungjoon6876.github.io/jlog/2018/07/20/btree.html

B-Tree 개념 정리

LSM은 제대로 된 설명이 안나온다..ㅠㅠㅠㅠㅠㅠㅠㅠ

HBase가 왜 말이 많은지도 모른다... 무튼 말이 많다는 정보는 얻었으니 나중에 아는척 조금 해봐야지.

 

그래도 책을 보다보니 단순히 API문서 따라치는 게 아니라, 밑바닥 흐름부터 잡을 수 있을거 같다는 예감이 든다.

이런 느낌이 좋다. 흐름을 잡고나서 뭔가 천천히 하면 그래도 덜 당황하는데, 막 무작정 달리면 당황한다.

(이렇지 못해서 프로그래밍을 잘 못하는걸까? 핑계일까?)