이번엔 NoSQL의 일종인 MongoDB에 대해서 공부를 해본다...
나는 NoSQL에 대한 개념이 아예 없기 때문에, NoSQL은 뭔지, RDBMS와 비교했을 때 어떤 장점이 있는지 살펴보고자 한다.
NoSQL은 Not Only SQL의 약자다.
-> 지금까지 SQL이 아니라는 뜻인줄 알았다!!!
해석을 해보면, SQL 뿐만 아니라, 인데...
그럼 추가적인 뭔가가 더 있다는거겠지? 그걸 염두에 두고 학습을 시작한다.
* NoSQL은 RDBMS처럼 고정된 스키마 및 JOIN이 존재하지 않는다. 스키마 변경, ALERT등이 필요없다.
* NoSQL의 종류에는 Key-Value Store (Redis), Wide Column Store (HBase, Cassandra), Document Store(MongoDB, CouchDB), Graph Store(Neo4j)가 있다.
헐.
지금까지 나는 NoSQL은 그냥 추상적으로 json 형태로 이루어진 key-value 구조의 데이터베이스인줄 알았다. 그런데 그게 아닌듯 하다.
아니 지금보니 이것 자체가 틀린 말이다! json 형태로 이루어진건 Document Store이고,
key-value 구조는 진짜 말 그대로 파이썬 dictionary처럼 key-value 쌍이 저장되어있는 데이터베이스를 말한다.
익히 알고 있는 Key-Value Store를 제외하고, Wide Column Store, Document Store, Graph Store를 간단히 짚고 넘어가보자.
-> 지금보니까 잘 모르고 있었다. Key-Value Store도 포함해서 설명한다.
Key-Value Store
: NoSQL중 가장 간단한 구조로써, 키 기반으로 값을 저장한다.
-> 이게 NoSQL인지는 몰랐다..
Wide Column Store
: 하나의 행이 많은 열을 포함할 수 있는 구조.
-> Wide Column Store는 왜 쓸까?
위 테이블을 보면...
MiddleName은 사람에 따라 있을 수도 있고 없을 수도 있다. 그럴 때, NoSQL을 쓰면 가변적으로 삭제할 수 있다.
RDBMS를 쓰면? 값이 없다고 해서 그 열 자체를 없애버리는건 불가능하다. NULL 같은 값을 넣어야겠지...
Document Store
: XML, JSON, BSON등 계층적 트리 데이터
-> 이게 내가 원래 생각하던 NoSQL이다. 근데 이건 일부에 불과했구나...
Graph Store
: 그래프 구조를 사용해서 데이터를 표현하고 저장한다.
Q) 그래프 데이터베이스는 Node, Edge, Property를 갖추고 있다. 각 노드의 관계를 나타낼 때 좋은 DB같은데, 실제 어떤 상황에서 이 DB를 쓰게될지는 잘 모르겠다.
이 중, mongoDB는 JSON 기반의 Document DB에 속한다.
그럼 왜 RDBMS를 사용하지 않는걸까? NoSQL의 장점?
: 분산 확장을 쉽게 하기 위해서다.
mongoDB는 Document의 키와 값을 미리 정의하지 않으므로, 고정된 스키마가 없다.
고정된 스키마가 없기 때문에 필요할 때마다 쉽게 필드를 추가하거나 제거할 수 있다.
그럼... RDBMS와 MongoDB가 어떻게 대응되는지 보자.
* mongoDB는 CRUD 이외에도 DBMS의 대부분의 기능을 제공한다.
-> 아하, 아까 앞에서 NoSQL이 Not Only SQL이라고 하더니... 역시 SQL 기능은 다 들어가 있구나.
그리고 +alpha는 확장성같은걸 말하는게 아닐까..????
* mongoDB 데이터의 기본 단위는 Document이고, 이는 관계형 데이터베이스의 행과 유사하다.
* 컬렉션 : 도큐먼트의 모음. 컬렉션은 RDBMS의 테이블에 대응된다.
* mongoDB shell : 명령행에서 mongoDB 인스턴스와 상호작용하는 자바스크립트 셸을 제공
-> Q) 데이터베이스가 자바스크립트로 구현이 되어있나??? 갑자기 자바스크립트가 왜 튀어나오지?
mongoDB 사용을 권장하지 않는 경우 :
1) 다양한 유형의 데이터를 여러 차원에 걸쳐 조인하는 작업은 관계형 데이터베이스에 적합하다. 이는 mongoDB로는 처리하기 힘들다.
2) RDBMS만큼 많은 지원을 하지는 않는다.
-> 즉.... RDBMS와 NoSQL은 서로의 replacement가 아니다! 모자란 부분을 채워주는 역할에 가깝다.
Sharding
: 데이터를 분산해서 저장하는 개념이다.
왜 굳이 분산해서 저장하는데?
-> 트래픽이 증가했을 때, Vertical Scaling보다 Horizontal Scaling이 훨씬 더 효율적이기 때문이다.
ㄴ 그렇지. 당연하다. 원래 하이엔드로 갈수록 가성비가 떨어지니깐... 저렴한거 여러개 사는게 효율상 이득이다.
글구 mongoDB에서는 데이터가 분산되었을 때 데이터 일관성 문제를 해결하기 위해, 설정 서버를 둔다.
이쯤에서 mongoDB의 아키텍처를 보자
Shard들이 분산되어 있고, Client가 각 Shard에 접근할 때는, Mongos에 접근해야 한다.
여기서 mongos가 중앙에서 핵심적인 역할을 하는 것으로 보인다.
위에서 언급했듯 Config Server는 Shard간 데이터 일관성 문제를 해결하기 위해서 사용한다.
아키텍처 자체는 간단해보인다...? 그림만 봤을 때는... ㅎ
mongos의 definition을 한번 찾아보자.
Sharded Cluster의 mongos는 client와 sharded cluster간 interface 역할을 한다.
mongos instance들이 query와 write operations를 shard에 route한다. 엥, 그럼 read operation은?
application의 관점에서, mongos instance는 다른 mongoDB instance와 동일하게 행동한다.
-> 음... 마지막 문장이 조금 어색한데, mongos를 거쳐서 가더라도 Shard로 구분되지 않은 single mongoDB에 접근하는 것과 완전히 동일하다는 뜻으로 이해했다.
Sharding vs Replication
당연하게도, Sharding과 Replication은 대응되는 개념이 아니다.
Sharding은 데이터를 쪼개는 역할이고 (데이터의 분산을 위해, 로드 밸런싱을 위해)
Replication은 이 데이터들의 durability를 위해 이중화를 해놓은 것에 가깝다.
즉, Sharding은 HA 전략이라고 할 수 없다.
-> 엇? 살짝 멈칫했는데...
생각해보면 당연하다. Shard1이 down 되었다고, Shard2나 Shard3이 Shard1을 대체할 수는 없으니까.
왜? 저장된 데이터가 다르잖아!
Percona Server for MongoDB
Percona Server는 뭐야?
-> MongoDB를 더 잘 쓰기 위해서 필요한 도구
Memory Engine, Hot Backups, Log Redactation, Database Auditing, LDAP Authentication ....
음... 여러 가지 기능들을 더 지원하는 듯? 일단 패스.
근데 우리는 지금 쿠버네티스 위에 올라가있는 Percona 서버가 궁금하다.
Percona Operator on k8s의 아키텍처는 다음과 같다.
다른 데이터베이스들과 똑같다.
Primary에 write하고, Primary가 Secondary에 write하고, Secondary에서 read를 한다.
Q) 하나 독특한 것은, 이 아키텍처 상으로는 Primary에서는 read를 안한다는 것?
왜지? 이 부분 다시 확인해볼 필요가 있다.
'Computer Science > Database' 카테고리의 다른 글
| OLTP, OLAP란 뭘까? (0) | 2022.09.06 |
|---|---|
| MSA 환경에서 데이터 관리를 위한 필수 사항: 고가용성과 데이터 동기화 (퍼옴) (0) | 2022.07.20 |
| KAFKA (카프카) 공부해보자 (0) | 2022.06.12 |
| DOIK - Operator와 Database 기본 개념 (0) | 2022.06.06 |
| 트랜잭션과 ACID 특성을 보장하는 방법 (+TPS, DB의 메모리 점유율이 항상 높은 이유) (0) | 2022.06.03 |
최근댓글