[17일차_01] 데이터베이스 기초

 

 

데이터베이스의 필요성

• 메모리에 임시 저장 (In-Memory)
  • 변수를 만들어 값을 저장한 경우, 해당 값은 메모리 상에 일시적으로 저장되지만, 프로그램이 종료될 때 해당 프로그램이 사용하던 데이터도 사라진다
  • 이 말은 변수 등에 저장한 데이터가 프로그램의 실행에 의존한다

 

• 파일 입/출력 (I/O)
  • 파일을 읽는 방식으로 작동하는 형태를 말한다.
  • 데이터가 필요할 때마다 전체 파일을 매번 읽어야 한다.
  • 파일의 크기가 커질수록 이 작업은 버겁고, 비효율적이어서 파일 입출력 방식의 큰 단점이다.
  • 파일이 손상되거나 여러 개의 파일들을 동시에 다뤄야 하거나 하는 등 복잡하고 데이터량이 많아질수록 데이터를 불러들이는 작업이 점점 힘들어진다.

 

RDBMS VS NOSQL

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

데이터베이스는 크게 관계형 데이터베이스와 비관계형 데이터베이스로 구분한다. 관계형 데이터베이스는 SQL을 기반으로 하고, 비관계형 데이터베이스는 NoSQL로 데이터를 다룬다.

 

• SQL(Structured Query Language)(구조화 쿼리 언어)(관계형 데이터베이스)
  • 데이터베이스의 프로그래밍 언어로서 주로 관계형 데이터베이스에서 사용
  • SQL을 사용하기 위해서는 데이터가 구조가 고정되어 있어야 하는 구조화된 쿼리 언어이다.
  • MySQL, Oracle, SQLite, PostgreSQL 등 다양한 데이터베이스에서 SQL 구문을 사용한다.

 

• NoSQL (비구조화 쿼리 언어)(비관계형 데이터베이스)
  • SQL을 사용할 수 있는 데이터베이스와 달리, 데이터의 구조가 고정되어 있지 않은 데이터베이스
  • 관계형 데이터베이스와는 달리, 테이블을 사용하지 않고 데이터를 다른 형태로 저장한다.
  • NoSQL의 대표적인 예시는 MongoDB 와 같은 문서 지향 데이터베이스이다.

 

• 관계형 데이터베이스
  • 테이블의 구조와 데이터 타입 등을 사전에 정의하고, 테이블에 정의된 내용에 알맞은 형태의 데이터만 삽입할 수 있다.
  • 관계형 데이터베이스는 행(row)과 열(column)로 구성된 테이블에 데이터를 저장한다.
  • 각 열은 하나의 속성에 대한 정보를 저장하고, 행에는 각 열의 데이터 형식에 맞는 데이터가 저장됨 특정한 형식을 지키기 때문에, 데이터를 정확히 입력했다면 데이터를 사용할 때는 매우 수월하다.
  • - 관계형 데이터베이스에서는 SQL을 활용해 원하는 정보를 쿼리할 수 있다.
  • - 관계형 데이터베이스에서는 스키마가 뚜렷하게 보인다는 말과 같다.
  • - 관계형 데이터베이스에서는 테이블 간의 관계를 직관적으로 파악할 수 있다.

 

• 스키마
  • 데이터베이스의 구조와 제약 조건에 관한 전반적인 명세를 기술한 메타데이터의 집합이다.
  • 데이터베이스를 구성하는 데이터 개체(Entity), 속성(Attribute), 관계(Relationship) 및 데이터 조작 시 데이터 값들이 갖는 제약 조건 등에 관해 전반적으로 정의한다.

 

NoSQL 기반의 비관계형 데이터베이스는 구성

 

• Key-Value 타입
  • - 속성을 Key-Value의 쌍으로 나타내는 데이터를 배열의 형태로 저장한다.
  • - 여기서 Key는 속성 이름을 뜻하고, Value는 속성에 연결된 데이터 값을 의미한다.
  • - Redis, Dynamo 등이 대표적인 Key-Value 형식의 데이터베이스이다.

 

