RDB vs NoSQL 비교 분석

참고 자료
XML 데이터 형식 메서드 http://technet.microsoft.com/ko-kr/library/ms190798.aspx
MySQL http://www.mysql.com/products/community/
MongoDB http://www.mongodb.org/
Cassandra http://cassandra.apache.org/
CAP 이론 http://blog.nahurst.com/visual-guide-to-nosql-systems
Consistency(일관성) : 모든 노드들은 동시에 같은 데이터를 일관되게 유지해야 함
Availability(유효성) : 모든 노드들은 항상 읽기와 쓰기를 할수 있어야 함
Partition Tolerance(파티션 허용) : 시스템은 물리적인 네트워크 파티션을 넘어서도 잘 동작해야 함


MS-SQL 2005
- 상용 라이센스
- Windows
- SQL Server Management Studio(SSMS) 툴 사용
- ODBC API 지원
- 대중적인 RDB로 Table Row(Record) 기반
- MS-SQL2005 부터 XML 지원
- 컬럼내용에 xml 이 저장
- xml 값을 select, update, delete, modify 가능
- xml 의 element 별로 index 처리 가능
- 장점
 : CAP 이론 중 C와A 충족
 : XML 로 데이터를 표현하면 친숙한 RDB 내에서 현재 대용량처리를 위해 주목받고 NoSQL like 기능을 제공
 : Oracle XML 에 비해 API 가 간단하며 직관적이여서 편리하고, 사용 비용이 좀 더 저렴
- 단점
CAP 이론 중 P 불충족
 : 게임 데이터가 급격하게 늘어날 경우 인해 확장이 어려움
 : MySQL XML 은 아직 성능이 현저하게 떨어지고, XML 기능의 범위 또한 제한적(예로, MySQL 은 ExtractValue() / UpdateXML() 하는데 extractvalue 사용시 XML 의 xpath 를 사용하지 못함)
 : 상용으로 비용 발생
 : 리눅스 지원 안함

MySQL 5.1 (Community Edition)
- GPL 상용(Enterprise), 무료(Community)
- Windows / Linux / Solaris / OS X
- SQLyog 툴 지원
- ODBC / MySQL Client API(C/C++/Java...etc)
- 대중적인 RDB로 Table Row(Record) 기반
- XML set / get api 지원
- 장점
 : CAP 이론 중 C와A 충족
 : 무료버전 사용 가능
 : 대중적인 RDB 환경 제공
 : MS-SQL 에 비해 리눅스환경에서 사용가능
- 단점
 : CAP 이론 중 P 불충족(데이터가 급격하게 늘어날 경우 확정이 어려움)
 : Oracle 이나 MS-SQL 에 비해 XML 에 대한 지원 기능이 떨어짐

MongoDB 2.0.2
- MongoDB : AGPL , 커넥터 드라이버는 Apache 2.0 라이센스
- Windows / Linux / Solaris / OS X
- mongo CLI(Command Line Interface) 툴 가능
- mongodb API(C/C++/Java...etc)
- RDBMS 의 대부분 index 지원
- C++ 로 개발됨
- MapReduce 방식의 분산 병렬 처리
- memory mapped db
 : db 의 모든 내용을 OS virtual memory 로 구성하여 paging 여부에 따라 memory <-> disk
 : 32bit mongodb 는 2^32 = 4,294,967,296(4GigaByte) 실제 2.5GB 정도의 데이터 사용가능
 : 64bit mongodb 는 2^64 = 18,446,744,073,709,551,616(18ExaByte) 데이터 사용가능
- disk fragment 방지를 위해 64MB, 128MB, 256MB, .. 1GB, 2GB 등으로 디스크 공간 할당
- 삭제된 데이터 공간은 자동으로 반환하지 않음
 : 예를 들어 100GB 중 50GB 데이터를 삭제해도 100GB 공간을 차직 하고 있음
 : db.repairDatabse() 를 수행하여 정리해야함
- 문서(Document)
 : 문서는 여러개의 필드,필드값 쌍을 가진 단위로 저장,삭제,수정 할 수 있음, JSON 을 바이너리로 인코딩한 BSON 포맷으로 데이터 크기는 4MiB 로 제한
- 컬렉션(Collection)
 : RDB 의 테이블과 유사 개념으로, 네임스페이스로만 의미가 있음
- 데이터베이스(Database)
 : 컬레션을 관리하는 단위
