NoSQL Flashcards
NoSQL 데이터 모델
[정의] 대용량,비구조적, 실시간 처리 특성을 갖는 빅데이터를 효과적 처리 위한 NoSQL 테이블 설계 구조
[모델링 원칙] Denormalization, Aggregation, Application Join
* 모델링 원칙 기반, 빅데이터 활용에 최적화한 다양한 데이터 모델 제공
[데이터 모델]
1. Key-Value Oriented : Redis, Dynamo, 리악
- Key를 이용해 value에 접근하는 구조
- 어떠한 형태(List, Set, Hash, String 등)의 데이터든 저장이 가능
2. Document Oriented : MongoDB, CouchDB
- 테이블의 스키마가 유동적, 즉 레코드마다 각각 다른 스키마를 가짐
- 보통 XML, Binary JSON과 같은 Document를 이용해 레코드를 저장
3. Column Family Oriented : HBase, Cassandra, 하이퍼테이블
- 두 단계의 집합(Map) 구조. Row Key에 다수의 column&value가 들어감
- Row key로 자동정렬, column key로 자동정렬 가능
4. Graph Model : Neo4J, orientDB, Hypergraph DB
- Entity와 Entity 사이의 관계를 저장
[차별화] NoSQL 모델과 RDBMS 모델의 차이점
- 모델링 절차 : Query → 테이블 설계 / 테이블 설계 → Query 설계
- 주요 활용 기법 : 비정규화 / 정규화
- 설계 중점 사항 : Query 효율성 / 데이터 일관성
- 고려 사항 : Join, Sorting, Grouping등 기능 제약 / I/O 비용
* 모델링 과정은 상이하나 공통적으로 도메인에 대한 정확한 분석이 선행되어야 최적의 설계 가능
NoSQL 모델링 패턴
[기본적인 데이타 모델링 패턴] = 원칙
- Denomalization : 데이터를 중복 허용, 같은 데이터를 여러 문서/테이블에 복제 (질의 처리 I/O 감소)
- Aggregation : 유연한 스키마 허용, 엔티티 구조 다양화, 1:N관계 최소화 (Join 연산 감소)
- Application Join : Join 기능이 필요한 경우 Client App단에서 Join 로직 처리 (Server Side 연산 부하 감소)
[확장된 데이타 모델링 패턴]
- Atomic aggregation : 테이블 병합 (데이타의 일관성 문제 해결)
- Index Table : 별도의 Index 테이블 생성 (검색 성능 향상)
- Composite Key : 하나 이상의 필드를 deliminator를 이용하여 구분지어 사용 (RDBMS의 복합키 개념)
- Inverted Search Index : value의 내용을 key로 하고, key의 내용을 반대로 value (검색 엔진에서 활용)
NoSQL
테이블 컬럼 스키마 없이 분산 환경 key-value기반,검색, 추가 작업 용이,base특성,비관계성,조인 불가,유연한 스키마,c+p,a+p,ft,schema less,수평적확장
NoSQL 모델링 패턴 및 절차
[NoSQL 정의] 대용량 처리, 분산 환경 결함 수용 및 비구조적 데이터 처리 통한 RDBMS 한계 보완, 빅데이터 환경의 신속하고 효율적 처리 최적화 데이터베이스 시스템 기술
[모델링 원칙]
- Denomalization, Aggregation, Application Join
[모델링 절차] (도Q모리 테스트 최적화)
1. 도메인 모델 파악 : 도메인(시스템) 파악, 저장 대상 데이터 식별 (ERD)
2. Query 디자인 : Application 쿼리 결과 값 선정 (데이터 출력 화면, Query, 논리 테이블 구조)
3. 패턴기반 모델링 : Put(key, value), Get(key) 기반 테이블 재정의 (Key-Value 테이블 구조)
4. 최적화 필요기능 리스팅 : Application 및 데이터 특성 기반 상세/최적화 (Key-Value, Key-Document)
5. NoSQL 테스트 : 부하, 안전성, 확장성 테스트 검증 (카산드라, 몽고DB, 레디스)
6. 모델 최적화 및 H/W 설계 : 데이터 모델 최종 최적화, App I/F 및 H/W 설계 ( I/F, 하드웨어 설계서)
[차별화] NoSQL 모델링 vs RDBMS 모델링
- 모델링 절차 : Query 설계 → 테이블 설계 / 테이블 설계 → Query 설계
- 주요 활용기법 : 비정규화 / 정규화
- Query 중점 사항 : Query 효율성 / 데이터 일관성
- 고려사항 : Join,Sorting, Grouping등의 기능 제약 / I/O 비용
- 활용사례 : 통계, 로그 모니터링 / ERP, 금융
NoSQL BASE
[정의] NoSQL에서 가용성과 성능을 중시하는 특성
[특성]
- 가용성(Basic Available) - 언제라도 접근, 가용성 중시
- 독립성(Soft-state) - 특정 시점에서 일관성 보장 되지 않음
- 일관성(Eventually Consistency) - 일정 시점후 일관성 유지
CAP이론
[정의] 분산 시스템이 갖추면 좋은 특징 C, A, P를 말하며, 세 가지 중 2가지 특성 보유 가능 이론
[이론]
- 일관성(Consistency) : 모든 데이터가 같은 시간에 같은 데이터
- 가용성(Availability) : 노드가 다운되어도 다른 노드에 영향 없음
- 파티션 허용성(Partition Tolerance) : 일부 메시지 손살에도 시스템은 정상 동작
[분류]
- C + A : 미션크리티컬, 금융 서비스 적합 (RDBMS,Oracle, MySQL, MS-SQL)
- C + P : 대용량 분산파일 시스템에 적합 (몽고DB, Hbase, Radis)
- A + P : 비동기화 서비스, SNS 서비스에 적합(카산드라, 다이나모, CouchDB)
* 네트워크 파티션 상황을 가정시 CA경우는 분산환경에서 존재불가 CASE 발생 → PACEL 이론
pacelc.이론
[정의] 장애상황(Partition)과 정상상황(Else)을 모두 고려한 NoSQL 특성 설명 통한 CAP 이론의 한계점 극복, 분산 데이터베이스 시스템 분류 이론
[CAP 한계점]
1. 생존성(P) 선택을 배제한 C+A의 경우 NW 장애(메시지 손실) 발생가능성 Zero 가정
→ 분산 환경에서 존재할 수 없는 Case
2. P를 전제로 C+P, A+P 조합만 가능 → 장애 상황에 국한된 한계 존재
[개념도] AC + Partition(장애 상황) + Else(정상 상황) + LC (Latency, Consistency)
[유형]
1. PA/EL(카산드라, DynamoDB): 장애시 가용 노드만 반영, 복구 시 전체 반영, 정상상황시 Latency 우선고려
2. PA/EC(Hazelcast IMDG, 몽고DB):동일, 정상 상황 시 모든 노드 동일 메시지 보장
3. PC/EL(PNUTS): 장애 상황 시 Timeline Consistency 수준 보장, 정상 상황 시 Latency 우선 고려
4. PC/EC(HBase, VoltDB): 장애상황시 일관성 우선보장, 정상 상황 시 모든 노드 동일 메시지 보장
NoSQL
[정의] 벡터 임베딩, 인덱싱 기반 벡터 유사성 활용, 고차원 데이터의 저장 최적화 및 검색 효율성을 향상 목적 특화 데이터베이스
[파이프라인]Vectors -> Indexing -> vector database -> Querying -> Post Processing
[기술요소]
1) 벡터 인덱싱 알고리즘: 벡터 색인화를 통한 빠른 검색 지원. 양자화(PQ)/해싱(LSH)/ 그래프기반(HNSW) 등
2) 쿼리 유사성 측정 알고리즘: 인덱스 벡터와 쿼리 벡터 비교 통한 최적 정보 검색. 코사인/유클리드/내적, ANN/KNN 등
3) 후처리 Filtering: 메타데이터 기반 최근접 항목 필터링. Post-Filtering
[활용방안]
할루시네이션 제거
NoSQL 데이터 모델
- Key-Value Oriented : 레디스, 리악, 다이나모
- Key를 이용해 value에 접근하는 구조
- 어떠한 형태(List, Set, Hash, String 등)의 데이터든 저장이 가능 - Document Oriented : MongoDB, CouchDB
- 테이블의 스키마가 유동적, 즉 레코드마다 각각 다른 스키마를 가짐
- 보통 XML, Binary JSON과 같은 Document를 이용해 레코드를 저장 - Column Family Oriented : HBase, 카산드라, 하이퍼테이블
- 두 단계의 집합(Map) 구조. Row Key에 다수의 column&value가 들어감
- Row key로 자동정렬, column key로 자동정렬 가능 - Graph 모델 : Neo4J, orientDB, Hypergraph DB
- Entity와 Entity 사이의 관계를 저장
