- 1) NoSQL 이란?
- 빅데이터를 다루기 위해... 스키마에 유연하고, 분산병렬처리가 쉽고, Scale-Out이 되는 DB가 필요해짐.
- 즉, 복잡한 쿼리의 성능을 높이기 보다는~ 중복적인 데이터를 단순하고 빠르게 처리하자!는 컨셉.
- RDBMS 처럼, 정형화된 상황의 완벽함(?)을 추구하지 않음.
- 즉, 비정규화된 데이터를 미리미리 batch 해두어~ 속도적 이점을 최대화.
- 중복 용량적인 단점은 스케일-아웃으로 커버.
- 예) Inverted Search Index : Key-Value에 대응하는 -> Value-Key 데이터를 미리 만들어 두고 활용)
- 각각에 상황에 적합한 다양한 제품들이, 각자의 장단점을 가지고 등장.
- 빅데이터를 다루기 위해... 스키마에 유연하고, 분산병렬처리가 쉽고, Scale-Out이 되는 DB가 필요해짐.
- 2) RDBMS Vs NoSQL
- RDBMS
- 무결성 보장 및 정형화된 데이터 처리.
- 서비스할 데이터에 기반한 모델링. (Entity중심 모델링)
- 정규화(Normalization)을 하되, 때떄로 비정규화를 한다.
- 도메인 분석->Entity간 관계(ER)도출->ERD->Table 생성->Query구현->최적화(Denormalization)
- 개발자가 데이터 모델을 만든 뒤, 고객의 요구사항을 맞춰나가는 방식.
- NoSQL
- 무결성,정합성 보장하지않고, 비정형 데이터 처리.
- 개발할 Application데이터 접근 패턴에 부합하도록 모델링.
- 도메인 분석->Entity간 관계(ER)식별->ERD->Query결과도출->Table 생성->최적화->분산키검토
- 고객의 요구사항을... 맞출수있는 데이터 모델로 대응하는 방식.
- (음... 잘 상상되진 않는다 ㅎㅎ)
- RDBMS
- 3) NoSQL 종류
- Key-Value 모델
- Key-Value 쌍으로 이루어진 HashTable 구조.
- BLOB(Binary Large Object) 등도 지원.
- 대부분 Key으로만 인덱스 처리. (Secondary-Index 지원하지 않는 경우가 많음)
- count, sum, avg 같은 집계함수가 잘 지원 안됨.
- multi-transaction 처리도 잘 지원이 안됨.
- 예) Redis, TokyoCabinet
- Document 모델
- Key-Value 모델을 개념적으로 확장한 것. (경계가 좀 모호함)
- _id 라는 PK가 고정되어 나옴.
- 스키마가 없음. (즉, 스키마 변경에 아주 유연한 특장점)
- 물론, Document 스키마를 빈번히 Update하다보면... fragmentation 이슈로~ 성능저하.
- XML, JSON, BSON등 다양한 형식으로 저장 가능. (Application단에서 타입처리)
- Collection이라는 테이블에 Document라는 데이터로 이루어진 구조.
- (자체 Map/Reduce 등으로 구현된) 집계함수가 잘 지원 됨.
- (RDBMS 유사한) 쿼리, 인덱스, 힌트, 뷰 등등이 지원 됨.
- 대부분 atomic한 수준의 transaction 처리만 지원.
- 예) MongoDb, CouchDB
- Column family 모델
- (Scale-Out이 용이한) 대용량 분산형 데이터베이스.
- 기본적으로 RowKey 기반으로 샤딩(분산) 함.
- Replication-Factor 만큼 복제를 해둠.
- Cassandra는 Multi-Master
- HBase는 NameNode가 Master , DataNode가 Slave (Cyclic Replication)
- 하나의 RowKey에 여러개의 Column[column-key:value]을 Timestamp와 함께 기록.
- 해당 Timbestamp으로 하나의 Column에 어러게의 Version 히스토리를 관리.
- 즉, RowKey에 Column들이 연결되어 집합을 이룸.
- Column 값을 다시 Column 묶음으로 구성 = Column-family (HBase 기준)
- Column 값을 다시 Column 묶음으로 구성 = Super-Column (Cassandra 기준)
- Column의 집합 = Row (Row들은 각자의 RowKey로 구별)
- Row의 집합 = Table (HBase 기준)
- Row의 집합 = Column-Family (Cassandra 기준) (???)
- Cassandra Vs HBase Vs RDBMS 용어
- Keyspace / 없음 / Database
- CF / Table / Table
- RowKey / RowKey / PrimaryKey
- column-key / column-name / column-name
- Tall-Narrow Vs Flat-Wide
- HBase Pheonix는 주로 TN.
- Cassandra CQL은 주로 FW.
- RowKey 와 column-key 를 명시하여 특정 Column을 R/W 함.
- RowKey 와 column-key 의 변화에 취약함.
- Map/Reduce 기능
- HBase 는 Hadoop 과 밀접하게(?) 통합되어 있으니... 당연히 제공됨.
- Cassandra 는 별도의 SDK 기반으로 Hadoop 과 통합 제공됨.
- ACID transaction 요구사항에 취약함.
- 자체적인 집계함수 기능이 약함.
- 예) Cassandra, HBase, Bigtable
- Graph 모델
- Entity 와 Entity 사이의 관계를 저장.
- 관계는, 속성이라는 정보를 가짐.
- 예를들어, "사용자 -(구매)-> 상품" 식으로~ RDBMS와 유사.
- Graph 및 Tree 등의 구조에 최적화. (추천 서비스 같은... 연관성 정보 처리에 적합)
- 관계를 저장하는 DB라... 분산형 성능이 좋지않다.
- 예) Neo4J
- Key-Value 모델
- 4) NoSQL 제품
- Redis
- 휘발성 및 영속성의 특징을 모두 가지고 있음.
- Atomic한 처리로, 데이터 부정합을 예방함.
- 일정한 주기로 데이터의 스냅샷을 보관.
- TokyoCabinet
- 디스크에 데이터 저장.
- 데이터형을 저장하는 방식을 설정가능.
- MongoDB
- 스키마를 자유롭게 정의하려 저장가능.
- json 형태로 구조화된 데이터를 저장.
join이 불가능하기 때문에, 이에맞는 설계가 필요.
- CouchDB
- ...
- Cassandra
- 기본적으로 분산저장을 하도록 설계하여, Scale-Out에 특화.
- 데이터가 크게 늘어나더라도, 속도이슈에 끄떡없도록~
- 영속성과 휘발성 key-value의 혼합설계를 가지고 있음.
- 성능을 우선할경우, 일관성을 희생하는 컨셉임.
- (Ring형 Multi-Master 구조 : 모든 Node가 역할을 하면서, 확장성 및 가용성 뛰어남)
- HBase
- Hadoop의 HDFS를 저장소로 사용함.
- Cassandra 같은 컬럼형 계열이고, 일관성을 보장받을 수 있는 컨셉임.
- (Master-Slave 구조 : Master가 일관성를 보장하면서, HA는 외부 솔루션 커버)
- (하둡계열과 막연히 더 연동 잘될것이라는 편견이 있는데...)
- (카산드라도 Map/Reduce 잘 지원되고, Hive나 Spark등 연동 잘됨ㅎㅎ)
- Redis
- ...
-끝-