23.3.29 DevOps 17일차

쿡쿡·2023년 3월 29일

DevOps(Code States)

목록 보기

9/25

Achievement Goals

RDBMS와 NoSQL의 차이와 각각의 장단점을 이해할 수 있다.
충분한 가용성이 확보되지 않은 다양한 문제 상황을 이해하고, 상황에 따른 솔루션이 무엇인지 이해할 수 있다.
- 다음 용어에 대한 간단한 정의를 내릴 수 있다: 인덱싱, 레플리카, 파티셔닝, 캐싱, 배치 작업, 스트림 처리
이벤트 기반 아키텍처를 설명할 수 있다.
RDBMS에서 테이블을 만들 때 스키마(필드) 디자인을 할 수 있다.
데이터 파이프라인의 필요성을 이해할 수 있다.
- OLTP와 OLAP의 차이를 이해할 수 있다.
- ETL 과정을 설명할 수 있다.
- MLOps와 DevOps의 차이를 이해할 수 있다.
리눅스 명령과 프로그래밍 언어를 이용해 간단한 데이터 파이프라인을 구현할 수 있다.
- 간단한 수준의 SQL문을 사용할 수 있다.

데이터베이스의 필요성

메모리에 임시 저장(In-Memory)

프로그램이 실행될 때에만 존재하는 데이터가 있음. 메모리 상에 일시적으로 저장, 프로그램이 종료될 때 해당 프로그램이 사용하던 데이터도 사라짐
프로그램의 실행에 의존
예기치 못한 상황으로부터 데이터 보호할 수 없음
프로그램이 종료된 상태라면 데이터를 원하는 시간에 받아올 수 없음
데이터의 수명이 프로그램의 수명에 의존

파일 입/출력(I/O)

파일을 읽는 방식으로 작동하는 형태, 속도가 느림
데이터가 필요할 때마다 전체 파일을 매번 읽어야 함
파일이 손상되거나 데이터량이 많아질수록 데이터를 불러들이는 작업이 점점 힘들어짐

RDBMS vs. NoSQL

SQL(구조화 쿼리 언어) vs. NoSQL(비구조화 쿼리 언어)

데이터 베이스는 크게 관계형 데이터베이스와 비관계형 데이터베이스로 구분
관계형 데이터베이스는 SQL을 기반으로, 비관계형 데이터베이스는 NoSQL로 데이터를 다룸
관계형 데이터 베이스
- 테이블의 구조와 데이터 타입 등을 사전에 정의, 테이블에 정의된 내용에 알맞은 형태의 데이터만 삽입할 수 있음
- 행(row)과 열(column)로 구성된 테이블에 데이터를 저장
- 각 열은 하나의 속성에 대한 정보를 저장, 행에는 각 열의 데이터 형식에 맞는 데이터가 저장
- 특정한 형식을 지키기 때문에, 데이터를 정확히 입력했다면 데이터를 사용할 때는 매우 수월함
- SQL을 활용해 원하는 정보를 쿼리할 수 있음. 이 말은 관계형 데이터베이스에서는 스키마가 뚜렷하게 보인다는 말과 같다. 다시 말해, 관계형 데이터베이스에서는 테이블 간의 관계를 직관적으로 파악할 수 있음
- 대표적인 관계형 데이터베이스는 MySQL, Oracle, SQLite, PostgreSQL, MariaDB 등이 있음
NoSQL
- SQL 앞에 붙은 'No'에서 알 수 있듯, 주로 데이터가 고정되어 있지 않은 데이터베이스를 가리킴
- SQL과 반대되는 개념처럼 사용된다고 해서, NoSQL에 스키마가 반드시 없는 것은 아님
- 데이터를 읽어올 때 스키마에 따라 데이터를 읽어 옴(schema-on-read)
- 읽어올 때만 데이터 스키마가 사용된다고 하여, 데이터를 쓸 때 정해진 방식이 없다는 의미는 아님
- 데이터를 입력하는 방식에 따라, 데이터를 읽어올 때 영향을 받음
- 대표적인 NoSQL은 MongoDB, Casandra 등이 있음

NoSQL

Key-Value 타입 : 속성을 Key-Value의 쌍으로 나타내는 데이터를 배열의 형태로 저장합니다. 여기서 Key는 속성 이름을 뜻하고, Value는 속성에 연결된 데이터 값을 의미합니다. Redis, Dynamo 등이 대표적인 Key-Value 형식의 데이터베이스입니다.
문서형(Document) 데이터베이스 : 데이터를 테이블이 아닌 문서처럼 저장하는 데이터베이스를 의미합니다. 많은 문서형 데이터베이스에서 JSON과 유사한 형식의 데이터를 문서화하여 저장합니다. 각각의 문서는 하나의 속성에 대한 데이터를 가지고 있고, 컬렉션이라고 하는 그룹으로 묶어서 관리합니다. 대표적인 문서형 데이터베이스에는 MongoDB 가 있습니다.
Wide-Column 데이터베이스 : 데이터베이스의 열(column)에 대한 데이터를 집중적으로 관리하는 데이터베이스입니다. 각 열에는 key-value 형식으로 데이터가 저장되고, 컬럼 패밀리(column families)라고 하는 열의 집합체 단위로 데이터를 처리할 수 있습니다. 하나의 행에 많은 열을 포함할 수 있어서 유연성이 높습니다. 데이터 처리에 필요한 열을 유연하게 선택할 수 있다는 점에서 규모가 큰 데이터 분석에 주로 사용되는 데이터베이스 형식입니다. 대표적인 wide-column 데이터베이스에는 Cassandra, HBase 가 있습니다.
그래프(Graph) 데이터베이스 : 자료구조의 그래프와 비슷한 형식으로 데이터 간의 관계를 구성하는 데이터베이스입니다. 노드(nodes)에 속성별(entities)로 데이터를 저장합니다. 각 노드 간 관계는 선(edge)으로 표현합니다. 대표적인 그래프 데이터베이스에는 Neo4J, InfiniteGraph 가 있습니다.

SQL 기반의 데이터베이스와 NoSQL 데이터베이스의 차이점

데이터 저장(Storage)

NoSQL은 key-value, document, wide-column, graph 등의 방식으로 데이터를 저장합니다.
관계형 데이터베이스는 SQL을 이용해서 데이터를 테이블에 저장합니다. 미리 작성된 스키마를 기반으로 정해진 형식에 맞게 데이터를 저장해야 합니다.

스키마(Schema)

