[요약 정리] 4-4. 비구조화 데이터의 분산 스토리지

4-4. 비구조화 데이터의 분산 스토리지

[기본 전략] NoSQL 데이터베이스에 의한 데이터 활용

• 분산 스토리지는 필요에 따라 얼마든지 확장할 수 있는 확장성과 데이터를 구조화하지 않고도 저장할 수 있는 유연성이 요구됨
• 객체 스토리지 장점
  • 임의의 파일을 저장할 수 있음
• 객체 스토리지 단점
  • 일단 파일을 써넣으면 그것을 통째로 교체하는 방법밖에 없음. 수시로 변경하는 용도로 적합하지 않음
  • 쓰기 빈도가 높은 데이터는 별도 RDB에 저장하고 정기적으로 스냅샷을 하거나 분산 데이터베이스에 저장
• 중요한 데이터는 트랜잭션 처리에 대해 고려된 데이터베이스에 기록하는 것이 원칙
• 열 지향 스토리지를 만듦으로써 집계는 고속화되지만, 작성에 시간이 걸림
• 용도에 최적화된 데이터 저장소 → NoSQL 데이터베이스

 

분산 KVS

- 디스크로의 쓰기 성능을 높이기

• 모든 데이터를 키값 쌍으로 저장하도록 설계된 데이터 저장소
• 몇 KB 정도의 데이터를 초당 수만 번 읽고 쓰는 경우
• 모든 데이터에 고유의 키를 지정하고 그것을 부하 분산을 위해 이용함
• 키가 정해지면 그 값을 클러스터 내의 어느 노드에 배치할 것인지 결정
• 노드 간에 부하를 균등하게 분산하고 노드를 증감하는 것만으로 클러스터의 성능을 변경할 수 있게 되어있음
• 마스터/슬레이브 형, P2P 형

 

Amazon DynamoDB

• 항상 안정된 읽기 쓰기 성능을 제공하도록 디자인된 분산형 NoSQL 데이터베이스
• 하나 또는 두개의 키에 연결하는 형태로 임의의 스키마리스 데이터를 저장할 수 있음
• P2P 형의 분산 아키텍처
• 미리 설정한 초 단위의 요청 수에 따라 노드가 증감되는 특징이 있어 데이터의 읽기 및 쓰기에 지연이 발생하면 곤란한 애플리케이션에 유용
• DynamoDB의 데이터를 분석하려면, Amazon EMR 및 Amazon RedShift 등과 결합함으로써 Hive에 의한 배치 처리를 실행하거나 데이터 웨어하우스에 데이터를 전송하도록 함
• DynamoDB Streams를 사용하면 데이터 변경을 이벤트로 외부에 전송해 실시간 스트림 처리를 할 수 있음

 

• 일반적으로 NoSQL 데이터베이스는 애플리케이션에서 처음에 데이터를 기록하는 장소로 이용
• NoSQL 데이터베이스 자체는 대량의 데이터를 집계하는 기능이 없는 것이 많아 데이터 분석을 위해서는 외부로 데이터를 추출해야 함

 

ACID 특성과 CAP 정리

• ACID 특성 - 트랜잭션 처리에 요구되는 4가지 성질, 일반적인 RDB들은 이들을 충족하고 있어 신뢰성 있는 트랜잭션 처리를 실행하고 있음
  • 원시성(Atomicity)
  • 일관성(Consistency)
  • 독립성(Isolation)
  • 내구성(Durability)
• CAP 정리 - ACID 특성을 만족하면서 분산 시스템을 구축하는 것은 어렵기 때문에 그 한계에 의해 제창된 것. 다음의 세가지를 동시에 충족시킬 수 없어 어느 하나가 희생될 수 있음. 분산 시스템에서 트랜잭션 처리를 실행할 수 없다는 의미는 아님
  • 일관성(Consistency)
  • 가용성(Availability)
  • 분단내성(Partition-tolerance)
• 결과 일관성
  • NoSQl 데이터베이스의 일부는 CAP의 일관성이나 가용성 중 하나를 선택함
  • 일관성 우선 가용성 포기(단시간의 장애 발생을 수용) or 가용성 우선 일관성 포기(오래된 데이터를 읽을 수 있는)
  • 결과 일관성 → 써넣은 데이터를 바로 읽을 수 있다고는 말할 수 없음
  • 결과 일관성은 기존 객체를 덮어쓰거나 삭제하거나 하는 경우에는 그 변경이 언제 반영되는지 보장되지 않아 지연이 발생할 가능성이 있음

 