• 문서형(Document) 데이터베이스
  • - 데이터를 테이블이 아닌 문서처럼 저장하는 데이터베이스를 의미한다
  • - 많은 문서형 데이터베이스에서 JSON과 유사한 형식의 데이터를 문서화하여 저장한다
  • - 각각의 문서는 하나의 속성에 대한 데이터를 가지고 있고, 컬렉션이라고 하는 그룹으로 묶어서 관리한다
  • - 대표적인 문서형 데이터베이스에는 MongoDB 가 있다.

 

 

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

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

 

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

 

• 쿼리(Querying)
  • 데이터베이스나 파일의 내용 중 원하는 내용을 검색하기 위하여 몇 개의 코드(code)나 키(Key)를 기초로 질의하는 것을 말한다.
  • 비관계형 데이터베이스의 쿼리는 데이터 그룹 자체를 조회하는 것에 초점을 두고 있다.
    • 구조화되지 않은 쿼리 언어로도 데이터 요청이 가능하며 UnQL이라고 말하기도 한다.
  • 관계형 데이터베이스는 테이블의 형식과 테이블 간의 관계에 맞춰 데이터를 요청해야 한다.
    • 정보를 요청할 때, SQL과 같이 구조화된 쿼리 언어를 사용한다.

 

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

 

 

 

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

• 관계형, 비관계형 데이터베이스를 모두 사용하여 서비스에 맞고 설계하고 있다
• NoSQL 기반의 비관계형 데이터베이스가 확장성이나 속도면에서 더 뛰어나다
• 고차원으로 구조화된 SQL 기반의 데이터베이스가 더 좋은 성능을 보여주는 서비스도 있다
• 여러 사용 사례를 살펴보고 적절한 데이터베이스를 선택하는 것이 중요

 

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

1. 데이터베이스의 ACID 성질을 준수해야 하는 경우

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

 

2. 소프트웨어에 사용되는 데이터가 구조적이고 일관적인 경우

• 소프트웨어(프로젝트)의 규모가 많은 서버를 필요로 하지 않고 일관된 데이터를 사용하는 경우, 관계형 데이터베이스를 사용하는 경우가 많다
• 다양한 데이터 유형과 높은 트래픽을 지원하도록 설계된 NoSQL 데이터베이스를 사용해야만 하는 이유가 없기 때문이다.

 

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

1. 데이터의 구조가 거의 또는 전혀 없는 대용량의 데이터를 저장하는 경우

• 대부분의 NoSQL 데이터베이스는 저장할 수 있는 데이터의 유형에 제한이 없다.
• 필요에 따라, 언제든지 데이터의 새 유형을 추가할 수 있다
• 소프트웨어 개발에 정형화되지 않은 많은 양의 데이터가 필요한 경우, NoSQL을 적용하는 것이 더 효율적일 수 있다.

 

2. 클라우드 컴퓨팅 및 저장공간을 최대한 활용하는 경우

• 클라우드 기반으로 데이터베이스 저장소를 구축하면, 저렴한 비용의 솔루션을 제공받을 수 있다. - 소프트웨어에 데이터베이스의 확장성이 중요하다면, 별다른 번거로움 없이 확장할 수 있는 NoSQL 데이터베이스를 사용하는 것이 좋다.

 

3. 빠르게 서비스를 구축하는 과정에서 데이터 구조를 자주 업데이트 하는 경우

• NoSQL 데이터베이스의 경우 스키마를 미리 준비할 필요가 없기 때문에 빠르게 개발하는 과정에 매우 유리하다
• 시장에 빠르게 프로토타입을 출시해야 하는 경우가 이에 해당한다
• 소프트웨어 버전별로 많은 다운타임(데이터베이스 서버를 오프라인으로 전환하여 데이터 처리를 진행하는 작업 시간) 없이 데이터 구조를 자주 업데이트 해야 하는 경우, 스키마를 매번 수정해야 하는 관계형 데이터베이스 보다 NoSQL 기반의 비관계형 데이터베이스를 사용하는 게 더 적합하다

 