SQL을 사용하려면, 고정된 형식의 스키마가 필요합니다. 다시 말해, 처리하려는 데이터 속성별로 열(column)에 대한 정보를 미리 정해두어야 합니다. 스키마는 나중에 변경할 수 있지만, 이 경우 데이터베이스 전체를 수정하거나 오프라인(down-time)으로 전환할 필요가 있습니다.
NoSQL은 관계형 데이터베이스보다 동적으로 스키마의 형태를 관리할 수 있습니다. 행을 추가할 때 즉시 새로운 열을 추가할 수 있고, 개별 속성에 대해서 모든 열에 대한 데이터를 반드시 입력하지 않아도 됩니다.

쿼리(Querying)

쿼리는 데이터베이스에 대해서 정보를 요청하는 질의문입니다. 관계형 데이터베이스는 테이블의 형식과 테이블 간의 관계에 맞춰 데이터를 요청해야 합니다. 그래서 정보를 요청할 때, SQL과 같이 구조화된 쿼리 언어를 사용합니다.
비관계형 데이터베이스의 쿼리는 데이터 그룹 자체를 조회하는 것에 초점을 두고 있습니다. 그래서 구조화되지 않은 쿼리 언어로도 데이터 요청이 가능합니다. UnQL(UnStructured Query Language)이라고 말하기도 합니다.

확장성(Scalability)

일반적으로 SQL 기반의 관계형 데이터베이스는 수직적으로 확장합니다. 높은 메모리, CPU를 사용하는 확장이라고도 합니다. 데이터베이스가 구축된 하드웨어의 성능을 많이 이용하기 때문에 비용이 많이 듭니다. 여러 서버에 걸쳐서 데이터베이스의 관계를 정의할 수 있지만, 매우 복잡하고 시간이 많이 소모됩니다.
NoSQL로 구성된 데이터베이스는 수평적으로 확장합니다. 보다 값싼 서버 증설, 또는 클라우드 서비스 이용하는 확장이라고도 합니다. NoSQL 데이터베이스를 위한 서버를 추가적으로 구축하면, 많은 트래픽을 보다 편리하게 처리할 수 있습니다. 그리고 저렴한 범용 하드웨어나 클라우드 기반의 인스턴스에 NoSQL 데이터베이스를 호스팅할 수 있어서, 수직적 확장보다 상대적으로 비용이 저렴합니다.

SQL과 NoSQL 중에서 어떤 것을 사용해야 하나요?

완벽한 솔루션은 없음
유저의 요구를 충족하기 위해 관계형, 비관계형 데이터베이스를 모두 사용하여 서비스에 맞게 설계
NoSQL 기반의 비관계형 데이터베이스가 확장성이나 속도면에서 더 뛰어남
고차원으로 구조화된 SQL 기반의 데이터베이스가 더 좋은 성능을 보여주는 서비스도 있음
여러 사용 사례를 살펴보고 적절한 데이터베이스를 선택하는 것이 중요함

SQL 기반의 관계형 데이터베이스를 사용하는 케이스

데이터베이스의 ACID 성질을 준수해야 하는 경우
- Atomicity(원자성), Consistency(일관성), Isolation(격리성), Durability(지속성)
- 각 단어는 데이터베이스에서 실행되는 하나의 트랜잭션(Transaction)에 의한 상태의 변화를 수행하는 과정에서, 안전성을 보장하기 위해 필요한 성질
- SQL을 사용하면 데이터베이스와 상호 작용하는 방식을 정확하게 규정할 수 있기 때문에, 데이터베이스에서 데이터를 처리할 때 발생할 수 있는 예외적인 상황을 줄이고, 데이터베이스의 무결성을 보호할 수 있음
- 전자 상거래를 비롯한 모든 금융 서비스를 위한 소프트웨어 개발 에서는 반드시 데이터베이스의 ACID 성질을 준수해야 해서 일반적으로 SQL을 이용한 관계형 데이터베이스를 사용함
소프트웨어에 사용되는 데이터가 구조적이고 일관적인 경우
- 규모가 많은 서버를 필요로 하지 않고 일관된 데이터를 사용하는 경우, 관계형 데이터베이스를 사용하는 경우가 많음
- 다양한 데이터 유형과 높은 트래픽을 지원하도록 설계된 NoSQL 데이터베이스를 사용해야만 하는 이유가 없기 때문

NoSQL 기반의 비관계형 데이터베이스를 사용하는 케이스

데이터의 구조가 거의 또는 전혀 없는 대용량의 데이터를 저장하는 경우
대부분의 NoSQL 데이터베이스는 저장할 수 있는 데이터의 유형에 제한이 없음. 필요에 따라, 언제든지 데이터의 새 유형을 추가 가능. 소프트웨어 개발에 정형화되지 않은 많은 양의 데이터가 필요한 경우, NoSQL을 적용하는 것이 더 효율적.
클라우드 컴퓨팅 및 저장공간을 최대한 활용하는 경우
클라우드 기반으로 데이터베이스 저장소를 구축하면, 저렴한 비용의 솔루션을 제공받을 수 있음. 소프트웨어에 데이터베이스의 확장성이 중요하다면, 별다른 번거로움 없이 확장할 수 있는 NoSQL 데이터베이스를 사용하는 것이 좋음
빠르게 서비스를 구축하는 과정에서 데이터 구조를 자주 업데이트 하는 경우
NoSQL 데이터베이스의 경우 스키마를 미리 준비할 필요가 없기 때문에 빠르게 개발하는 과정에 매우 유리함. 시장에 빠르게 프로토타입을 출시해야 하는 경우가 이에 해당. 또한 소프트웨어 버전별로 많은 다운타임(데이터베이스 서버를 오프라인으로 전환하여 데이터 처리를 진행하는 작업 시간) 없이 데이터 구조를 자주 업데이트 해야 하는 경우, 스키마를 매번 수정해야 하는 관계형 데이터베이스 보다 NoSQL 기반의 비관계형 데이터베이스를 사용하는 게 더 적합.

관계형 데이터베이스의 표준 언어 SQL

SQL 소개

Structured Query Language (SQL)은 데이터베이스 언어, 주로 관계형 데이터베이스에서 사용
MySQL, Oracle, SQLite, PostgreSQL 등 다양한 데이터베이스에서 SQL 구문을 사용할 수 있음
SQL이란 데이터베이스 용 프로그래밍 언어
데이터베이스에 쿼리를 보내 원하는 데이터를 가져오거나 삽입할 수 있음
SQL은 (relation 이라고도 불리는) 데이터가 구조화된(structured) 테이블을 사용하는 데이터베이스에서 활용할 수 있음
데이터의 구조가 고정되어 있지 않은 데이터베이스를 NoSQL이라고 함
관계형 데이터베이스와는 달리, 테이블을 사용하지 않고 데이터를 다른 형태로 저장
NoSQL의 대표적인 예시는 MongoDB 와 같은 문서 지향 데이터베이스
SQL을 사용하기 위해서는 데이터가 구조가 고정되어 있어야 함

쿼리란 ?

