No sql 이해 및 활용 공개용

Editor's Notes

• #3 NoSQL을 본격적으로 얘기 하기 전에 약간의 히스토리를 얘기 하겠다. 약간 지겨울수도 있겠지만
• #5  하지만 몇가지 문제 들이 있었죠. 메모리에 저장 되어 있는 변수들.. Relational database 에 맞게 변환을 해야 했습니다. 특정 테이블에 row, column 에 맞게 데이터를 변환을 해야 했습니다. 참 귀찮은 일이죠.
• #6 1980 년 중반에 나온 Relational Database 우리에게 굉장히 익숙한 DB Oracle, Mysql, Mssql 등등이 여기에 속함. Transaction 처리, SQL , Join, Procedure 등 다양한 기능들이 있죠 많은 기업들이 RDBMS 를 적극적으로 사용 했습니다. RDBMS는 정말 좋은 툴이죠 20년 동안 DBMS 에 시장에서 Relational Database 가 독보적으로 사용이 되었죠. 여러분 학교에서도 프로젝트를 한다고 한다면 보통은 Relational Database 를 많이 사용 했을거 같습니다. 1990 년 중반에 Object Database 가 나왔습니다. RDBMS 처럼 테이블에 저장하기 위해 변환을 할 필요가 없었습니다. 메모리에 있는 그대로 넣었으면 되었으니까요. 하지만.. 우리는 Object Database 를 지금까지 써본적도 없을 것이고 제품이 무엇인지 들어 본적도 없을 것입니다.
• #8  많은 트래픽을 감당하기 위해 많은 시도 첫번 째로는 scale-up 을 시도 하게 되죠. CPU 코어수를 늘린다거나, 많은 디스크를 사용하거나 기타 등등 많은 비용이 들어가게 되고 또한 성능을 업그 레이드 할 수 있는 한계가 있음. 그래서 다음 대안으로 sclae-out 비싸지 않은 장비로 확장을 하게 되는 거죠. 대표적인 예는 데이터를 replicate 하거나 sharding 을 하는 것입니다. 물론 Oracle RAC, Microsoft SQL 이 cluster 구성을 할 수 있도록 되어 있긴 하죠.. 엄청나게 비쌉니다. 또한 하나의 디스크 만을 공유 하기 때문에 a single point of failure 이 발생 할 수 있죠,
• #9 각각 다른 데이터 set 를 담당하게 되는 거죠. sharding 이라고 불립니다. 서버의 로드가 id 로 분리 되기 때문에 고르게 받을 수 있음. 장애에 대비하기 위해 master-slave replicationMaster는 write, update만 처리 하고 slave는 보통은 reads만 처리 순간적으로read 장애가 많아 진다고 하면 slave를 더 늘리면 되지만.. 갑자기 write 와 read 가 많아 지는 상황에서 순간적으로 master, slave 간데 데이터가 inconsistency 발생 가능성 있음. consistency의 의미는 commit 한 이후로는 항상 같은 데이터가 조회가 되어야 한다는 의미 인데.. 업데이트가 지연이 될 수 있다. RDBMS의 consistency 는 아주 중요한 요소 입니다. 이거에 대해서는 뒤에서 자세하게 설명 또한 Application 에서 어디로 데이터를 저장할지 써야 할지 알아야 합니다. 일반적으로 modular 연산으로 하게 되죠. 우리한테 이런 구조는 익숙 하지만.. 굉장히 많은 복합적인 문제들을 포함 하고 있습니다.
• #10 뭐 이렇든.. 굉장히 문제 들이 복잡해 지면서 이러한 Google, Amazon 에서는 paper 발간 하게 됩니다. 구글의 BigTable, Amazon DynamoDB 들이 NoSQL이 탄생 에 많은 영향을 미칩니다.
• #11 이제 부터 본격적으로 NoSQL에 대해서 얘기를 해보려고 합니다 high-level view 로 RDBMS 와 NoSQL 차이점을 설명해 보도록 하겠습니다. .
• #12 정보처리 기사 공부 하거나 DBMS 대학교 수업 시간에 처음으로 배우는 거죠. 다시 복습 한다는 차원에서 얘기를 다시 해보겠습니다. RDBMS가 오랫동안 사용될 수 있었던 이유는 ACID 때문이죠.
• #13 RDBMS는 consistency, transaction에 집중을 한다면 NoSQL은 availability에 좀더 집중하고 있다고 생각. NOSQL 은 반대로 BASE 라는 개념을 사용. Basic availability : 많은 NoSQL 이라는 건 클러스터를 사용을 하기 때문에 어느 한 장비가 장애가 발생 하더라도 다른 노드 그 일을 대신 할 수 있게 됨 soft-state : 내가 데이터를 수정 하거나 입력하지 않았는데 데이터는 변경 될 수 있다는 의미에서 soft 라는 단어를 사용 했고요 Eventual consistency 는.. 우리가 RDBMS 가 사용 했다면 사실 이해하기가 쉽지 않을 것 같습니다. update, insert 를 하게 되면 우리는 당연히 데이터는 바로 반영이 될 것이고 어느때나 똑같은 데이터를 조회를 할 수 있다고 생각을 하게 되죠.. 하지만 NoSQL은 클러스터로 묶여 있고 데이터가 분산 되어서 저장이 되기 때문에 잠시동안은 데이터가 inconsistency 할 수 있습니다. 하지만 결국에는 데이터는 일치 하게 되겠죠. 쓸만한 DB 인거냐 생각을 해보면. Join, lock, transaction 이 없기 때문에 굉장히 빨라요. 당연 하겠죠 그 만큼 체크를 해야 되는 것들이 줄어 드니깐요. facebook like, twitter retweet에 적합하다.. Like가 안보인다고, retweet이 안보인다고 문제가 생기지 않는다. 이런 상황은 like 처리 되었다고 빨리 처리 해주고 뒤에서 데이터를 빨리 consistency 하게 만들어 주는 작업이 좋습니다.
• #14  지금 까지 얘기 했던 ACID, BASE 에 대해서 비교를 해보자.. 영어를 볼건 없고 그림만 보아도 쉽게 이해 할 수 있다. ACID에 있는 그림은 굉장히 깐깐하게 보이는 사람이 있죠. 이와 같이 트랜잭션을 사용하고, 데이터는 항상 consistency 해야 하고 이 때문에 테이블을 lock, unlock 을 하는 이런 메커니즘을 사용 하고 있죠. 반면에 Base 는 어느 바다에 해먹 그림 인데요. 굉장히 편안해 보이죠. 트랜잭션을 사용하지 않고 데이터가 일시적으로 inconsistency 해도 허용 하고 lock 을 사용하지 않죠. 하지만 availability 에 중점을 두고 있습니다.
• #16 http://eincs.com/2013/07/misleading-and-truth-of-cap-theorem/CAP는 분산 시스템을 선택할때 도움을 주는 가이드 역할을 한다. 즉 우리 비스지스에 맞게 올바른 database를 선택할 수 있는 가이드 역할을 해준다. CAP가 주장 하는 바로는 CAP 중에 2개만을 만족할 수 있다. Consistency 데이터 일관성을 중요하게 여길 것인가. Availability 장애 상황에서 read/update를 할 수 있는가. Partition Tolerance 이 부분 때문에 논란이 많은데.. 한 노드에서 다른 노드로 메시지가 유실 되어도 용인을 할 것인지에 대한 것이다. 사실 이 상황은 네트워크가 장애인 상황인데.. 이 세상에 네트워크가 장애가 발생하지 않은 네트워크는 없기 때문에.. P는 기본적으로 무조건 들어 가기 때문에 P가 빠진 분산 시스템이 있을 수 없다. 근래에는 PACELC가 맞다고 얘기가 되어 지고 있는데.. 이 것은 장애 상황 일때, 장애 상황이 아닐때를 모드 파악 할 수 있다. Partition 상황일때 Availability/Consistency 상충 되므로 둘 중에 하나만 선택이 되어야 하고, 장애 상황이 아닐 때는 latency/Consistency가 선택 되어야 한다. 뒤에서 설명할 Cassandra는 PA/EL 이다. 장애 상황 일때는 서비스를 최대한 할 수 있도록 초점을 맞추도록 하고 정상 상황 일때는 latency를 위해 consistency를 포기 한다. 모든 노드에 consistency를 위해 업데이트를 하게 되면 latency가 떨어 지게 된다.
• #17 종류 4가지 RDBMS는 종류가 1가지다.
• #18 key, value의 단순한 형태.java 에서 hashMap 자료 구조와 동일함.value 이미지, 문서, PDF, HTML 어떤 것이든 가능 key 는 상품 아이디value 는 상품의 정보가 될 수 있다.
• #20 document db 는 documents 저장 하거나 가지고 올 수 있다. 도큐먼트 형태는 JSON, XML, HTML 어떤 문서이든 가능하다. document는 self-describing 이면서 tree 형태의 자료구조를 가지고 있는 형태 이고, maps, collection 자료 구조를 가질 수 있다. RDBMS 처럼 schema가 있기 때문에 데이터를 empty 혹은 null로 표시를 해야 되지만 document db는 no schema 이기 때문에 그럴 필요도 없고 각 row 마다 데이터가 동일할 필요가 없다. 어떻게 보면 key-value store와 document store를 비슷하게 생각 할 수 있지만 document db는 document 안에 내용을 query를 할 수 있다. key-value는 반대로 불가능 하고 value를 파싱을 해야 함.
• #21  RDBMS 를 사용 한다면.. 상품 정보의 경우 여러 테이블에 나누어서 저장을 하게 되는데 document store 를 사용하게 되면 json, xml 형태로 편하게 저장 할 수 있죠
• #23 테이블은 만들지만 스키마를 깐깐하게 fix 하지 않기 때문에 다양한 형태의 데이터를 저장 할 수 있다. 어플리케이션에서 만들어 내는 로그를 저장할 수 있는데.. 각 어플리케이션 마다 컬럼 정보가 틀리기 때문에 유연하게 저장 하는데.. 사용이 될 수 있고요.
• #26 그러면 왜 우리가 NoSQL 쓰는가 의문을 가질 수 있을거 같습니다. 일반 첫번째 로는 개발하기 쉽다. 예를 들어 guardian, 기사를 통채로 저장한다. rdbms에 저장 하는걸 생각해봐.. 짜증난다. 친구 추천을 생각 한다고 해보자 rdmbs 엄청 복잡하다. graph 를 이용한다고 생각해봐라. 엄청 쉬움. 클러스터로 구성이 되어 있어 single point of failure 에 대비 할 수 있다. 빅데이터 처리가 가능하면서 처리 속도는 굉장히 빠르다. 라는 장점 때문에 NoSQL을 쓰는거 같습니다.
• #28 Cassandra는 Google Big Table, Dynamo 장점만 취했음. PACELC 에서 PA/EL 임 partition 일때 availability에 중점을 두고 장애 상황인 아니면 Latency에 중점을 둔다는 의미 화면에 내용을 엄청 좋아 보임. 몇가지 특징만 얘기 하면
• #29 논리적인 Data 저장소 keyspace - rdbms 에서 database와 동일한 컨셉 keyspace는 table을 포함하고 있다. table을 여러개의 Row 들로 구성 되어 있고 Row는 key-value로 구성된 column 들로 구성. rdbms table-column 구조와 동일
• #39 미래에는 NoSQL이 모든 것을 지배 하게 될까? 그건 아닐 것이다.. 아마도 다양한 polyglot persistence가 생기게 될 것이다. 다시 말해 다양한 DBMS가 서비스에 맞게 사용이 될 것이라는 의미 이다.
• #40 요즘 많이 대두가 되고 있는 microservice, 간단하게 말하면 monolith 싱글 데이터 베이스에 한 프로젝트에 모든 코드를 다 집어 넣는 거죠.. 굉장히 무겁죠. 그 대신에 서비스를 짤개 쪼개서 배포를 빠르게 하고 고객의 요구에 빠르게 대응할 수 있도록 하는 거죠. 각각의 microservice는 각각의 요구사항에 맞게 다양한 NoSQL을 쓰게 되는 거죠.