y.developer
[TIL] Day 57 SQL과 NoSQL의 차이 본문
2023.12.22 금
NoSQL
Not only SQL 혹은 Not SQL 혹은 Non SQL 이라고 부른다.
그러나 딱 한가지 종류의 DB만을 뜻하지는 않는다.
거대한 DB의 그룹들이라고 생각하면 된다.
마치 한국음식 vs 외국음식(Non한국음식)을 비교하는 것과 같다.
한국음식이 아닌 외국음식은 거대한 카테고리가 될 것이다.
같은 논리가 SQL vs NoSQL에도 적용이 된다.
그렇다면 NoSQL의 종류에는 어떤 것이 있는지에 대해서 알아보자.
대표적으로 3가지의 카테고리가 있다!
1. DocumentDB : MongoDB
- MongoDB
json document 형태로 저장
SQL에서는 데이터의 구조가 꽤나 엄격하다.
그에 반해서 mongoDB에서는 원하는 무슨 형태든 저장가능하고,
또한 데이터가 같은 모양일 필요가 없다.
2. Key-ValueDB : CassandraDB, DynamoDB
- CassandraDB
column wide datavase 유형
읽고, 쓰기가 매우 빠르다
애플이 Cassandra를 이용해서 100 petabyres의 데이터를 저장하고 있고, 넷플릭스, 인스타그램, 우버 같은 회사들도 쓰고 있다.
이런 회사들은 엄청 많은 양의 데이터를 빠르게 저장해야한다.
혹은 검색엔진 처럼 많은 양의 데이터를 빠르게 읽어야할 때에도 사용된다.
-DynamoDB
서버리스, 분산된 Key-ValueDB로서 아마존이 만들었다.
Duolingo(듀오링고:언어학습앱)이 이를 사용하는데 그 이유는 매초 24,000개의 읽기를 지원하기 때문이라고 한다.
이처럼 엄청 빠르게, 많이 써야하고, 많이 읽어야할 때 사용하면 좋다.
Key-ValueDB의 특징으로는 어떤 종류의 DB를 얻을 수 있는지가 제한적이라는 것이다.
저장하기전에 DB에서 무엇을 얻을 것인지 미리 생각해야한다.
예를 들어 SQL에선 데이터의 구조에 대해서 생각을 하지만, 어떤 데이터를 어떻게 얻을 것인지, 어떻게 활용할 것인지 고민하지 않는다.
하지만 Key-ValueDB에서는 저장하기 전에 미리 어떻게 할건지 고민해야한다.
3. GraphDB : Tao, Neo4j
column이나 document가 필요없지만, 노드 사이의 관계를 알아야할 때 사용한다.
- Tao
예를 들면 SNS를 만들 때 사용된다.
실제로 페이스북이 사용하는 수많은 DB중 하나이다.
페이스북은 Tao라는 그들만의 DB를 만들었다.
GraphDB는 각각의 entity를 저장하고, 이를 관계망으로 연결한다.
예를 들어 유저1이 사진1을 좋아요 누르고, 유저1은 유저2의 친구이고, 유저1이 사진1을 공유하고 등등
- Neo4j
SNS를 만들고 있다면 활용해보면 좋겠다.
정리
SQL과 NoSQL을 비교하는 것 자체가 말이 되지 않는다.
NoSQL 종류나 카데고리가 훨씬 많기 때문이다.
그러나 정리할 수 있는 것은 만약 평범한 프로젝트, 화려하지 않은 프로젝트라면 거의 모든 경우 SQL을 선택한다.
왜냐하면 대부분의 경우 SQL로 다 커버가 가능하기 때문이다.
NoSQL은 특별한 경우, 특별한 이슈에 대응하기에 좋은 DB이다.
인스타그램도 처음에는 PostgreSQL로 시작했다. 엄청나게 성장함에 따라 여러 이슈가 발생했고 GraphDB로 변화를 준 것이다.
따라서 처음에는 평범함 SQL로 시작해서 최대한 작업을 해보고, 그런 다음에 나중에 필요하면 그때! 문제를 고칠 수 있는 솔루션을 찾아도 늦지 않다.
이슈가 발생하기도 전에 미리 짐작해서 graphDB를 구축할 필요가 없다고 본다.
하루를 마치며
SQL과 NoSQL에 대한 차이점을 정확히 모르고 있었는데 이번 기회에 정리할 수 있었다.
그리고 보통의 경우 SQL로 작성하게 될 것이라는 것도.
이제부터 DB를 활용할 때 정말 특별한 이유가 처음부터 계획되어 있지 않다면 고민하지 말고 SQL DB를 찾아보자!
SQLite를 자주 사용한다는 추천을 들은적이 있다.
다른 것도 찾아보고 비교해봐야겠다.
오늘의 한 줄
🎄 메리 크리스마스🎄