Presented at the late 2017, to introduce NoSQL

1. NoSQL
발표자: 이 성현

2. NoSQL?

3. Rise of NoSQL
▶ 전통적인 강자 RDBMS
▶ Oracle, MySQL, … 등의 데이터베이스
▶ ACID
▶ Atomicity
▶ Consistency
▶ Isolation
▶ Durability
▶ 이런 강점을 통해 데이터베이스의 안정성과 동시성을 동시에 충족했기 때문
에 많은 사람들에게 여전히 사랑받고 있습니다.

4. Rise of NoSQL
▶ RDBMS… 하지만 단점도 명확!
▶ 관계를 표현하는데 있어서 데이터 타입이 제한됨.
▶ 우리가 memory에서 사용하고 있는 data type은 사실 다양합니다.
▶ boolean, char, int, double…
▶ array, object, structure, class…
▶ method, inheritance, polymorphism
▶ Impedance Mismatch
▶ 정규화???

5. Rise of NoSQL
▶ World Wide Web
▶ Data… Data… Traffic…

7. NoSQL은 무엇인가?
▶ 사실 특별한 정의는 없음.
▶ 관계형 모델을 사용하지 않음.
▶ 클러스터에서 동작이 용이하다.
▶ 대부분 (사실상 거의 전부) 오픈 소스
▶ 웹 환경을 위해 구축되었다.
▶ schemaless

8. Category
▶ Key-Value Model
▶ Document Model
▶ Column-family Model
▶ Graph model
Aggregate orientation!

9. 집합 지향
▶ RDBMS에서 사용할 수 있는 data type
▶ 그 밖에 우리가 사용하고 싶은 data type들..
▶ array, object, class..
▶ NoSQL의 기본 조작 단위에 포함됨.
▶ Replica-set (복제), Sharding의 기본 단위가 되어 집합이라는 것을 자연스
럽게 클러스터링할 수 있다.
▶ 우리가 직접 프로그램을 구현할 때도 집합을 사용하므로 개발자 입장에서
도 데이터베이스를 조작하는 게 더욱 쉬워진다.

10. NoSQL에 대한 고민…
▶ Schema 없이 괜찮은가?
▶ mongoDB를 쓰다보니 NoSQL이 RDBMS처럼 되어 가고 있어!
▶ ACID를 공식적으로 지원하지 않는데, 데이터 일관성을 보장할 수 있는가?

11. Schema 없이 괜찮은가?
▶ 개발자를 믿지 않는 것이 좋다.
▶ Schema가 없다면 production 데이터베이스가 한 순간의 실수로 local 데
이터베이스처럼 되어버릴 수 있다…
Schema가 없다는 건 장점이 아니다.
▶ 스키마를 사용하면 된다.
▶ explicit schema가 아닌 implicit schema로 사용하도록 해도 RDBMS보다
strict하지 않다.
▶ MongoDB의 경우, Schema 안에 MixedField를 설정하여 스키마가 없는
집합을 포함할 수 있다. 집합에 스키마가 없어야 할 경우만 확실하고 개발자
가 알고 있다면 이 방법을 쓸 수도 있다.

12. Schema 없이 괜찮은가?
▶ 스키마를 남발한 예..
▶ 밸런스가 중요

13. 데이터 일관성…
▶ NoSQL는 데이터 일관성이 존재하지 않는다?
▶ 집합 지향의 원자성은 단일 집합에 대해서만 유효하다.
▶ 어떤 집합에 대한 update가 두 건 이상 발생한다면 최대한 연속하여 실행
▶ MongoDB의 경우, replica set에서 write-quorum을 다수로 설정하여 일
관성을 향상시켜
▶ 수 millisecond 단위로 줄일 수 있다면 일관성이 보장된다고 해도 좋을 것이
다.
Inconsistency Window를 줄이자!

14. 일관성 완화
일관성이 없다는 건 정말 catastrophe인가.

15. CAP 정리
- Consistency
- Availability
- Partition tolerance
우리가 쓰는 건,
distributed data system.
-> 그렇다면 Partition tolerance는 만족해야 한다.

16. 복제

17. 샤딩

18. 복제 + 샤딩

19. 끝
감사합니다.