와이드 칼럼 스토어

- 구조화 데이터를 분석해서 저장하기

• 분산 KVS를 발전시켜 2개 이상의 임의의 키에 데이터를 저장할 수 있도록 한 것
• Google Cloud Bigtable, Apache HBase, Apache Cassandra
• 내부적으로 행 키와 칼럼 명의 조합에 대해 값을 저장
• 칼럼도 얼마든지 추가할 수 있는 구조, 수억의 칼럼을 만들 수도 있음
• 하나의 테이블에 가로와 세로의 2차원에 데이터를 쓸 수 있도록

 

Apache Cassandra

• 내부적인 데이터 저장소로 와이드 칼럼 스토어 이용, CQL이라는 높은 수준의 쿼리 언어가 구현되어 있음
• 구조화 데이터만 취급할 수 있음
• P2P형의 분산 아키텍처, 지정한 키에 의해 결정한 노드에 해당 키와 관련된 모든 값 저장
• 사용자 ID를 키로 사용하는 경우 그 사용자에 대한 기록은 하나의 노드에 모이고 그 노드 안에서 쿼리가 실행됨
• 데이터를 집계하는 데는 적합하지 않음 ← 집계를 위해서는 분산된 모든 노드에서 데이터를 모아야 하기 때문
• Hive, Presto, Spark 등으로 로드해야함

 

도큐먼트 스토어

- 스키마리스 데이터 관리하기

• 와이드 칼럼 스토어가 주로 성능 향상을 목표로 하는 반면, 도큐먼트 스토어에서는 주로 데이터 처리의 유연성을 목적으로 함
• JSON 과 같은 스키마리스 데이터를 그대로의 형태로 저장하고 쿼리를 실행할 수 있도록 함
• 배열과 연상 배열(맵 형)과 같은 중첩된 데이터 구조에 대해 인덱스를 만들거나 도큐먼트 일부만을 치환하는 식의 쿼리 실행
• 스키마를 정하지 않고 데이터를 처리할 수 있음
• 외부에서 들여온 데이터를 저장하는 데 특히 적합

 

MongoDB

• 성능을 우선하여 신뢰성을 희생해왔지만 간편함
• 여러 노드에 데이터를 분산할 수 있지만 그 자체는 대량의 데이터를 집계하는 데 적합하지 않음

 

검색 엔진

- 키워드 검색으로 데이터 검색

• NoSQL과는 성격이 조금 다름. but 저장된 데이터를 쿼리로 찾아낸다는 점에서는 유사한 부분도 많음
• 텍스트 데이터 및 스키마리스 데이터를 집계하는 데 자주 사용
• 역 색인
  • 텍스트에 포함된 단어를 분해하고 어떤 단어가 어떤 레코드에 포함되어 있는가 하는 인덱스를 먼저 만들어 둠
  • 역 색인이 없으면 모든 텍스트를 전체 스캔해야 원하는 레코드를 찾을 수 있음
• 데이터의 집계에 적합, 비정상적인 상태의 감지 및 보안 체크, 고객 서포트 등 민첩성이 요구되는 용도에서 최근의 데이터를 보기위해 사용, 실시간 집계 시스템의 일부로 사용

 

Elasticsearch

• 도큐먼트 스토어와 비슷하지만, 아무것도 지정하지 않으면 모든 필드에 색인이 만들어 짐
• 텍스트 데이터에선 역 색인이 구축됨
• 도큐먼트 스토어와 비교하면 쓰기의 부하가 크고, 필요에 따라 명시적으로 스키마를 결정함으로써 색인을 무효로 하는 식의 튜닝 필요
• 자체 쿼리 언어에 의한 고급 집계 기능 제공
• 열 지향 스토리지에도 대응

 

Splunk

• 웹 서버나 네트워크 기기 등으로부터 출력되는 로그 파일이나 JSON 파일을 다루어 텍스트 처리를 해야만 분석할 수 있는 비정형 데이터에 강함
• 검색을 실행할 때 텍스트에서 필드가 추출됨
• 검색할 때마다 데이터가 구조화되게 되어 있어 쿼리를 다시 작성함으로써 어떤 테이블이라도 유연하게 만들어 낼 수 있음

 

 

 

[출처]

빅데이터를 지탱하는 기술, 니시다 케이스케