'질의문' 이라는 뜻을 가지고 있음
검색을 할 때 입력하는 검색어가 일종의 쿼리
검색을 할 때, 기존에 존재하는 데이터를 검색어로 필터링함. 해서, 쿼리는 저장되어 있는 데이터를 필터하기 위한 질의문으로도 볼 수 있음.

https://www.w3schools.com/sql/sql_intro.asp

SQL이란?

Structured Query Language
사용하면 데이터베이스에 액세스하고 조작할 수 있음

SQL은 뭘 할 수 있는가?

데이터베이스에 대해 쿼리를 실행할 수 있습니다.
데이터베이스에서 데이터를 검색할 수 있습니다.
데이터베이스에 레코드를 삽입할 수 있습니다.
(레코드 = 데이터베이스에서 하나의 단위로 취급되는 자료의 집합)
데이터베이스의 레코드를 업데이트할 수 있습니다.
데이터베이스에서 레코드를 삭제할 수 있습니다.
새로운 데이터베이스를 생성할 수 있습니다.
데이터베이스에서 새 테이블을 만들 수 있습니다.
데이터베이스에서 저장 프로시저를 생성할 수 있습니다.
데이터베이스에서 뷰를 생성할 수 있습니다.
테이블, 프로시저 및 뷰에 대한 권한을 설정할 수 있습니다.

SQL은 ANSI/ISO 표준이지만 다양한 버전의 SQL언어가 있음

ANSI 표준을 준수하기 위해 모두 유사한 방식으로 적어도 주요 명령(예: SELECT, UPDATE, DELETE, INSERT, WHERE)을 지원합니다.
대부분의 SQL 데이터베이스 프로그램에는 SQL 표준 외에도 고유한 확장 기능이 있음

웹 사이트 SQL(데이터베이스의 데이터를 보여주는 웹 사이트 구축)

RDBMS 데이터베이스 프로그램(MS Access, SQL Server, MySQL 등)
PHP 또는 ASP와 같은 서버 측 스크립팅 언어 사용
SQL을 사용하여 원하는 데이터 얻음
HTML/CSS를 사용하여 페이지 스타일 지정

RDBMS

관계형 데이터베이스 관리 시스템
QL과 MS SQL Server, IBM DB2, Oracle, MySQL 및 Microsoft Access와 같은 모든 최신 데이터베이스 시스템의 기반
RDBMS의 데이터는 테이블이라는 데이터베이스 개체에 저장됩니다. 테이블은 관련 데이터 항목의 모음이며 열과 행으로 구성
모든 테이블은 필드라는 더 작은 엔터티로 나뉨
필드는 테이블의 모든 레코드에 대한 특정 정보를 유지하도록 설계된 테이블의 열
행이라고도 하는 레코드는 테이블에 존재하는 각각의 개별 항목
레코드는 테이블의 가로 항목, 열은 테이블의 특정 필드와 관련된 모든 정보를 포함하는 테이블의 세로 항목

SQL 문

데이터베이스에서 수행해야 하는 대부분의 작업은 SQL 문으로 수행
SELECT * FROM (테이블 명); : 테이블의 모든 레코드 선택
세미콜론은 데이터베이스 시스템에서 각 SQL 문을 구분하는 표준 방법

가장 중요한 SQL 명령 일부분

SELECT- 데이터베이스에서 데이터 추출
UPDATE- 데이터베이스의 데이터 업데이트
DELETE- 데이터베이스에서 데이터를 삭제합니다.
INSERT INTO- 새로운 데이터를 데이터베이스에 삽입
CREATE DATABASE- 새로운 데이터베이스 생성
ALTER DATABASE- 데이터베이스 수정
CREATE TABLE- 새로운 테이블 생성
ALTER TABLE- 테이블 수정
DROP TABLE- 테이블 삭제
CREATE INDEX- 색인 생성(검색 키)
DROP INDEX- 색인을 삭제합니다.

SELECT 문은 데이터베이스에서 데이터를 선택하는 데 사용

SELECT column1, column2, ... // column1, column2, ...는 데이터를 선택하려는 테이블의 필드 이름
FROM table_name;

SELECT * FROM table_name; // 테이블에서 사용 가능한 모든 필드를 선택

SELECT DISTINCT 문은 고유한(서로 다른) 값만 반환하는 데 사용

SELECT DISTINCT column1, column2, ...
FROM table_name;

SELECT column FROM table_name;

WHERE 절은 레코드를 필터링하는 데 사용, 지정된 조건을 충족하는 레코드만 추출하는 데 사용

SELECT column1, column2, ...
FROM table_name
WHERE condition;

WHERE 절 은 AND, OR 및 NOT연산자 와 결합할 수 있음
AND및 OR 연산자는 둘 이상의 조건을 기반으로 레코드를 필터링하는 데 사용

AND 연산자는 AND 로 구분된 모든 조건이 TRUE인 경우 레코드를 표시
OR 연산자는OR 로 구분된 조건 중 하나라도 TRUE이면 레코드를 표시
NOT 연산자는 조건이 TRUE가 아닌 경우 레코드를 표시

SELECT column1, column2, ...
FROM table_name
WHERE condition1 AND condition2 AND condition3 ...;

SELECT column1, column2, ...
FROM table_name
WHERE condition1 OR condition2 OR condition3 ...;

SELECT column1, column2, ...
FROM table_name
WHERE NOT condition;

키워드 ORDER BY 는 결과 집합을 오름차순 또는 내림차순으로 정렬하는 데 사용(내림차순으로 정렬하려면 DESC)

SELECT column1, column2, ...
FROM table_name
ORDER BY column1, column2, ... ASC|DESC;

INSERT INTO 명령문은 테이블에 새 레코드를 삽입하는 데 사용

INSERT INTO table_name (column1, column2, column3, ...)
VALUES (value1, value2, value3, ...);

INSERT INTO table_name
VALUES (value1, value2, value3, ...);

NULL 값이 있는 필드는 값이 없는 필드

SELECT column_names
FROM table_name
WHERE column_name IS NULL;

SELECT column_names
FROM table_name
WHERE column_name IS NOT NULL;

UPDATE 명령문은 테이블의 기존 레코드를 수정하는 데 사용

UPDATE table_name
SET column1 = value1, column2 = value2, ...
WHERE condition;

DELETE 명령문은 테이블의 기존 레코드를 삭제하는 데 사용

DELETE FROM table_name WHERE condition;

문제 상황에 따른 해결책

낮은 검색 성능 - 인덱싱

효율적인 검색을 위한 시도

데이터의 핵심적인 기능
- 데이터 저장
- 요청이 왔을 때 저장되어 있는 데이터 중 요청에 맞는 데이터를 찾아서 제공
좀 더 효율적인 방법으로 특정 키의 값을 확인하고 제공하기 위해 인덱스(색인)를 이용