• 인덱스(Index)
  • 인덱스는 데이터베이스에 저장된 기본데이터(primary data)에서 파생된 부가적인 메타데이터(meta-data : 데이터에 관한 구조화된 데이터)이며, 우리가 원하는 데이터의 위치를 찾는데 도움을 주는 이정표가 된다.
  • 인덱스는 책에서의 목차 혹은 색인이라고 생각하면 된다. 책에서 원하는 내용을 찾을 때 목차나 색인을 이용하면 훨씬 빠르게 찾을 수 있는데, 마찬가지로 테이블에서 원하는 데이터를 찾기 위해 인덱스를 이용하면 빠르게 찾을 수 있다.
  • 데이터 = 책의 내용, 인덱스 = 책의 목차, 물리적 주소 = 책의 페이지 번호라고 할 수 있다.
  • 테이블의 특정 컬럼(Column)에 인덱스를 생성하면, 해당 컬럼의 데이터를 정렬한 후 별도의 메모리 공간에 데이터의 물리적 주소와 함께 저장된다.
  • 컬럼의 값과 물리적 주소를 (key, value)의 한 쌍으로 저장한다.
  • 데이터베이스의 테이블에 대한 검색 속도를 향상시켜주는 자료구조이며 그의 따라 부하 분산한다
    인덱스의 편집사항(추가, 삭제 등)은 데이터베이스의 내용에는 영향을 주지 않고 쿼라 성능에만 영향을 준다.

 

• 인덱스를 사용하면 좋은 경우
  • - 인덱스를 효율적으로 사용하기 위해선 데이터의 range가 넓고 중복이 적을수록, 조회가 많거나 정렬된 상태가 유용한 컬럼에 사용하는 것이 좋다. 따라서 다음과 같은 경우들에 인덱스를 사용하면 효율적이다.
  • - 규모가 큰 테이블
  • - 삽입(INSERT), 수정(UPDATE), 삭제(DELETE) 작업이 자주 발생하지 않는 컬럼
  • - WHERE나 ORDER BY, JOIN 등이 자주 사용되는 컬럼
  • - 데이터의 중복도가 낮은 컬럼

 

• Replication
  • 실시간 복제본 데이터베이스 서버를 운용하는 것을 의미합니다.
  • 기준이 되는 서버를 마스터 서버라 하고, 마스터 서버와 동일한 내용을 갖는 또 다른 서버를 ‘리플리카(Replica)’라 합니다.
  • 데이터베이스 리플리케이션은 기본적으로 데이터 안정성을 위함이다
  • 리플리카 서버는 기본적으로 읽기전용으로 운용

 

• 모든 읽기 처리 요청이 하나의 데이터베이스에 쏠리게 되면, 성능저하로 이어질 가능성이 높다 데이터베이스 자체의 성능을 높여서 대처할 수 있지만, 이는 일반적으로 높은 비용을 수반한다. 이러한 경우에 레플리카를 읽기전용 데이터베이스로 활용할 수 있습니다. 리더에서는 읽기와 쓰기 처리를 한번에 처리하면서, 쓰기 처리가 발생할 경우 각 레플리카에도 데이터를 저장해서, 동기화를 진행합니다. 레플리카는 최종적으로 리더와 같은 데이터를 가지고 있기 때문에 사용자들이 읽기 요청을 보낼 때 해당사항을 처리할 수 있다. 이렇게 되면 사용자 트래픽이 각 데이터베이스로 분산되기 때문에 성능향상에 도움이 된다.

 

• 데이터베이스가 데이터를 요청하는 곳과 지리적으로 멀 경우 지연시간을 감소시키기 위해서 레플리카의 위치를 각 지역에 분산시켜 배치할 수 있다. 각 지역에 분산 배치된 레플리카는 해당 지역에서 가까운 사용자의 요청을 처리하여 지연시간을 감소시킬 수 있습니다.

 

