NoSQL 대 SQL, 그리고 빅데이터
본 게시글은
'NoSQL 프로그래밍
Professional NoSQL : A hands-on guide to leveraging NoAQL Databases'를 읽고 정리한 글입니다.
해당 서적은 NoSQL 입문서로
기존 SQL과의 비교가 잘 되어있다.
NoSQL 개념이 왜 등장했고
왜 빅데이터와 관련있는지
NoSQL, SQL의 차이점을 각 실습 파트의 초입부에 설명하면서 잘 와닿게 설명하고있다.
다만 2013년에 출판된 책인만큼
24년의 기술과 차이를 생각하면서 읽는 것이 좋다고 생각한다.
SQL이 취급하는 데이터, NoSQL이 취급하는 데이터
RDBMS-SQL 제품에서는 다루는 데이터는
- 잘 정의된 구조 : 테이블 생성 이후 스키마 변경이 거의 없어야함.
- 데이터의 속성 미리 정의할 수 있어야하며
- relation을 통해 정합성과 일관성을 유지한다.
의 특징을 가지고 있는데
다루는 데이터의 속성이 위와 같지 않을 때에는 제 기능을 다하지 못한다.
구조가 잘 정의되어있지 않은 데이터의 처리에 대해서도
rdbms로 처리할 수 있지만 희소성 데이터가 많을 때 사용하기 더 힘들어진다.
( 데이터베이스에서 희소성 데이터란
많은 레코드의 데이터 필드값이 없는(NULL로 기록된) 파일을 뜻한다. )
유튜브 동영상을 업로드 할 때
동영상 제목만 기입하고 업로드를 실행했을경우를 예로 들어보자.
동영상 자체는 rdbms가 아니라 인코딩을 수행하는 전용 미디어 서버가 수행할 것이다.
메타데이터 정보에 대해서 제목 이외의 column에는 전부 null값이 삽입되거나
일부 string 타입의 column에 한해서 빈칸을 기본값으로 부여할 수 있을 것이다.
이를 rdbms의 테이블의 삽입한다 가정하면
제목 이외의 칼럼엔 전부 null이 들어가야할 테지만
정합성을 중요시 여기는 rdbms에서는 null값이 과도하게 많은 테이블은
에러를 유발하기 쉽고 null이 많은 필드는 참조 키로서 역할을 할 수 없는 등
문제가 많다.
위와 같은 단점(?)을 보완하기 위해
rdbms를 좀 더 유연하게 활용할 수있지만
비정규화, 제약을없애고, 트래잭션 제약을 느슨하게 하면
이는 더 이상 rdbms가 아니고
nosql 제품을 닮은 무언가가 되어버린다.
( 단점이라기 보다는 애플리케이션에 부적합한 제품을 적용했다고 생각한다. )
반면 NoSQL 제품에서 다루는 데이터는
스키마 없는 데이터 저장소를 지향하므로 변화가 쉽고 자연스럽다.
이 유연성에 대해서는 마찬가지로 대가가 따르는데
(정합성-유연한 인덱싱-'강력한' 쿼리) 기능을 제공하지 못한다.
글에서 말하는 '강력한'의 범위는
사용 도메인과 개발자마다 다를 것이라고 생각한다.
글쓴이는 NoSQL에서 가장 부족한 기능 중 하나가 바로 쿼리 기능이라고 했으며
제품 벤더들이 이 기능을 보충하기 위해 노력중이라고 한다.
게시글을 작성하는 24년 9월 시점에서는
각 NoSQL 제품별로 많은 기법이 추가되었을것으로 예상한다.
이 장을 정리하자면
"애플리케이션에서 취급하는 데이터의 특성과 도메인을 파악하고
적합한 제품을 적용해야한다."
그래서 어느 애플리케이션에 NoSQL을 적용하는 것이 좋은가? 빅데이터
NoSQL의 탄생 배경이 곧 적용 분야를 알려주고 있다는 생각이 들었다.
NoSQL과 함께 언급되는 키워드 중에는
대용량 데이터, 병렬 처리, 확장 가능한 인프라...이런 것들이 있다.
이 키워드들은 모두 <빅데이터>
보통 수테리바이트를 넘는 데이터셋은 빅데이터로 분류한다고 한다.
데이터는 여러 개의 물리적 저장소에 저장되는데
샤딩을 이용한다 해도 rdbms 기법으로는 처리에 한계가 있다.
기업에서 취급하던 일반적인 데이터가
- 데이터의 크기가 증가
- 데이터의 소스가 다양화
되면서 반구조, 비구조화된 데이터 형태로 변화했기 때문이다.
그리고 반구조, 비구조화된 데이터는
- 스키마 데이터, 메타데이터 분리가 어렵고
- 장애 허용 능력과 백업에 대한 추가 요구
- 효율적인 저장, 대용량 데이터 접근이 어려워짐
의 특징을 띄면서
저장 및 조회, 수단에 있어서
기존 방식을 뛰어넘는 새로운 접근 방법이 필요성이 대두한다.
이 새로운 접근 방법을 얘기할 때 Google을 얘기하지 않을 수 없다.
구글은
- 분산 파일 시스템
- 칼럼 패밀리 지향 데이터 저장소
- 분산 조율 시스템
- 맵리듀스 기반 병렬 알고리즘 실행환경
등의 메커니즘을 공개했는데
Nosql은 구글의 하둡 프로젝트로 인해 빠르게 성장했다.
빅데이터 애플리케이션의 수평 확장성에 따른
병렬 프로그래밍 모델
참고 : 저장 매체는 HDD, SSD 할 것 없이 문제가 생긴다
SSD는 디스크를 회전하며 접근하는 방식의 HDD보다
빠른 접근 속도와 IOPS 수치를 제공하지만
버그, 비용 문제가 있고
SSD 또한 사용할수록 각 셀의 R/W 수명이 줄고
디스크가 점점 채워짐에 따라 접근 속도가 줄어드는 것은 마찬가지다.
수직확장성-수평확장성
빅데이터를 취급하는 저장소 아키텍쳐를 떠올리면
수직 확장대신 수평 확장을 채택하고 있다.
저장소의 디스크의 접근 속도가 곧 데이터의 R/W 속도를 결정하기 때문에
하나의 큰 저장소보다는 여러 데이터 단위에 걸쳐 데이터를 저장하는 것이 낫다.
(읽을 데이터에 접근, 수정할 데이터에 접근)
부하가 늘어남에 따라,
수평 확장은 부품 스펙을 높이는 수직정 확장 대신
비슷한 시스템 스펙의 노드를 추가한다.
이를 "클러스터의 스케일을 변경"한다고한다.
수평 확장했다고해서 저절로 데이터의 CRUD가 이루어지지는 않는다.
수평확장이 적용되기 위해서는
수평적 클러스터상에서 노드가 추가됨에 따라
데이터가 처리되는 적절한 방식이 필요한데
바로 맵리듀스 모델이다.
맵 &. 리듀스 inspired by 함수형 프로그래밍
map, reduce는 함수형 프로그래밍에서 쓰는 함수다.
함수형 프로그래밍
- 원본 데이터를 수정하지 않는 방식을 고수한다.
- 프로세스나 스레드 사이에서 데이터를 공유하기를 꺼린다.
(서로 간섭을 하지 않는다)
map은
자료구조의 각 요소별로 작업을 수행하거나, 함수를 적용한다.
reduce는 fold, accumulate, compress, inject라고도 불리는데
데이터 구조의 모든 요소에 함수를 적용하고 하나의 결과를 생산한다.
key/value 쌍이나 tuple collection에 적용할 수 있다.
이 장을 정리하자면
"Nosql은 빅데이터를 처리하기 위해 고안된 모델이고
아키텍쳐의 수평적 확장에 기반을 둔다."
"많은 Nosql 제품이 데이터 처리를 위해 구글의 맵-리듀스 모델에 의존한다."
맵 리듀스에 대한 특징에 따른 처리량 증가,
제품별 nosql 모델과 구현 특징 등에 대해서는 공부가 덜 돼서
다른 포스팅에서 정리 예정입니다.
댓글
댓글 쓰기