데이터 검색에 도움을 주기 위한 메타데이터

인덱스: 데이터베이스에 저장된 기본데이터에서 파생된 부가적인 메타데이터
원하는 데이터의 위치를 찾는데 도움을 주는 이정표가 됨

데이터에 영향을 주지 않는 인덱스

인덱스의 편집사항은 데이터베이스의 내용에는 영향을 주지 않음
질의 성능에만 영향을 줌

고려사항

별도의 저장공간을 확보하고 데이터에 연계된 인덱스들을 필요에 따라 설정하고 저장해야 하므로, 추가적인 작업이 수반
데이터 변경에 따라서 인덱스에 대한 수정도 연계되어 이루어져야 하므로 적절하게 인덱스를 활용하지 못하는 경우 오히려 성능저하의 문제가 발생

많은 사용자 - 레플리카

안정적인 서비스를 제공하기 위한 시도

많은 사용자가 하나의 데이터베이스에 접근하는 경우에 성능 저하가 발생할 수 있음, 이러한 경우에 데이터베이스의 복사본을 저장하는 각각의 노드인 레플리카(replica : 복제서버)를 활용하여 문제를 해결할 수 있음
원본이 되는 데이터베이스와 같은 데이터를 다른 위치에 존재하는 여러 노드에 유지하는 방식
데이터의 중복성이 발생하는데, 이 중복성으로 인해서 얻을 수 있는 장점이 존재하며, 그에 따라 해결해야하는 문제점들 역시 존재

레플리카 활용의 장점

시스템 장애 발생시에도 동작할 수 있도록 가용성 확보

일부 노드가 사용불가능 상태라면 해당 데이터는 남은 다른 노드를 통해 여전히 제공할 수 있다는 장점 있음
장애 상황이 발생하더라도 레플리카 중 하나를 새로운 리더로 지정하고 사용자의 요청을 새로운 리더로 연결하여, 서비스가 중단되는 시간을 최소화 할 수 있음

읽기 쿼리 제공 장비 수를 확장해 읽기 처리량을 늘림

레플리카를 읽기전용 데이터베이스로 활용할 수 있음
리더에서는 읽기와 쓰기 처리를 한번에 처리하면서, 쓰기 처리가 발생할 경우 각 레플리카에도 데이터를 저장해서, 동기화를 진행, 레플리카는 최종적으로 리더와 같은 데이터를 가지고 있기 때문에 사용자들이 읽기 요청을 보낼 때 해당사항을 처리할 수 있음

지연시간 감소

레플리카의 위치를 각 지역에 분산시켜 배치할 수 있음
각 지역에 분산 배치된 레플리카는 해당 지역에서 가까운 사용자의 요청을 처리하여 지연시간을 감소시킬 수 있음

레플리카 활용 시 고려해야할 사항

모든 데이터베이스가 정확히 같은 데이터를 가지고 있게 하는 것

동기식 복제(synchronous)

리더의 데이터 처리와 별개로 레플리카에서의 데이터 처리까지 모두 완료되어야만 프로세스가 진행
레플리카와 리더 데이터베이스가 일관성 있게 최신 데이터 복사본을 가지고 있는 것을 보장할 수 있음
네트워크 문제나, 다른 이유로 레플리카가 정상적으로 데이터처리 작업을 완료할 수 없는 경우 응답을 받지 못한 리더 데이터베이스 역시 프로세스를 진행하지 못함. 리더는 모든 쓰기를 차단하고 동기 레플리카가 회복되기를 기다리기 때문에 시스템 운영이 멈출수 있는 위험이 있음

비동기식 복제 (Asynchronous)

리더가 레플리카의 처리 응답을 기다리지 않음
리더는 레플리카에 데이터 처리를 요청한 후 자신의 작업을 완료하면 사용자의 요청에 바로 응답
연결된 모든 레플리카가 어떠한 이유로, 처리를 지속할 수 없더라도 리더는 쓰기 처리를 계속할 수 있다는 장점
리더 데이터베이스에 문제가 없다면, 레플리카의 상태와 무관하게 사용자에게 서비스를 계속해서 제공
하지만 레플리카가 읽기 전용으로 이용되고 있을 경우, 사용자에게 리더와 같은 응답을 주지 못하는 경우가 발생할 수 있음
데이터의 불일치가 발생하기 때문에 불일치 상태가 길어지는 경우 큰 문제가 될 수 있음
리더가 잘못되고 복구할 수 없는 상황이 발생 시, 팔로워에게 복제되지 못한 모든 처리가 유실될 수 있으며, 클라이언트에게는 정상 작동을 알린 이후임에도 불구하고 지속성을 보장하지 못하는 문제가 발생

반동기식 복제(semi-synchronous)

하나의 레플리카는 동기식 복제를 사용하고, 다른 레플리카들은 비동기식으로 사용하는 반동기식 복제로 활용

정리

일반적인 웹 서비스 이용의 패턴에서는 읽기 처리가 쓰기 처리에 비해 훨씬 많이 요청
많은 레플리카를 구성해서 읽기 요청을 분산하는 전략은 리더의 부하를 줄일 수 있는 선택이지만, 모든 레플리카에 동기식으로 복제를 시도한다면, 서비스가 불안정해질 수 있음
하나의 레플리카라도 문제가 발생한다면 전체 시스템이 다운되는 결과가 나타날 수 있음
이러한 이유로 비동기식 복제를 사용하는 경우가 많으며, 이 경우 비동기식 복제에서 설명한 단점인 데이터 불일치 문제를 해결해야 함
최근에는 데이터베이스 성능의 향상으로 이러한 불일치가 발생하는 기간은 일시적. 따라서 서비스 전체의 중단보다 짧은 시간 동안의 데이터 불일치를 감수하고 최종적 일관성을 유지하는 방법을 많이 선택

대용량의 데이터 - 파티셔닝

대용량 데이터를 처리하기 위해 데이터셋을 쪼개기

데이터베이스에 들어가는 데이터셋이 매우 크거나, 쿼리 처리량이 매우 높은 경우에는 단순히 복제하는 것만으로는 부족
이에 따라 큰 데이터베이스를 파티션이라는 작은 단위로 쪼개서 활용하는 방법이 제시
샤딩(shardIng)이라고도 표현
파티션은 그 자체로 작은 데이터베이스가 됨

파티셔닝의 목적

데이터 파티셔닝을 필요로 하는 주된 이유는 확장성
데이터베이스가 확장되면서 점점 대용량의 데이터베이스가 되고, 그러한 환경에 맞게 프로세스를 처리할 필요성이 생기기 때문
데이터셋을 여러 디스크에 분산하의 요청에 따른 질의 부하를 여러 곳으로 분산하는 것