• 백업본을 이용한 대처는 큰 단점이 있다, 데이터 백업을 주기적이고 자동으로 되도록 해놓았다고 하더라도 백업된 시간과 장애가 발생한 시간 사이의 데이터 변경 사항들은 모두 소실되게 된다.

 

• 리플리카 서버는 ‘아주 약간의 딜레이가 있긴 하지만’ 거의 실시간으로 마스터 서버와 동일한 데이터를 갖고 있기 때문에, 장애 복구 시 데이터 소실이 최소화 즉 시스템 장애 발생시에도 동작할 수 있도록 가용성 확보 할 수 있다

 

• 레플리카 활용 시 고려해야할 사항으로 레플리카를 활용한 데이터베이스 구조를 유지할 때 가장 중요한 것은, 모든 데이터베이스가 정확히 같은 데이터를 가지고 있게 하는 것 이다. 기본적으로 리더가 되는 데이터베이스에 쓰기 요청이 들어왔다면, 해당 데이터는 리더 데이터베이스에 저장되어야 함은 물론, 모든 레플리카에도 똑같이 저장되어야 한다.

 

다른 데이터베이스로 데이터를 복제하는 방식에는, 동기식 복제(synchronous)과 비동기식 복제(Asynchronous)이 사용될 수 있다.

• 동기식 복제(synchronous)

동기식으로 복제가 진행되는 레플리카 구조에서는 리더의 데이터 처리와 별개로 레플리카에서의 데이터 처리까지 모두 완료되어야만 프로세스가 진행된다. 이 경우에 레플리카와 리더 데이터베이스가 일관성 있게 최신 데이터 복사본을 가지고 있는 것을 보장할 수 있다.

그러나 동기식 복제의 경우 네트워크 문제나, 다른 이유로 레플리카가 정상적으로 데이터처리 작업을 완료할 수 없는 경우 응답을 받지 못한 리더 데이터베이스 역시 프로세스를 진행하지 못한다. 리더는 모든 쓰기를 차단하고 동기 레플리카가 회복되기를 기다리기 때문에 시스템 운영이 멈출수 있는 위험이 있다.

• 비동기식 복제 (Asynchronous)

반면 비동기식 복제는 동기식 복제와 다르게 리더가 레플리카의 처리 응답을 기다리지 않다. 리더는 레플리카에 데이터 처리를 요청한 후 자신의 작업을 완료하면 사용자의 요청에 바로 응답한다. 이 경우에는 연결된 모든 레플리카가 어떠한 이유로, 처리를 지속할 수 없더라도 리더는 쓰기 처리를 계속할 수 있다는 장점이 있다. 리더 데이터베이스에 문제가 없다면, 레플리카의 상태와 무관하게 사용자에게 서비스를 계속해서 제공할 수 있다

하지만 레플리카가 읽기 전용으로 이용되고 있을 경우, 사용자에게 리더와 같은 응답을 주지 못하는 경우가 발생할 수 있다. 데이터의 불일치가 발생하기 때문에 불일치 상태가 길어지는 경우 큰 문제가 될 수 있다. 또한 리더가 잘못되고 복구할 수 없는 상황이 발생 시, 팔로워에게 복제되지 못한 모든 처리가 유실될 수 있으며, 클라이언트에게는 정상 작동을 알린 이후임에도 불구하고 지속성을 보장하지 못하는 문제가 발생할 수 있다.

• 반동기식 복제(semi-synchronous)

앞서 설명한 두 복제 방식의 장단점을 보완하기 위해서, 하나의 레플리카는 동기식 복제를 사용하고, 다른 레플리카들은 비동기식으로 사용하는 반동기식 복제도 활용된다.

 

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

•  파티셔닝(partitioning)
  • - 데이터베이스를 여러 부분으로 분할하는 것이다

 

• 파티셔닝 사용의 장점

1. 성능 (Performance)

