-
[DB] NoSQL 처음보는 초보 개발자가 쓰는 NoSQL이란?database/DB Concept 2021. 2. 1. 18:57
NoSQL 처음보는 초보 개발자가 쓰는 NoSQL이란?
안녕하세요? 장장스입니다.
오늘은 NoSql에 대해 포스팅해보려고 합니다. 그동안 저는 오라클, MySql, MariaDB 같은 테이블 형태의 관계형 데이터베이스만을 사용해 봤었습니다. 그런데 유튜브를 보다보면 NoSql이라는 단어를 종종 보곤 했는데요. NoSql이 무엇인지 초보 개발자의 시선으로 풀어보려고 합니다!
NoSQL은 왜? 어떻게? 두둥등장 했을까?
그래프를 보면 2009년을 기점으로 NoSQL이 SQL을 추월하여 사용되고 있는 것과 SQL이 점점 하향세를 타고 있음을 알 수가 있습니다. 이렇게 많이 사용되고 있지만 개발자인 제가 정작 NoSQL이 무엇이지 모르고 있다는 사실이 참 부끄러워지네요,, ㅠㅠ
구글이나 페이스북과 같은 글로벌 기업들은 엄청나게 쏟아지는 데이터들과 트래픽의 양으로 인해 기존의 관계형 데이터베이스로는 더 이상 쏟아지는 엄청난 데이터를 감당하기 어려워지는 것을 느꼈습니다. 어떤 문제일까요?
기존의 관계형 데이터베이스는 하나의 시스템에서 작동하도록 설계가 되어있습니다. 따라서 성능을 향상시키기 위해서는 더 좋은 성능의 하드웨어를 하나의 시스템에 모두 몰빵(?) 해야만 했었고, 이는 비용의 큰 증가를 불러왔습니다. 때문에 이러한 문제를 해결하기 위해 NoSQL이 본격적으로 등장하게 됩니다.
NoSQL 이란?
뜻만 놓고 보면 SQL만을 사용하지 않는 데이터베이스 관리 시스템을 지칭하는 단어입니다. 쿼리가 없다는 말은 아닙니다. MongoDB나 CouchDB는 각각 다른 쿼리 언어가 있습니다. 기존의 SQL을 사용하지 않는 다고 보면 좋을 것 같습니다.
정확하게 NoSQL에 대해 내려진 구체적인 정의같은 것은 없습니다. 대신 아래와 같은 성격을 보입니다.
- 대부분 클러스터에서 실행할 목적으로 만들어졌기 때문에 관계형 모델을 사용하지 않습니다. (일부는 RDBMS와 비슷한 분산 모델을 사용합니다.)
- 스키마 없이 동작한다.
- 구조에 대한 정의를 변경할 필요 없이 데이터베이스 레코드에 자유롭게 필드를 추가할 수 있다.
특징 #1. 수평적 확장(Scale-out)을 통한 데이터 분산 저장
위에서 언급했듯이 기존의 관계형 데이터베이스는 시스템 하드웨어를 고성능으로 업그레이드하는 수직적 확장(Scale-up)으로 문제를 해결해야 했다. 이는 더욱 더 고성능의 장비를 요구하는 큰 비용의 문제를 불러왔다.
반면 NoSQL 데이터베이스는 적당한 성능의 장비의 수(서버)를 늘리는 수평적 확장(Scale-out)을 통해 장비의 성능을 올릴 수 있다. 이와 같은 특징으로 인해 데이터를 저장할 때 여러 DB서버에 나누어서 저장을 하게 되는 분산 저장의 특징을 갖는다.
특징 #2. 자유로운 스키마(schema-free)
학교에서 배운 데이터베이스 과목을 떠올려 보라. 하나의 데이터베이스를 만드는 개념/내부/외부 스키마를 마구 만들어야 했었다. 그러나 NoSQL 데이터베이스의 공통적인 특징은 스키마가 없이 동작한다. 이는 DBMS가 스키마를 관리하지 않는 것일 뿐 NoSQL도 암묵적인 스키마는 존재한다. 때문에 단일 값에 대한 데이터 타입에서 불일치가 발생 할 수 있다.
특징 #3. 간단한 쿼리
RDBMS는 데이터를 조회하기 위해 수많은 테이블을 JOIN 하거나 서브쿼리를 달거나 등등 복잡한 쿼리문을 사용해 왔다. 하지만 NoSQL은 복잡한 쿼리를 사용하지 않는다.
특징 #4. 일관성보다 확장성
학부시절 데이터베이스의 절대적인 요소로 일관성에 대해서 배웠다. 그러나 NoSQL은 아래와 같은 이유로 일관성을 양보(?)해도 된다고 말한다.
- 다수가 동시에 읽고 쓰는(Read and write) 상황에서의 성능 향상을 위해서.
- 분산 환경에서 노드들이 잘 작동하고 있음에도, 시스템의 일부가 고장나면 데이터베이스를 사용할 수 없게 되는 문제를 해결하기 위해서.
종류
- Key-value
- 가장 단순한 형태의 NoSQL, 값의 내용을 사용한 쿼리가 불가능하다는 단점이 있다.
- 사용자가 키를 사용해 값을 읽어드린 뒤, 어플리리이션 레벨에서 적절히 처리해야 한다.
- Memcached, Riak, Redis, Amazon Dynamo DB, LevelDB
- Document
- Key-value 모델의 진화 형태로 Key-Document 형태로 저장된다.
- Document는 객체지향에서의 객체와 유사하다.
- 객체를 바로 Document형태로 저장하므로 객체-관계 매핑이 없다.
- Document 질의 언어로 Document 내의 값을 이용한 쿼리가 가능하다.
- MongoDB, CouchDB, MarkLogic
- Column-family
- Key에서 필드를 결정하는 남다른(?) 특징을 갖는다.
- 내용을 읽어도 이해가 잘 안간다. ㅡ_ㅡ;;
- HBase, Cassandra, Hypertable
- Graph
- 데이터를 관계와 함꼐 표현하기 위해 디자인된 모델
- 연속적인 노드, 관계, 특성의 형태(그래프 형태)로 데이터를 저장
- 클러스터링에 적합하지 않다
- 특화된 질의 언어로 배우기가 어렵다.
References
잘못된 코드나 내용이 있다면 댓글을 남겨주세요. 즉시 수정하도록 하겠습니다! :)
'database > DB Concept' 카테고리의 다른 글
[DB] 트랜잭션 격리수준 (Isolation Level) (0) 2022.01.31 [DB] 트랜잭션의 장애와 복구 (0) 2021.11.25 [DB] 트랜잭션 (0) 2021.11.23 [데이터베이스]옵티마이저 (Optimizer) (1) 2021.07.13 [데이터베이스] 인덱스(INDEX) (0) 2021.07.12