- 장점
 : CAP 이론 중 C와P 충족(master/slave 로 분산 복제로 싱크되어 slave 에서 master 데이터를 똑같이 읽수 있음, Auto-sharding 기능으로 으로 분할 저장 가능)
 : 다양한 클라이언트 라이브러리(C,C++,C#,Java,Javascript,PHP,Perl,Ruby,Python...)를 제공
 : JSON(내부적으로 document 로 불리며, BSON으로 저장) 프토토콜을 사용
 :XML 비해 통신이나 기타 데이터 처리에 있어 빠름
 : XML 은 DOM tree 나 <> 태그등의 오버헤드로 취급될 수 있음
 : 테이블하나에 아주 많은 문서스타일의 데이터를 사용하는 경우에 좋음(예, Log 기록)
- 단점
 : CAP 이론 중 A 불충족 (master 에만 write 할 수 있어 master 에 부하 증가로 write 가 지연될 수 있고 master 장애 발생시 전체 db 를 사용할 수 없음)
 : 메모리와 매핑되는 데이터파일을 사용한다. (즉 main memory 크기를 넘어서는 데이터는 virtual memory (OS가 관리)를 증가시킨다.)
 : 데이터가 머신의 메인 메모리 보다 클 수록 가상메모리를 증가시켜 성능 저하가 발생한다.
큰 데이터를 Insert, Delete 시 성능 저하

Cassandra 1.0.7
- Apache 2.0 라이센스
- Windows / Linux / Solaris / OS X /  기타 JVM 환경
- cassandra-CLI, nodetool 등 제공
- cassandra thrift API(C/C++/Java...etc)
- 구글 bigtable 과 아마존 Dynamo 특징을 토대로 Java 로 개발됨
- Read replica count, write replica count를 설정하여 Availability(유효성)과 Consistency(일관성) 사이의 균형을 사용자가 선택해 사용
 : Write 과정
  1. commitlog -> memtable(memory) -> 일정 threadhold 를 넘어서면 SSTable 로 flush -> SSTable(Disk, 구글의 BigTable 컨셉)
  2. Compaction : SSTable 데이터(key, colunms)를 머지하여 새로운 정렬된 데이터 및 새 인덱스를 생성하는 작업
- Rowkey(1차인덱스), Column(2차인덱스) 을 기본적으로 인덱싱
- 클러스터(Cluster)
 : 여러대의 서버로 구성된 카산드라 클러스터 자체
- 키스페이스(KeySpace)
 : RDB 의 스키마에 해당하는 개념으로 하나의 카산드라 클러스터는 여러개의 키 스페이스를 가질 수 있음
- 칼럼패밀리(ColumnFamily)
 : RDB 의 테이블에 대응하는 개념으로 키 스페이스는 여러개의 칼럼 패밀리를 가질 수 있음
칼럼(Column) : 카산드라에서 저장되는 데이터의 최소 단위이며, 이름, 값, 타임스탬프를 가짐(이름이 키역할을 함)
- 슈퍼칼럼(SuperColumn)
 : 여러 개의 칼럼을 묶어 관리하는 단위이며, 칼럼 패밀리 정의 시 ColumnType=Super 로 명시해야함
- 장점
 : 머지로 인해 여유 공간을 만들어냄
 : disk io 탐색을 줄일 수 있음
 : CAP 이론 중 A와P 충족
 : 현재까지 기존의 RDB 를 대체하는데 가장 적합하여 사용하는 곳이 많음
 : RDB 에 비해 유동적인 데이터 크기를 가져 효율적(Compaction 기능)
 : SSTable(Sorted String Table)에 데이터를 추가후 SSTable 단위로 저장하기 때문에 Write 빠름
 : Column 을 모아 저장하는 Column oriented DB 라서 연관된 데이터를 읽기에 적합
 : 장비추가의 과정이 단순 (새로운 장비를 추가하고 설정을 바꾼 후 cassandra 재시작)
- 단점
 : SuperColumn 안의 컬럼은 인덱스 지원 안됨
 : CAP 이론 중 C 불충족 (성능을 높이면 Consistency 가 낮아짐)
 : thrift 와 같은 rpc frame work 를 사용해서 클라이언트 개발
 : 조금 생소한 컬럼베이스
 : Java 로 만들어져 JVM 이 설치되어 있어야함

comments:

댓글 쓰기