• - 특정 Query의 성능을 향상시킬 수 있다.
• - 대용량 Data Write 환경에서 효율적이다
• - 필요한 데이터만 빠르게 조회할 수 있으므로 쿼리가 가벼워진다.
• - Full Scan에서 데이터 접근의 범위를 줄여 성능을 향상할 수 있다.

 

2. 가용성 (Availability)

• - 물리적인 파티셔닝으로 전체 데이터의 훼손 가능성이 줄어들고 데이터 가용성이 향상된다.
• - 파티션 별로 독립적으로 백업하고 복구할 수 있다.
• - 테이블의 파티션 단위로 Disk I/O를 분산하여 경합을 줄여 UPDATE 성능을 향상할 수 있다.

 

3. 관리용이성 (Manageability)

• - 큰 테이블들을 제거하여 관리를 쉽게 할 수 있다.

 

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

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

 

• Redis
  • - 데이터베이스의 여러 솔루션 중 하나로 메모리를 사용하는 키, 밸류 형식의 데이터베이스이다
  • - Redis의 최고 장점은 메모리를 사용하기 때문에 매우 빠른 속도를 자랑한다
  • - 일반적인 하드 디스크에 비하여 상대적으로 엄청나게 빠를수도 있지만 메모리라는 제약으로 공간이 크지 않고 키, 밸류(Key, Value) 형식의 입출력 방식이기에 복잡한 데이터베이스에 적합하지 않다.
  • - Redis서버는 Client에서 Read 요청이 들어올때 주서버로부터 값을 가져와 저장한다.
  • - 이때 주서버와 싱크된 데이터 이 외에 추가로 데이터 만료시점을 처리하기 위해서 현재시간이나 만효시간을 함께 저장해야한다.

 

• Read 요청시
  • - 방문자, 사용자의 새로운 데이터 서버에 요청- Redis 서버에서 요청 데이터가 있는지 확인
  • - 데이터가 존재하는 경우 만료여부 확인 후 이 정보를 반환
  • - 정보를 반환한 경우 시간을 현재로 업데이트 후 종료
  • - 데이터가 만료되었거나 없는 경우 삭제 후 주 서버에 요청
  • - 주 서버에서 받은 데이터를 캐싱, 데이터베이스에 저장
  • - 이 값을 방문자에게 반환 후 종료

 

• CUD Create, Update, Delete 요청시
  • - 데이터에 변화가 생겨 해당하는 값의 데이터는 캐싱 값이 아닌 현재 실시간 정보를 보내주는 것이 효과적이다
  • - 캐싱 만료시간이 짧게 설정되어도 없는 데이터를 사용자가 보게되는 일은 없도록 해야할 것이다
  • - 방문자가 CUD를 서버에 요청
  • - CUD 요청을 주서버에 반영하여 업데이트
  • - 변경된 데이터 값을 캐싱데이터인 Redis에서 찾아 삭제 후 종료

 

• 캐시 사용의 장점

성능향상

• 데이터 베이스는 기본적으로 속도 보다는 데이터의 저장과 안정성에 초점을 맞추게 된다.(디스크 기반 데이터 저장소)
• 캐시의 경우에는 임시로 데이터가 저장되는 장소이기 때문에, 저장의 기능보다는 정보를 제공하는 처리 속도에 더 집중 할 수 있다(인 메모리 캐시)
• 사용자의 요청이 반복되는 데이터를 빠르게 제공하기 위해서 캐시를 활용하게 되면, 원본 데이터가 존재하는 데이터베이스에 액세스 하는 것보다 훨씬 빠른 속도로 데이터를 제공하면서 전반적인 애플리케이션 환경이 개선된다.

비용감소

• 데이터 베이스의 성능을 높이거나, 많은 쿼리 요청을 처리하는 것은 모두 많은 비용이 필요
• 캐시를 사용하게 됨으로서 원본 데이터베이스에 대한 쿼리 수를 줄이고, 데이터베이스 자체를 스케일링 할 필요성을 낮추면, 성능 향상과 더불어 비용을 절감하는 효과를 낼 수 있다.