No SQL

거대한 DB의 그룹
니꼬의 설명에 따르면 한국음식 vs 논 한국음식 논 한국음식이 훨씬더 많을거기 때문에 거대한 그룹이다

No SQL 3가지 카테고리

1) Document Db
ex:mongo DB (가장유명함) json으로 저장
내가 원하는 어떤 종류 모양이든 저장가능
SQL은 구조가 엄격

2) Key Value Db
ex
CassandraDb: column wide database 유형 읽고쓰기가 겁나빠름 매우빠름
애플이 카산드라를 통해 저장하고있다.. 많은양의 데이터를 읽고 저장해야된다면 이거 ..

ㅇ
DynamoDb: 서버리스. 분산된 Kay value Db임.. 아마존이 만들었음
듀오링고가 저장하는데 매초 24000의 읽기를 지원
이런상황에서 key value db가 필요 빠르게 읽고 쓸수있게

documnet DB랑 비교해봤을때 어떤종류의 DB를 얻을수있는지 좀더 제한적
SQL에서는 어떤걸 얻어야할지 고민을안함 데이터구조에대해서 고민함

DynamoDb에선 미리 어떻게 할건지 고민해봐야함

엄청난 빠른 속도를 얻었다면 잃는것도 있음 SQL에서하는 쿼리를 할수없다는것
저장하기전에 반드시 어떻게 얻을것인가에 대해 고민해

3) Graph Db

column 이나 documnet가 필요없을때!
각노드 사이의 관계를 알아야할때

주로 소셜네트워크같은걸 만들대 많이 필요
실제로 페이스북이 사용 "TAO db"가 예임

column 이나 document가 아닌 각각의 entity를 저장하고 이를 관계망으로 연결

예를들어 좋아요를 누르거나 공유하거나 태그를하거나..? 이러한정보는 Graph DB에서 더 잘 저장할수있다

결론

우선 수로썬 비교가 안되고
내가 진행하는 프로젝트가 평범하거나 화려하지않다면

거의 대부분 SQL 을 선택한다 요걸로 거의다 커버가능

sql에서 최대한해보고 너무 거대해서 힘이들다면 옮겨가는거..를 생각해보자