1. 접근방법기준에 따른 분류
1.1. CAP
1.1.1. CA
1.1.1.1. Postgres
1.1.1.2. MySQL
1.1.2. CP
1.1.2.1. MongoDB
1.1.2.2. BigTable
1.1.3. AP
1.1.3.1. Cassandra
1.1.3.2. CouchDB
1.1.3.3. Dynamo
1.1.3.4. SimpleDB
1.2. 분산
1.2.1. 분산형
1.2.1.1. CouchDB
1.2.1.2. MongoDB
1.2.1.3. Cassandra
1.2.2. 비분산형
1.2.2.1. Amazon SimpleDB
1.3. 데이터모델의 풍부함
1.3.1. Key-Value Store
1.3.1.1. Amazon Dynamo
1.3.1.2. Amazon S3
1.3.2. Document Store
1.3.2.1. Amazon SimpleDB
1.3.2.2. CouchDB
1.3.2.2.1. Erlang으로 작성
1.3.2.2.2. 데이터와 스토리지 모델
1.3.2.2.3. View 함수는 View를 쿼리했을때 실행. Map, Reduce 함수 존재
1.3.2.2.4. 복제-다중마스터를 지원. 마스터 슬레이브를 갖으며 오직 최신의 리비전만 복제
1.3.2.2.5. 멀티마스터 충돌 핸들링-충돌을 탐지하고 winner를 선택키 위해 결정론적인 알고리즘 사용. winner는 기대한 마스터가 아닐 경우 애플리케이션에서 스스로 고쳐야함
1.3.2.2.6. 파티셔닝과 로드 밸런싱- CouchDB Lounge 에 의해 제공
1.3.2.2.7. Apache 2.0 라이센스
1.3.2.3. MongoDB
1.3.2.3.1. C++로 작성
1.3.2.3.2. 데이터 모델
1.3.2.3.3. 스토리지
1.3.2.3.4. 쿼리
1.3.2.3.5. 배치 오퍼레이션:컬렉션에 Map-Reduce를 지원
1.3.2.3.6. 복제:마스터-슬레이브 모델(복제쌍)
1.3.2.3.7. 파티셔닝
1.3.3. Column Store
1.3.3.1. Cassndra
1.3.3.1.1. Column-family(BigTable) 데이터 모델 + Dynamo 분산아키텍쳐
1.3.3.1.2. Java로 작성
1.3.3.1.3. 데이터 모델
1.3.3.1.4. 파티셔닝
1.3.3.1.5. 퍼시스턴스
1.3.3.1.6. 쓰기
1.3.3.1.7. 읽기
1.3.3.2. Big Table
1.4. 저장
1.4.1. Memory
1.4.2. Configurable
1.4.2.1. Big Table
1.4.2.2. Cassandra
1.4.3. Disk
1.4.3.1. CouchDB
1.4.3.2. MongoDB
2. 왜 비관계형 인가?
2.1. 관계형은 확장 어려움
2.1.1. 복제에 의한 확장
2.1.1.1. Master-Slave 구조에선 읽기는 빠르지만 쓰기는 제한적임(병목현상)
2.1.1.2. 다중 마스터 구조에선 마스터 추가로 쓰기 성능 향상 가능 하지만 충돌의 위험 생김
2.1.2. 분할에 의한 확장
2.1.2.1. 읽기만큼 쓰기도 확장 가능하나 애플리케이션 레이어에서 파티셔닝을 인지하고 있어야 함. 쉽지않음
2.2. INSERT-only 시스템
2.2.1. 문제점1. 종속에 대한 트리거를 이용할 수 없음
2.2.2. 문제점2. 쿼리가 비활성 데이터를 걸러야함
2.3. UPDATE와 DELETE
2.3.1. 정보손실의 이유로 잘 사용되지 않음
2.3.2. JOIN
2.3.2.1. 비용이 많이듬
2.3.2.2. 반정규화로 비용 줄일 수 있으나 UPDATE DELETE 시스템에선 어려움
2.3.3. ACID 트랜젝션
2.3.3.1. 원자성
2.3.3.1.1. 단일키 원자성이면 충분
2.3.3.2. 일관성
2.3.3.2.1. 엄격한 일관성 필요없고 결과으이 일관성을 가질 수 있음
2.3.3.3. 격리성
2.3.3.3.1. 읽기에 최선을 다하는것 이상의 격리성은 필요치 않으며 단일키 원자성이 더 쉬움
2.3.3.4. 지속성
2.3.3.4.1. 실패시도 데이터가 유지되는 지속성 필요
2.3.4. 고정된 스키마
2.3.4.1. UPDATE DELETE 시스템은 테이블 락이 필요하기 때문에 스키마 수정이 어려움
2.4. 대부분 디스크 기반이기 때문에 빠른 응답 기대키 어렵다
3. CAP 이론
3.1. 이해도
3.1.1. RDBMS는 CA에 집중
3.1.2. 웹발전에 따라 다양한 요구사항 때문에 P의 특성 강조됨
3.2. 시스템에서 보장해야 하는 특징
3.2.1. 유효성
3.2.1.1. 모든 노드는 항상 읽기와 쓰기를 할 수 있어야 합니다.
3.2.2. 일관성
3.2.2.1. 모든 노드들은 동시에 같은 데이터를 보여야 합니다.
3.2.3. 파티션 허용치
3.2.3.1. 시스템은 물리적인 네트워크 파티션을 넘어서도 잘 동작해야 합니다
4. 확장성을 해결기위해 No SQL을 선택함
5. 특장점
5.1. 높은 확장성
5.2. 높은 Availability
5.3. 높은 성능
5.4. 원자성
5.5. 일관성
5.6. 지속성
5.7. 배포의 유연함
5.8. 쿼리의 유연함
6. 사례
6.1. 해외
6.1.1. Google
6.1.1.1. BigTable
6.1.1.2. 모든 URL 기반의 문서정보 수집(key/value 기반의 BigTable에 저장)
6.1.1.3. 수집한 정보를 Map/Reduce로 색인(색인 데이터도 BigTable에 저장)
6.1.1.4. 도큐먼트에서 사용하는 정보가 계속 추가될 수 있다.
6.1.2. Digg.com
6.1.2.1. Cassandra
6.1.2.2. 내 친구가 추천한 정보를 보여주기 위해
6.1.3. Amazon
6.1.3.1. Dynamo
6.1.4. Twitter
6.1.4.1. 모든 사용자의 글을 하나의 DB에 저장할 수 없다면 내가 팔로우 하는 timeline은 어떻게 보여줄 수 있을까?
6.2. 국내
6.2.1. NHN 인증 플랫폼
6.2.1.1. 요구사항
6.2.1.1.1. backend DB 점검시에도 Read가 가능한 시스템
6.2.1.1.2. 로그인 사용자 세션정보를 저장 및 조회
6.2.1.2. 구현
6.2.1.2.1. MySQL 클러스터링으로 세션 정보 저장(MySQL을 메모르 DB로 사용)
6.2.1.2.2. in-house 메모리 DB로 사용자 정보 저장(Oracle 로그 기반으로 메모리 리플리케이션)
6.2.2. Daum view 추천 플랫폼
6.2.2.1. 사용자의 추천을 모두 수집
6.2.2.2. 소셜 네트웤을 저장
6.2.2.3. 추천정보를 추천히스토리와 소셜 네트워크 기반으로 Map/Reduce 분석
6.2.2.4. 신뢰도 높은 추천 기반으로 문서 랭킹 부여
6.2.3. Daum Cafe
6.2.3.1. 최근방문카페기능
6.2.3.2. Cassandra