쏠림현상(skewed) 방지를 위한 시도

데이터를 분산시켰음에도 불구하고, 특정 패턴을 가진 요청에 의해서 한 곳으로 요청이 쏠리는 현상(skewed)이 발생
파티션을 구성할때는 데이터의 쿼리(질의) 부하를 노드 사이에 고르게 분산시킬 수 있도록 전략적으로 배치

고른 분포를 위한 전략

레코드를 할당할 노드를 무작위로 선택
- 데이터를 읽어내야할 때는 특별한 기준으로 찾을 수 없기 때문에 성능저하를 가져올 수 있음
키 범위를 기준으로 한 파티셔닝
- 특정 접근 패턴이 핫스팟을 유발하는 경우가 여전히 존재
키의 해시값 기준 파티셔닝
- 해시함수를 통해 처리를 거쳐 균일하게 분산
- 핫스팟 발생을 막을 수 있지만, 역시 범위 쿼리 효율성이 높은 키 범위 파티셔닝의 장점을 잃어버린다는 단점

동일 데이터의 잦은 조회 - 캐싱

특정 데이터에 대한 반복된 요청을 효과적으로 처리하기 위한 시도

캐시(Cache)는 임시로 복제된 데이터를 저장하는 장소로 사용자가 더 효율적이고 빠르게 원하는 데이터에 접근할 수 있도록 하기위해 설정
원본 데이터베이스가 제공할 수 있는 것보다 짧은 대기 시간을 제공하면서 웹 애플리케이션의 성능을 향상, 데이터베이스의 비용을 절감

캐시 사용의 장점

성능향상

캐시의 경우에는 임시로 데이터가 저장되는 장소이기 때문에, 저장의 기능보다는 정보를 제공하는 처리 속도에 더 집중 할 수 있음
원본 데이터가 존재하는 데이터베이스에 액세스 하는 것보다 훨씬 빠른 속도로 데이터를 제공하면서 전반적인 애플리케이션 환경이 개선

비용감소

원본 데이터베이스에 대한 쿼리 수를 줄이고, 데이터베이스 자체를 스케일링 할 필요성을 낮추면, 성능 향상과 더불어 비용을 절감하는 효과

캐시 타입

Cache-aside

일반적으로 웹 애플리케이션에서는 읽기 작업량이 많음. 이 경우에 애플리케이션을 설계할 때 캐시 보관 패턴을 사용
애플리케이션은 우선적으로 캐시에서 원하는 데이터를 검색, 데이터가 캐시에 존재하지 않는다면 데이터베이스에 직접 연결하도록 코드를 구성, 데이터베이스에서 직접 데이터를 확보했다면 애플리케이션은 해당 데이터를 캐시에 복사

Read-through/Write-through Cache

모두 데이터베이스와 일렬로 배치되며, 애플리케이션은 뒤에 있는 데이터베이스가 아닌 캐시를 주 데이터 저장소처럼 취급
Read-through를 통해서 애플리케이션이 데이터를 읽으려 한다면, 최초 데이터를 로드할 때만 캐시가 데이터베이스에 접근. 이후 동일 데이터는 캐시에서 처리. Cache-Aside 방식과 달리 애플리케이션이 캐시에 기록하지 않기 때문에, 애플리케이션 자체의 부담을 줄일 수 있음. 읽기처리가 많은 워크로드에 적합한 캐시 방법
Write-through를 통해서 에플리케이션에서 쓰기 요청이 발생한다면, 우선적으로 캐시에 데이터를 추가한 뒤 데이터베이스에도 데이터를 추가. 이로 인해서 항상 최신 상태를 유지하면서 데이터 일관성을 보장 받을 수 있음.
결과적으로 Read-through/Write-through를 함께 사용하면 데이터의 일관성을 보장하면서, 애플리케이션의 코드를 단순화 하고 원본 데이터베이스에 전달되는 요청을 최소화 할 수 있음

Write-behind/write-back Cache

애플리케이션은 일단 캐시에 데이터를 저장, 그 후 캐시가 백그라운드에서 비동기적인 방식으로 데이터베이스에 데이터를 기록, 이러한 방식은 쓰기처리가 많은 워크로드에 적합한 캐시 방법
애플리케이션은 데이터베이스에 쓰기가 완료되는 것을 기다릴 필요없이 다음 작업을 진행할 수 있으므로 사용자에게 좀 더 쾌적한 사용환경을 제공

배치 작업에 따른 성능 저하 - 스트림 처리

데이터 배치작업

Data Batch Processing

데이터를 특정량 또는 특정기간 모아서 한번에 처리한다는 의미
일괄 작업은 최소한의 인간 상호 작용으로 실행 할 수 있으며, 자주 사용되는 프로그램을 위한 것
데이터를 실시간으로 처리하는 것이 아니라 일괄적으로 모아서 한번에 처리하는 작업을 의미

배치 작업의 단점

앞단에 실행시간이 많이 필요한 응용 프로그램이 실행될 경우 컴퓨터 응답시간이 오래 걸릴 수가 있음
-CPU가 필요없는 시간대에도 응용 프로그램이 CPU를 점유하고 있을 수 있기 때문에 총 실행 시간도 오래 걸릴 수 있음

배치작업으로 인한 성능저하

대량의 배치작업을 한꺼번에 진행하게 되면 특정시간대에 I/O가 몰리게 되어 서버에 갑작스러운 부하가 일어나 성능이 저하 될 수 있음
DB의 성능 개선을 위해서는 DB를 효율적으로 처리하는 것이 중요

DB를 효율적으로 처리하는 방법

좀 더 자주 처리를 실행해야 함
시간을 초단위, 밀리초 단위로 해서 데이터를 처리하거나, 또는 고정된 시간이 아닌 단순히 이벤트가 발생할 때마다 처리를 해야 함

데이터 배치 처리 vs 데이터 스트림 처리

데이터 스트림

데이터 스트림 처리

스트림 처리는 데이터가 생성되는 즉시 연속 스트림을 처리하는 것을 의미
스트리밍 데이터를 실시간으로 분석하는 것으로, 스트림 처리는 데이터 크기를 알 수 없고 무한하고 연속적일 때 사용
스트림 처리에서 데이터 출력 속도는 데이터 입력 속도만큼 빠르며, 스트림 프로세서는 데이터를 몇 번의 패스로 처리
데이터 스트림이 연속적이고 즉각적인 응답이 필요한 경우 스트림 처리가 사용
스트림 처리를 통해 데이터가 생성되자마자 분석 시스템에 하나씩 데이터가 공급, 이를 통해 거의 실시간으로 필요한 정보를 이용할 수가 있음

데이터 스트림 특징

