728x90
다시 정리할 겸.
데이터엔지니어로 회사의 스택들을 보면 nosql보다는 sql쪽이 훨씬 많이 보이긴 한다. 계속 관계형 디비를 사용해와서 새로운 DB로 바꾸는 비용을 들이고 싶지 않아서 일수도 있을 것 같기도 하고. 분석쪽은 sql을 주로 많이 이용하니 다른 팀과의 데이터사용을 고려해서 관계형 디비를 사용할 수도 있을 것 같고.. 일관성 때문에 유연성이나 스케일아웃 문제에도 불구하고 sql을 더 쓰는걸까.
데이터 저장하면서 스케일 아웃이 필요한 시기가 있을 것이고 관계형DB는 스케일아웃에는 적합치 않다 들었는데. 어떻게 처리하고 있는걸까? 데이터레이크 쪽은 nosql로 하고, elt 작업으로 처리한 분석을 위한 데이터는 sql을 사용하고. 그런걸까?
-> 생각해보면 sqldb의 데이터가 얼마 이상이고 튜닝상태가 어떤지에 반응이 달라질테니..정말 데이터를 많이 쌓는 곳에선 어떤 디비를 쓰는지 궁금하구먼.
NoSQL이란
- NoSQL → Not only SQL 혹은 Non SQL이라고 해석
- 관계형 테이블과 다른 방식으로 데이터를 저장한다.
- 물론 관계형 데이터도 저장할 수 있다. No라는 말에 오해 금지. 오히려 SQL보다 관계 데이터 모델링하는게 쉬움. 테이블 분할 안 하고 집어넣으면 되니까. 관련 데이터를 단일 데이터 구조 내에 중첩시킬 수 있음 (json구조니까..)
- NoSQL DB는 데이터 모델에 따라 주로 문서, 키-값, 와이드컬럼, 그래프가 있음.
- 유연한 스키마를 제공하며, 대량의 데이터와 높은 사용자 부하에서도 손쉽게 확장이 가능하다.
- NoSQL은 2000년대 말 스토리지 비용이 크게 하락하면서 등장했음. 단순히 데이터 중복 감소를 목적으로 복잡하고 관리가 어려운 데이터 모델을 생성해야할 필요가 없다. 스토리지가 아니라 개발자들이 소프트웨어 개발의 1차 비용이 되었기 때문에 NoSQL DB는 개발자 생산성에 맞게 최적화되었음.
- 저장 및 쿼리를 위해 필요한 데이터 앱의 양도 증가했다. 이러한 데이터는 정형, 반정형, 다형적 등 모양과 크기가 모두 다르기 때문에 미리 스키마를 정의하는 것이 거의 불가능해졌다. NoSQL DB는 개발자가 엄청난 양의 비정형 데이터를 저장할 수 있도록 지원하여 뛰어난 유연성 제공
- 애자일 개발방식 → 변화하는 요구사항에 빠르게 적응해야 함 → DB모델에 이르기까지 소프트웨어 스택 전반에서 반복작업과 변경을 신속하게 수행할 수 있는 능력 필요. NoSQL은 이런 유연성 제공
- 클라우드 컴퓨팅 역시 인기가 높아졌고, 개발자들은 퍼블릭 클라우드를 사용해 애플리케이션과 데이터를 호스팅하기 시작 → 여러 서버와 리전에 데이터를 분산시켜 애플리케이션 복원력을 높이고, 스케일업이 아닌 스케일아웃을 수행하며, 데이터를 지능적으로 배치할 수 있기를 원함. → 몽고DB같은 일부 NoSQL DB들이 이러한 기능 제공
NoSQL 데이터베이스 유형
- 문서데이터베이스
- JSON 객체외 비슷한 문서에 데이터를 저장. 각 문서에는 필드와 값의 쌍이 포함되어 있음, 일반적으로 값은 문자열, 숫자, boolean, 배열, object 등 유형이 다양할 수 있으며, 구조는 개발자가 코드에서 사용하고 있는 객체에 맞춰 조정된다.
- 어플리케이션에서 사용되는 데이터 오브젝트와 비슷하기 떄문에 앱에서 사용할 때 더 적은 트랜잭션이 필요하다. 그에 비해 SQL에서는 데이터를 합치고 나누고 하는 작업을 해야 함.
- 대량의 데이터를 수용하도록 수평 스케일아웃이 가능
- DB-engines 사이트 랭킹 보여줌. (그렇다 이전에 그래프DB 볼 때도 여기서 참조했다.)
- 키-값 데이터베이스
- 각 항목에 키와 값이 포함되어 있는 보다 간단한 유형의 데이터베이스. 값은 보통 기를 참조하는 방식으로만 검색이 가능하기 때문에 일반적으로 특정 키-값 쌍에 대해 쿼리를 수행하는 방법을 간단히 익힐 수 있다.
- 대량의 데이터를 저장해야 하지만 검색을 위해 복잡한 쿼리를 수행할 필요가 없는 사용 사례에 적합
- 사용자 선호도 저장 쇼핑카트, 유저 프로파일, 캐싱 등에 사용함
- Redis, DynamoDB가 인기있음
- 와이트 컬럼 스토어
- 테이블, 행, 동적 열에 데이터를 저장
- 관계형 데이터베이스가 행에다 데이터를 저장하고 읽는 반면 컬럼스토어는 컬럼들의 집합으로 이루어져 있다. 즉 적은 수의 컬럼들을 가지고 분석을 수행하길 원할 때 원하지 않는 데이터까지 가져와 메모리를 사용하지 않고 필요한 컬럼만 불러올 수 있다. 컬럼들은 주로 같은 타입이고 효과적으로 압축하여 읽기도 더 빠르게 해준다.
- 주어진 컬럼값에 대해 빠르게 집계할 수 있다. (분석에 용이)
- 속도가 중요한 빅데이터 분석에 적합. 빅데이터에 대한 데이터 웨어하우스 작업, 대규모 프로젝트에도 적합, 이 데이터베이스 방식은 일반적인 트랜잭션 응용프로그램에 좋지 않음
- 와이드 컬럼 스토어는 각 행이 동일한 열을 가질 필요가 없다는 점에서 관계형 데이터베이스에 대해 뛰어난 유연성을 제공.
- 와이드 컬럼 스토어를 2차원적 키-값 데이터베이스로 생각하는 사람들이 많다. 와이드 컬럼 스토어는 대량의 데이터를 저장해야 할 때 적합하며, 쿼리 패턴을 예측할 수 있다.
- 약점
- 분석에 좋은 반면 데이터를 쓰는 방식은 강한 일관성을 유지하는데 어렵다. 왜냐하면 모든 컬럼들의 쓰기는 디스크에 다중 쓰기 이벤트를 필요로 하기 때문이다. 관계형 데이터베이스는 이런 문제에 대해 자유로운데 행데이터는 디스크에 연속적으로 기록되기 때문. (Unfortunately there is no free lunch, which means that while columnar databases are great for analytics, the way in which they write data makes it very difficult for them to be strongly consistent as writes of all the columns require multiple write events on disk. Relational databases don't suffer from this problem as row data is written contiguously to disk.)
- 소규모로 사용할 때 비용이 많이 든다. 한꺼번에 업데이트하는 것은 쉽지만 개별 기록을 업로드하고 업데이트하기 어렵다.
- 트랜잭션을 처리할 때 관계형 데이터베이스보다 느리다.
- 와이드 컬럼 스토어는 보통 사물인터넷 데이터와 사용자 프로필 데이터를 저장하는 데 사용된다.
- Cassandra와 HBase는 가장 인기 있는 와이드 컬럼 스토어.
- 그래프 데이터베이스
- 노드와 엣지에 데이터 저장.
- 노드에는 일반적으로 사람, 장소 및 사물에 대한 정보가 저장되고, 에지에는 노드 간의 관계에 대한 정보가 저장된다.
- 그래프 데이터베이스는 소셜 네트워크, 사기 탐지, 권장 엔진 같은 패턴을 찾아보기 위해 관계를 상세히 검토해야 하는 사용사례에 적합
- Neo4j와 JanusGraph
SQL
- 데이터 완전성이 무엇보다 중요한 상황에 적합하다. 재무 응용프로그램, 방어 및, 보안, 개인 건강 정보 등. 이 밖에 고도로 정형화된 데이터, 내부 프로세스의 자동화에도 적합
- ACID
- 원자성 (Atomicity): 작업이 일부만 실행되다가 중단되지 않도록 보장. (ex. a-b-c 커밋이 모두 보장됨을 확인 전까지 부분 커밋을 하지 않음.)
- 일관성 (consistency): 데이터베이스의 일관성 유지. 문제가 생기면 전체 중단: (오라클 페이지 참)
- 관계형 모델은 애플리케이션과 데이터베이스 복사본(인스턴스 ) 간에 데이터 일관성을 유지하는 데 가장 적합. 예를 들어 ATM에 돈을 입금한 다음, 휴대폰에서 계정 잔액을 확인할 때 고객은 해당 입금이 업데이트된 계정 잔액에 즉시 반영되길 기대.
- 관계형 데이터베이스는 데이터베이스의 여러 인스턴스가 항상 동일한 데이터를 갖도록 한다는 점에서 이러한 종류의 데이터 일관성에 있어 탁월
- 다른 유형의 데이터베이스는 대량의 데이터에서 이 정도 수준으로 시의적절한 일관성을 유지하기가 어렵다. NoSQL 같은 일부 최신 데이터베이스는 “결과적 일관성”만 지원할 수 있음. 이 원칙에 따라 데이터베이스를 확장하거나 여러 사용자가 같은 데이터에 동시에 액세스 할 때 데이터가 이러한 상황을 “이해”하려면 약간 시간이 걸린다.
- 제품 카탈로그에 목록을 유지하는 것과 같은 일부 사례에서는 결과적 일관성이 허용되지만, 쇼핑 카트 트랜잭션과 같이 중요한 비즈니스 시스템에서는 관계형 데이터베이스가 여전히 최적 표준입니다
- 고립성 (Isolation): 연산작업시 다른 연산작업이 끼어들지 못하도록 보장
- 지속성 (Durability): 성공적으로 수행된 작업은 영원히 유지
- 약점
- 정형 데이터 처리에 뛰난 만큼 비정형 데이터 처리에는 한계를 보인다. 테이블로부터 써러낸 데이터를 가독성이 높은 것으로 재조립해야 하고 이는 속도에 부정적인 영향을 미칠 수 있다.
- 고정된 스키마 역시 변화에 유연하게 대응하기 힘들다.
- 구성과 확장에 비용이 많이 든다. 서버를 여러 개 더 추가하는 방식의 수평 확장은 서버 하나에 자원을 더 추가하는 수직 확장에 비해 더 빠르고 경제적인 경우가 대부분이다. 그러나 관계형 데이터베이스는 그 구조 떄문에 수평 확장 과정이 복잡하다. 관계형 데이터베이스를 확장하려면 샤딩(데이터가 수평적으로 분할되고 기기의 모음 전반에 걸쳐 분산되는 경우)이 필요하다. ACID 준수를 유지하면서 관계형 데이터베이스를 샤딩하는 것은 매우 까다로운 작업
- SQL DB는 1970년대 초반에 사용자들에게 많이 사용됨. 스토리지가 매우 비쌌기 때문에 데이터 중복을 줄이기 위해 데이터베이스를 정규화함
- 1970년대의 소프트웨어 엔지니어들은 일반적으로 소프트웨어 개발에 있어 폭포수모델을 따랐다. 개발이 시작되기 전에 프롲게트에 대한 상세한 계획이 수립됨 → 저장이 필요한 모든 데이터를 신중하게 고려하기 위해 애써서 복잡한 entity-relation(E-R) 다이어그램을 만들었음 → 이러한 선행 계획 모델로 인해 소프트웨어 엔지니어들은 개발 주기 동안 요구사항이 바뀔 경우, 이에 대처하느라 애를 먹었다. 그 결과 프로젝트에서 예산이 초과되고 마감 기간을 넘겨서 사용자 요구를 충족하지 못하는 일이 잦았다.
참조
반응형
