새벽에 남은 사람들끼리

목요일까지 함께한 6조

새로 시작한 5조. 3주째 맨 구석 6조였다가 드디어 벗어났다.

이번주 한일 및 회고

@ 숙련주차 과제를 마무리했는데 이제야 뭔가 node.js를 하고 있는 것 같은 느낌이 들었다.
@ 사이드 프로젝트로 하고 있는 브로콜리가 엎어졌다. 프론트엔드분이 매우 어려워 하셔서 어쩔 수 없었다. 하지만 서로가 열심히 해왔던 걸 잘 알기에 훈훈하게 끝이 났다.
@ 이번 주도 꽤나 공부 시간을 채웠다. 그냥 기념용 캡쳐.

@ 알고리즘 공부도 계속 하고 있는데 이번에 푸는 DFS와 BFS 문제들이 너무너무 어려워서 이번주에 다 해결하지 못했다. 1개도 겨우 가까스로 풀었다. 알고리즘은 꾸준히 감각을 익혀둬야 문제 이해나 어떻게 풀지 접근법이 잘 떠오는게 아닐까 생각이 들었다.
@

NoSQL과 SQL

noSQL은 Not only SQL 혹은 Not SQL이다. 즉, 어떤 한가지 DB를 지칭하는 것이 아닌 SQL이 아닌 여러가지를 뭉쳐서 지칭하는 것이다.
SQL은 서로 조금씩 달라도 거의 비슷하지만 noSQL은 다음과 같이 서로 완전히 다른 여러가지가 포함된 개념이다.

NoSQL

DocumentDB

documentDB에서 가장 유명한 것은 mongoDB가 있다. mongoDB는 데이터를 json document 형태로 저장한다. 데이터의 구조가 꽤나 엄격한 SQL과 달리 어떤 형태의 데이터든지 다 저장할 수가 있다.

Key-valueDB

CassandraDB는 Wide-ColumnDB이기도 하다. 읽고 쓰기가 매우매우 빠르다. 애플은 카산드라를 이용해서 10페타바이트의 데이터를 저장하고 있다. 엄청나게 많은 양의 DB가 필요하거나 검색엔진같은 경우에 카산드라가 필요하다.

또다른 KeyvalueDB로는 DynamoDB가 있다. 다이나모는 아마존이 만든 서버리스, 분산된 key-valueDB이다. 이것 또한 매우 빠르다.

Key-valueDB를 mongoDB와 비교하면 DB에서 어떤 것을 얻을지가 제한적이라고 할 수 있다. 설계할 때 미리 저장한 것을 어떻게 접근할지 고민해야 한다.

GraphDB

coulumn이나 document가 필요 없을 때 그러나 각 노드 사이 관계를 알아야할 때 쓰는 DB 모델이다. 페이스북같은 소셜네트워크를 만든다면 graphDB가 필요하다. 페이스북은 Tao라는 자신만의 DB를 만들었는데 이것이 바로 GraphDB이다. GraphDB는 각가의 entity를 저장하고 이를 관계망으로 연결한다.

또다른 graphDB의 예시로는 neo4j라는 것도 있따.

NoSQL vs SQL

NoSQL은 종류가 매우 다양하므로 이렇게 비교하는 것 자체가 말이 되지 않는 것이다.
그냥 평범한 프로젝트를 한다면 거의 모든 경우 SQL을 선택할 것이다. 왜냐하면 대부분의 경우 SQL로 다 커버가 가능하기 때문이다.
NoSQL은 특별한 경우, 특별한 이슈에 대응하기에 좋은 DB들이다.
인스타그램도 처음에는 PostgreSQL로 시작하였지만 엄청나게 성장하면서 graphDB로 옮겨야 했다.
처음에는 그냥 SQL로 시작해서 최대한 해보고 나중에 필요해지면 문제를 고칠 수 있는 솔루션을 그때 찾아도 늦지 않다.