시간에 민감함
테이터 스트림의 각 요서는 타임 스탬프를 전달합니다. 데이터 스트림은 시간에 민감하며 특정 시간이 지나면 중요성을 잃게 됩니다. 예를 들어, 의심스러운 움직임을 나타내는 홈 보안 시스템의 데이터는 관련성을 유지하기 위해 짧은 시간 내에 분석 및 처리되어야 합니다.
연속성
스트리밍 데이터에는 시작도 끝도 없습니다. 데이터 스트림은 연속적이고 실시간으로 발생하지만 시스템 요구 사항에 따라 항상 그 순간에 실행되는 것은 아닙니다.
다양성
스트림 데이터는 지리적으로 멀리 떨어져 있을 수 있는 수천 개의 서로 다른 소스에서 오는 경우가 많습니다. 소스의 불일치로 인해 스트림 데이터에는 다양한 형식이 혼합되어 있을 수 있습니다.
불완전성
소스의 다양성과 데이터 전송 메커니즘의 차이로 인해 데이터 스트림에 데이터 요소가 누락되거나 손상될 수 있습니다. 또한 스트림의 데이터 요소가 순서대로 도착하지 않을 수 있습니다.
휘발성
데이터 스트리밍이 실시간으로 이루어지기 때문에 스트림을 반복적으로 전송하는 것은 상당히 어렵습니다. 재전송에 대한 조항이 있지만 새 데이터는 마지막 데이터와 동일하지 않을 수 있습니다. 이로부터 데이터 스트림은 휘발성이 높습니다. 그러나 많은 최신 시스템은 데이터 스트림의 기록을 유지하므로 현재 액세스할 수 없더라도 나중에 분석할 수 있습니다.

데이터 스트림을 처리하기 위해서는

짧은 대기 시간
스트림 프로세서는 연속적인 데이터 스트림에서 빠르게 작동해야 합니다. 이것은 데이터 스트림이 시간에 민감한 특성때문입니다. 모든 처리 지연은 데이터의 가치를 저하시키는 것과 직결이 됩니다.
확장성
스트리밍 데이터의 양이 항상 같지는 않습니다. 예를 들어, 운행중인 자동차의 위치를 추적하는 시스템에서 운행 차량의 양이 많을 수도 있고 늦은 시간에는 운행하는 차량이 없을 수도 있습니다. 데이터의 양은 예측할 수 없기 때문에 프로세서는 필요한 경우 많은 양의 데이터를 처리할 수 있도록 확장되어야 합니다.
가용성
스트림 프로세서는 긴 가동 중지 시간을 감당할 수 없습니다. 스트림 데이터는 연속적이며 실시간으로 도착합니다. 프로세서는 결함 내성이 있어야 합니다. 즉, 일부 구성 요소에 장애가 발생하더라도 계속 작동할 수 있어야 합니다. 또한 스트림 프로세서는 정보를 수집, 처리 및 즉시 상위 계층으로 전달하여 프레젠테이션을 수행할 수 있어야 합니다.

데이터 스트림 처리의 이점

새로운 동적 데이터가 지속적으로 생성되는 시나리오 대부분에서 유용(산업 부문과 빅 데이터 사용 사례)

데이터 스트림 처리의 예

사물 인터넷: IoT에는 센서를 사용하여 데이터를 수집하고 실시간으로 데이터 프로세서에 전송하는 수많은 장치를 포함하고 있습니다. IoT 데이터는 스트림 데이터를 생성합니다. 워치와 같은 웨어러블 건강 모니터, 가정 보안 시스템, 교통 모니터링 시스템, 생체 인식 스캐너, 연결된 가전 제품, 사이버 보안 및 개인 정보 보호 시스템은 실시간으로 데이터를 생성하고 스트리밍합니다.
실시간 주식 시장 모니터: 실시간 금융 데이터는 종종 스트림 형식으로 전송됩니다. 금융 데이터(예: 주가 및 시장 동향)의 처리 및 분석은 조직에 중요한 결정을 빠르게 내리는 데 도움을 줍니다.
활동 및 트랜잭션 로그: 인터넷은 실시간 스트림 데이터의 주요 소스이기도 합니다. 사람들이 웹사이트를 방문하거나 링크를 클릭하면 웹 브라우저는 활동 로그를 생성합니다. 신용 카드 구매와 같은 온라인 금융 거래도 실시간 조치를 위해 스트리밍 및 처리할 수 있는 시간이 긴급한 데이터를 생성합니다.
프로세스 모니터: 모든 회사는 내부 시스템에서 수십억 개의 데이터 포인트를 생성합니다. 기업은 이 데이터를 스트리밍하고 실시간으로 처리함으로써 시스템 상태를 모니터링하고 상황이 확대되기 전에 조치를 취할 수 있습니다. 예를 들어, 제조 회사에는 종종 조립 라인의 상태를 모니터링하고 결함을 감지하여 생산 위험을 평가하는 장치가 있습니다. 이러한 장치는 또한 시간적으로 긴급한 데이터를 스트리밍하여 중지를 모니터링하고 방지할 수도 있습니다.

이벤트

이벤트란?

시스템 하드웨어 또는 소프트웨어 상태가 변화다는 것을 의미, 중대 사건의 발생을 의미하기도 함
이벤트는 시스템의 다른 부분에 이벤트가 발생했음을 알리기 위해 해당 시스템에서 보내는 메시지 또는 알림을 뜻하는 이벤트 알림과는 다름
내부 또는 외부 입력일 수도 있고, 마우스 클릭이나 키보드 입력과 같은 사용자 또는 센서 출력과 같은 외부 소스에서 생성되거나 프로그램 로딩과 같이 시스템에서 비롯될 수도 있음

이벤트 기반 아키텍처

이벤트 생성자와 이벤트 소비자로 구성
이벤트 생성자는 이벤트를 감지하며 메시지로 해당 이벤트를 나타냄
생성자는 이벤트 소비자 또는 이벤트 결과를 알지 못함
이벤트 기반 아키텍처는 조직이 실시간으로 변화에 대응하여 의사 결정을 내릴 수 있는 유연한 시스템을 확보할 수 있도록 지원

수평확장된 데이터베이스와 중복처리 (Advanced)

빅 데이터 처리에서 확장성의 중요성

마이크로서비스와 클라우드 환경이 발달이 되고 하드웨어의 종속성이 줄어들면서 우리는 수평확장 기술로 컴퓨터의 클론을 만들어 가용성을 높이고 있음
수직확장 또는 수평확장을 통해 상당한 양의 데이터를 관리하고 이용

데이터 중복성

높은 가용성을 위해 한 컴퓨터의 클론을 만든다는 것은, 그 안에 존재하는 데이터 역시 복제되어야 함을 의미, 데이터 중복 메커니즘은 가용성을 얻기 위해 필요한 작업

데이터 중복 발생의 원인

관리시스템 내의 소프트웨어(코딩) 품질
- 데이터 중복은 조직에 긍정적이거나 부정적인 결과를 가져옴, 그 결과는 그 중복인 의도적인지 우발적인지에 따라 다를 수 있음
- 우발적인 데이터 중복의 원인 중 하나는 조직의 데이터 관리 시스템 내 소프트웨어 품질때문, 이로 인해 경로 오작동으로 이어질 수 있음
- 이는 곧 데이터 관리 시스템 전체에서 적절하게 업데이트 되지 않을 수 있음을 의미하며, 알고리즘을 방해하고 데이터베이스의 불일치를 유발
백업시스템
- 백업 스토리지가 있는 경우 백업은 데이터 관리 시스템 또는 원본 데이터베이스의 문제를 완화하기 위해 정보의 복사본 역할

데이터 중복성의 이점

정보 보호 개선: 의도적인 데이터 중복성은 외부공격으로 부터 조직의 데이터를 보호함으로써 정보 보호를 강화할 수 있습니다. 또한 조직의 모든 데이터가 서로 다른 위치에 있는 경우 사이버 공격이 상당한 양의 데이터를 동시에 표적으로 삼는 것도 어렵습니다.
데이터 백업 생성: 데이터 중복성을 통해 조직은 스토리지 시스템의 데이터 세트 또는 사본이 손상될 때 정보를 보존할 수 있습니다. 예를 들어 데이터가 포함된 하드드라이브가 오작동하여 정보가 손실되는 경우 조직에서 동일한 정보를 클라우드에 백업할 수 있습니다.
데이터 엑세스 속도 향상: 조직에서 데이터를 여러 위치에 보관하는 경우 일부 저장소 위치에 다른 위치보다 쉽게 액세스 할 수 있습니다. 이를 통해 조직 내의 다양한 사용자가 여러 데이터 진입점에 엑세스하고 더 빠른 데이터 액세스 속도를 즐길 수 있습니다.
데이터 정확성 보장: 데이터 관리 시스템은 동일한 데이터에 대해 여러 위치를 가짐으로써 불일치를 평가하여 데이터의 정확성을 향상 시킬 수 있습니다. 다른 수준의 데이터 저장은 이후에 효율적인 품질 보증을 가능하게 할 수 있습니다.
정확한 분석: 상당한 양의 데이터를 저장하는 조직은 일반적으로 추세를 분석하고 회사 또는 고객을 위한 보고서를 작성하는 데 데이터를 사용합니다. 이를 위해서는 회사가 의도적인 데이터 중복을 통해 보장 할 수 있는 정확한 데이터가 필요합니다.

데이터 중복성의 문제점

불일치 증가: 여러 위치에서 테이터를 보존하면 정보가 모든위치에서 즉시 업데이트 되지 않는 경우 불일치가 발생할 수 있습니다. 이는 원본 저장 위치 정보가 변경되고 다른 복사본은 변경되지 않거나 한 복사본의 변경 사항이 Array 전체에 적용되지 않는 경우에 발생 할 수 있습니다.
데이터 손상 가능성: 데이터 손상은 저장, 전송 또는 생성과정에서 정보가 손상되거나 오류가 발생하는 경우 발생합니다. 즉 동일한 데이터의 복사본을 여러 개 저장하면 손상도리 가능성이 더 커질 수 있습니다.
유지 비용 증가: 데이터 중복성은 유지 관리하고 해결하는데 비용이 많이 듭니다.
- 스토리지 : 무엇보다도 클라우드와 온프레미스를 불문하고 스토리지 블록을 저장하는 데는 비용이 들기 때문에 중복 데이터를 제거하는 것은 매우 중요합니다.
- 네트워크: 중복 데이터 블록을 기기에서 백업 서버와 스토리지로 불필요하게 전송하면 네트워크 경로가 여러 지점에서 포화 상태가 됩니다.
- 디바이스: 파일을 호스팅하는 디바이스든 단순히 데이터를 전달하는 디바이스든 백업 경로상의 모든 기기는 중복 데이터를 위해 프로세서 사이클과 메모리를 낭비해야 합니다.
- 시간: 기업은 애플리케이션과 데이터를 24시간 사용할 수 있어야 하므로 백업으로 인한 성능 저하는 달갑지 않은 현상입니다. 이런 이유로 IT 관리자는 백업이 시스템 성능에 미치는 영향을 최소화하도록 일반적으로 백업 작업시간을 야간에 계획합니다. 중복 데이터는 이렇게 귀중한 시간을 낭비합니다.
사용할 수 없는 데이터 생성: 상당한 양의 데이터를 보관하는 회사는 일반적으로 이를 사용하여 회사 또는 고객의 시장 정보 패턴을 평가합니다. 즉 부정확한 데이터가 있는 경우 평가 결과가 부정확할 수 있습니다.

데이터의 중복을 줄이는 방법

마스터 데이터 활용
마스터 데이터는 데이터 관리자가 여러 시스템 또는 애플리케이션에서 공유하는 공통 비즈니스 데이터의 유일한 소스입니다. 마스터 데이터는 데이터 중복의 발생을 줄이지는 않지만 조직이 특정 수준의 데이터 중복을 적용하고 해결 할 수 있도록 합니다. 마스터 데이터를 활용하면 변경되는 경우 조직에서 단일 정보를 업데이트 할 수 있습니다. 이 시스템은 중복 데이터가 최신 상태를 유지하고 동일한 정보를 제공하도록 합니다.
데이터베이스 정규화
데이터베이스 정규화는 중복제거를 보장하기 위해 데이터베이스에 데이터를 효율적으로 배열하는 작업입니다. 이 프로세스를 통해 회사의 데이터베이스에는 모든 레코드에서 유사하게 표시되고 읽는 정보가 포함됩니다. 데이터 정규화에는 일반적으로 데이터베이스의 열과 테이블을 정렬하여 종속성을 올바르게 적용합니다. 이는 IT기업 뿐만아니라 여러 일반기업에서도 SQL을 다룰 수 있는 사원을 영입하려고 하는 이유이기도 합니다. 현재 수많은 회사에 데이터 정규화에 관한 특별한 기준 세트가 있고 데이터 정규화에 대한 접근 방식들이 각각 다릅니다.
미사용 데이터 삭제
데이터 중복성에 기여하는 또 다른 요소는 조직에서 더 이상 필요하지 않은 데이터 조각을 보존하는 것입니다. 예를 들어, 조직은 고객 데이터를 새 데이터베이스로 옮기고 동일한 데이터를 이전 데이터베이스에 유지할 수 있습니다. 이는 데이터 중복 및 저장 낭비로 이어질 수 있습니다. 조직은 더 이상 필요하지 않은 데이터를 즉시 삭제하여 이러한 중복을 피할 수 있습니다.
데이터베이스 설계
기업은 또한 데이터 베이스에서 직접 읽을 수 있는 사내 애플리케이션으로데이터 베이스 아키텍처를 설계할 수 있습니다. 관계형 데이터베이스는 조직에 표준 필드가 있는지 확인하고 레코드를 일치시키고 테이블을 연결 할 수 있도록 합니다. 이 방법을 사용하면 조직에서 반복을 쉽게 식별하고 제거 할 수 있습니다.

데이터 중복처리

데이터 중복 제거(Deduplication)

중복 데이터가 스토리지 비용에 미치는 영향을 줄이는데 도움이 되는 기능
중복제거가 설정된 경우 볼륨에서 중복된 부분을 찾기 위해 볼륨의 데이터를 검사하여 볼륨의 여유 공간을 최적화
볼륨의 데이터 세트에서 중복된 부분이 한 번 저장되며 필요한 경우 추가적인 절약을 위해 압축
데이터 중복 제거는 데이터 충실도 또는 무결성을 손상시키지 않고 중복성을 최적화
주로 소프트웨어 레벨에서 이루어지며, 중복되는 데이터를 파악해 처음 저장된 데이터만을 남겨두는 방식으로 진행
중복되는 데이터가 있는 자리에는 원본 데이터의 위치만 남겨둠
이렇게 중복되는 부분을 파악하기 위해 주로 블록(block) 또는 청크(chunk)라는 하나의 데이터 덩어리로 나누고, 각 블록에 고유의 해시(hash)값을 부여해 구분

데이터 중복제거 유형

데이터 중복 제거의 프로세스는 동일한 데이터의 불필요한 사본을 없애 사본 하나만 저장하는 것으로 이루어 짐

저장 시점에 따른 유형

인라인 중복 제거(Inline deduplication)
- 수신 데이터가 스토리지 미디어에 기록되기 전에 데이터 축소가 발생하는 중복을 제거하는 데 널리 사용되는 방법
- 중복 제거 도구는 일반적으로 데이터가 배치되는 위치와 방법을 제어하는 SDS(Software Defined Storage) 컨트롤러 임
- 일반적으로 원래 데이터의 중복 제거가 되지 않은 데이터세트는 디스크에 기록되지 않기 때문에 시스템에 필요한 원시 디스크 용량을 줄임
- 실행되는 쓰기 작업도 그에 따라 낮아져 디스크 마모가 줄어듬
후처리 중복 제거(Post-process deduplication)
- 데이터가 먼저 저장 매체에 기록된 다음 복제 및 압축 기회에 대해 분석되는 접근 방식
- 데이터가 저장 장치에 한번 저장된 후에만 중복 제가가 실행되기 때문에 원시 데이터 크기(데이터 축소 전)만큼 필요한 초기 용량이 있음
- 용량 최적화 데이터는 데이터 축소 전보다 잠재적으로 더 적은 공간 요구 사항으로 저장 미디어에 다시 저장

데이터 분류 방식에 따른 유형

고정 블록 중복 제거(Fixed block deduplication)
- 데이터를 고정된 블록 크기로 분류해 중복제거를 진행하는 것
- 고정된 블록 크기로 단순화 한 해시 알고리즘을 쓰기 때문에 중복 제거 속도가 빠르고 CPU 부하가 적음
- 모든 데이터 유형에 고정된 크기로 중복을 제거하기 때문에 중복 제거율이 떨어지는 편
- CPU 부하가 적은 특성으로 인해 메인 스토리지에 사용하기 적합
가변 블록 중복 제거(Variable block deduplication)
- 데이터 유형에 맞게 블록 크기를 자동으로 나누어 분류해서 중복제거를 진행
- 블록 크기를 유연하게 조정할 수 있어 데이터 유형이 다양한 경우에 적합하며, 매우 높은 중복제거 효율
- 블록 크기 파악 및 해시 처리등으로 CPU 부하가 높아 워크로드에 부담이 많은 메인 스토리지에는 적합하지 않고 백업용 스토리지에 적합

진행 위치에 따른 유형

소스 기반 중복 제거(Source-based deduplication)
- 소스 측에서 중복제거를 진행한 후 타겟에 전송하는 방식
- 타겟으로 전송되는 데이터양을 크게 감소시킬 수 있고, 전반적인 백업 속도를 향상
- 중복제거를 위한 해시 생성 작업으로 인해 소스 측 CPU 리소스가 소모되고, 데이터 복구 속도가 느림
- 스 중복제거는 대역폭을 절약하여 낮은 대역폭 환경에서의 원격 백업에 특화되어 있고, SW 백업 에이전트만 설치하기 때문에 구축이 간단해 소규모 원격 사무소에 적합
- 부가적으로 백업 장치의 용량과 비용 효율 확보에 적합
타깃 기반 중복 제거(Target-based deduplication)
- 타겟 스토리지에서 진행되는 중복제거를 말함
- 소스에 상관없이 타겟마다 같은 소프트웨어를 사용할 수 있고, 대부분 백업 소프트웨어와 호환된다는 장점
- 소스에 리소스 부하 없이 진행되어 서비스 운용이나 복구 속도에 지장을 주지 않음
- 소스에서 모든 데이터를 그대로 가져오기 때문에 소스 중복제거보다 리소스 활용이 많은 점이 있음
- 중복제거 작업보다 업로드 시 발생하는 리소스 비용이 낮은 경우에 특화되어 있어 소스 측 성능을 확보하기에 적합
- 소스 중복제거에 비해 오래된 기술로 안정적이라 대규모 데이터베이스나 일일 데이터 변경 빈도가 높은 데이터베이스 구축환경에 도입하기 적합

데이터 압축(Compresstion)

한 행에 나타나는 동일한 데이터 시퀀스를 먼저 찾은 다음 첫 번째 시퀀스만 저장하고 다음의 동일한 시퀀스를 행에 나타나는 횟수에 대한 정보로 대체하여 데이터 크기를 줄이는 알고리즘 프로세스
바이너리 수준에서 데이터 크기를 더 작게 만들면 디스크 공간이 덜 사용되므로 사용 가능한 용량에 더 많은 데이터를 저장할 수 있음
데이터 세트 자체의 특성, 즉 압축 가능한 형식인지 여부와 압축 가능한 양에 따라 다름
데이터의 손실을 일으키지 않음

오늘 진짜 양이 너무 많다
머리 터진다ㅏㅏㅏㅏㅏㅏㅏ
정리 하는거만 3시간이 걸렸다. 중간중간 정신 놓고 그냥 복붙도 했어....ㅋㅋ

쿡쿡

https://www.notion.so/a67850905fb843fc9cdcdb173f888338

다음 포스트