[데이터베이스(Database, DB)란?] Database(DB), DBMS, SQL의 개념

SMALL

IT관련 용어 정리 [데이터베이스] DataBase 란?

오늘은 IT 에서 너무도 많이 사용하는 데이터베이스(DB : Database) 가 무엇인지 알아보도록 하겠습니다.
어려운 말들은 보기도 힘드니 쉽게 이해하면서 가면 좋겠네요.
데이터베이스(database, DB)는 체계화된 데이터의 모임을 뜻합니다.
작성된 목록으로써 여러 응용 시스템들의 통합된 정보들을 저장하여
운영할 수 있는 공용 데이터들의 묶음을 의미합니다.
즉, 여러 사람이 공유하여 사용할 목적으로 통합, 관리하는 데이터의 집합입니다.
데이터 베이스의 시작이 궁금해지는데요,
시초가 어떻게 되는지 살펴보죠.

데이터베이스(DB:database) 의 역사

1950년대에 데이터베이스라는 용어가 미국에서 처음 사용되었으며,
본래는 군비의 집중적·효율적 관리를 위해 컴퓨터를 활용한 도서관 개념을 개발하면서
이를 '데이터의 기지'라는 뜻의 데이터베이스로 일컫게 되었습니다.
역시 기술은 전쟁과 군대 관련해서 시작되는경우가 많네요.
이후 1965년 시스템 디벨로프사가 2차로 개최한
'컴퓨터 중심 데이터베이스 시스템'이라는 심포지엄에서 처음 사용하였습니다.
프로세서, 컴퓨터 메모리, 컴퓨터 스토리지, 컴퓨터 네트워크 분야에서 기술이 진전됨에 따라,
등급 순으로 데이터베이스 및 각 DBMS의 크기, 기능, 성능이 상승해왔습니다.
데이터베이스의 개념
데이터베이스는 여러 사람이 공유하고 사용할 목적으로 통합 관리되는 정보의 집합입니다.
논리적으로 연관된 하나 이상의 자료의 모음으로 그 내용을 고도로 구조화함으로써
검색과 갱신의 효율화를 꾀한 것이죠.
즉, 몇 개의 자료 파일을 조직적으로 통합하여 자료 항목의 중복을 없애고
자료를 구조화하여 기억시켜 놓은 자료의 집합체라고 할 수 있습니다.
공동 자료로서 각 사용자는 같은 데이터라 할지라도
각자의 응용 목적에 따라 다르게 사용할 수 있죠.

DBMS? 그건 뭐죠?

앞서 이야기했듯이, DataBase 는 정보의 집합이라고 했죠.
그럼 정보의 집합을 잘 활용하고 관리가 필요하겠지요?
그래서 DBMS가 생겼습니다.
DBMS는 DataBase Management System 의 약자입니다.
'데이터베이스 관리 시스템' 이란 뜻으로, 데이터베이스를 관리하며
응용 프로그램들이 데이터베이스를 공유하며 사용할 수 있는 환경을 제공하는
소프트웨어 입니다.
DBMS가 실제적으로 관리해주기 때문에 DB = DBMS 의 의미로 사용하는 경우가 많습니다.
- DBMS는 사용자와 DB사이에서 사용자의 요구에 따라 정보를 생성해주고 관리해줍니다.
- DBMS는 데이터의 종속성과 중복성의 문제를 해결해주며, 모든 응용프로그램들이 DB를 공용할 수 있도록
관리해줍니다.
- DBMS는 데이터베이스의 구성, 접근방법 및 권한, 유지관리 등의 기능을 지원합니다.
그렇다면, DBMS는 어떤것이 있을까요?

데이터베이스란?

데이터베이스(DB: Database)는 통합하여 관리되는 데이터의 집합체를 의미합니다.
이는 중복된 데이터를 없애고, 자료를 구조화하여, 효율적인 처리를 할 수 있도록 관리됩니다.
이러한 데이터베이스는 응용 프로그램과는 다른 별도의 미들웨어에 의해 관리됩니다.
데이터베이스를 관리하는 이러한 미들웨어를 데이터베이스 관리 시스템(DBMS: Database Management System)이라고 부릅니다.

DBMS란?

DBMS란 사용자와 데이터베이스 사이에서 사용자의 요구에 따라 정보를 생성해주고 데이터베이스를 관리할 수 있게 해주는 소프트웨어입니다.
DBMS는 기존의 파일 시스템이 갖는 데이터의 종속성과 중복성의 문제를 해결하기 위해 제안된 시스템으로 모든 응용 프로그램들이 데이터베이스를 공용할 수 있도록 관리해줍니다.
DBMS는 데이터베이스의 구성, 접근방법, 유지관리에 대한 모든 책임을 집니다.

데이터베이스의 특징

사용자의 질의에 대하여 즉각적인 처리와 응답이 이루어집니다.
생성, 수정, 삭제를 통하여 항상 최신의 데이터를 유지합니다.
사용자들이 원하는 데이터를 동시에 공유할 수 있습니다.
사용자가 원하는 데이터를 주소가 아닌 내용에 따라 참조할 수 있습니다.
응용 프로그램과 데이터베이스는 독립되어 있으므로, 데이터의 논리적 구조와 응용 프로그램은 별개로 동작됩니다.

SQL(Structured Query Language)

SQL은 데이터베이스에서 데이터를 정의, 조작, 제어하기 위해 사용하는 언어입니다.
따라서 SQL 구문도 위의 목적에 맞게 크게 세 가지로 구분할 수 있습니다.

DDL(Data Definition Language)
DML(Data Manipulation Language)
DCL(Data Control Language)

[데이터베이스 이해하기] Database(DB), DBMS, SQL의 개념

데이터베이스는 IT 분야 뿐만 아니라 다른 분야에서도 보편적으로 사용하는 용어가 되었습니다. 우리의 삶이 데이터베이스와 직/간접적으로 연관되어 있다고 생각해도 무방할 정도입니다. 데이터베이스가 대체 무엇이길래 여기저기 모든 것에 연관되어 있고 비전공자까지 관심을 가지는지 데이터베이스의 개념과 SQL의 관계에 대해 알아보겠습니다.

3줄 요약 KeyPoint

데이터베이스(Database, DB)란? : 데이터의 저장소.
DBMS(Database Management System, 데이터베이스 관리 시스템)란? 데이터베이스를 운영하고 관리하는 소프트웨어.
- 계층형, 망형, 관계형 DBMS 중 대부분의 DBMS가 테이블로 구성된 관계형 DBMS(RDMBS)형태로 사용돕니다.
SQL(Structured Query Language)란? 구조화된 질의 언어라는 뜻으로 관계형 데이터베이스에서 사용되는 언어. 표준 SQL을 배우면 대부분의 DBMS를 사용할 수 있습니다.

데이터베이스(Database, DB)란?

데이터베이스를 한 마디로 정의하면 ‘데이터의 집합’이라고 할 수 있습니다.

데이터베이스에는 일상생활 대부분의 정보가 저장되고 관리됩니다. 오늘 보내거나 받은 카카오톡 메시지, 인스타그램에 등록한 사진, 버스/지하철에서 찍은 교통카드, 카페에서 구매한 아이스 아메리카노 등의 정보가 모두 데이터베이스에 기록됩니다.

DBMS란?

데이터베이스를 ‘데이터의 집합’이라고 정의한다면, 이런 데이터베이스를 관리하고 운영하는 소프트웨어를 DBMS(Database Management System)라고 합니다. 다양한 데이터가 저장되어 있는 데이터베이스는 여러 명의 사용자나 응용 프로그램과 공유하고 동시에 접근이 가능해야 합니다.

가까운 예로 은행의 예금 계좌는 많은 사람들이 가지고 있습니다. 여러 명의 예금 계좌 정보를 모아 놓은 것이 데이터베이스입니다. 은행이 가지고 있는 예금 계좌 데이터베이스에는 여러 명이 동시에 접근할 수 있습니다. 예금 계좌 주인, 은행 직원, 인터넷 뱅킹, ATM 기기 등에서 모두 접근이 가능하니까요. 이러한 것이 가능한 이유는 바로 DBMS가 있기 때문입니다.

DBMS의 종류

DBMS와 같은 소프트웨어는 특정 목적을 처리하기 위한 프로그램입니다. 예를 들어 문서를 작성하기 위해서는 아래아한글(HWP)이나 워드(Word), 표 계산을 위해서는 엑셀(Excel)이나 캘크(Calc), 멋진 사진을 편집하려면 포토샵(PhotoShop)이나 김프(Gimp)와 같은 소프트웨어를 설치해야 합니다.

마찬가지로 데이터베이스를 사용하기 위해서도 소프트웨어, 즉 DBMS를 설치해야 하는데 대표적으로 MySQL, 오라클(Oracle), SQL 서버, MariaDB 등이 있습니다. 소프트웨어 각각의 사용 방법과 특징이 다르지만 특정 목적을 위해서는 어떤 것을 사용해도 무방합니다.

대표적인 DBMS의 특징입니다. SQL 공부가 처음이라면 이중에서 비교적 쉬우면서 실무에서도 인기가 많은 MySQL이라는 소프트웨어를 설치해서 사용할 것을 추천합니다.

DBMS	제작사	작동 운영체제	기타
MySQL	Oracle	Unix, Linux, Windows, Mac	오픈 소스(무료), 상용
MariaDB	MariaDB	Unix, Linux, Windows	오픈 소스(무료), MySQL 초기 개발자들이 독립해서 만듦
PostgreSQL	PostgreSQL	Unix, Linux, Windows, Mac	오픈 소스(무료)
Oracle	Oracle	Unix, Linux, Windows	상용 시장 점유율 1위
SQL Server	Microsoft	Windows	주로 중/대형급 시장에서 사용
DB2	IBM	Unix, Linux, Windows	메인프레임 시장 점유율 1위
Access	Microsoft	Windows	PC용
SQLite	SQLite	Android, iOS	모바일 전용, 오픈 소스(무료)

DBMS의 분류

DBMS의 유형은 계층형(Hierarchical), 망형(Network), 관계형(Relational), 객체지향형(Object-Oriented), 객체관계형(Object-Relational) 등으로 분류됩니다. 현재 사용되는 DBMS 중에는 관계형 DBMS가 가장 많은 부분을 차지하며, MySQL도 관계형 DBMS에 포함됩니다.

계층형 DBMS

계층형 DBMS(Hierarchical DBMS)는 처음으로 등장한 DBMS 개념으로 1960년대에 시작되었습니다. 아래 그림과 같이 각 계층은 트리tree 형태를 갖습니다. 사장 1명에 이사 3명이 연결되어 있는 구조입니다. 계층형 DBMS의 문제는 처음 구성을 완료한 후에 이를 변경하기가 상당히 까다롭다는 것입니다. 또한 다른 구성원을 찾아가는 것이 비효율적입니다. 예를 들어 재무2팀에서 회계팀으로 연결하려면 재무이사 → 사장 → 회계이사 → 회계팀과 같이 여러 단계를 거쳐야 합니다. 지금은 사용하지 않는 형태입니다.

망형 DBMS

망형 DBMS(Network DBMS)는 계층형 DBMS의 문제점을 개선하기 위해 1970년대에 등장했습니다. 다음 그림을 보면 하위에 있는 구성원끼리도 연결된 유연한 구조입니다. 예를 들어 재무2팀에서 바로 회계팀으로 연결이 가능합니다. 하지만 망형 DBMS를 잘 활용하려면 프로그래머가 모든 구조를 이해해야만 프로그램 작성이 가능하다는 단점이 존재합니다. 역시 지금은 거의 사용하지 않는 형태입니다.

관계형 DBMS

관계형 DBMS(Relational DBMS)는 줄여서 RDBMS라고 부릅니다. MySQL뿐만 아니라, 대부분의 DBMS가 RDBMS 형태로 사용됩니다. RDBMS의 데이터베이스는 테이블(table)이라는 최소 단위로 구성되며, 이 테이블은 하나 이상의 열(column)과 행(row)으로 이루어져 있습니다.

한글이나 워드에서 표를 만들었던 경험이 있을텐데요, 이 표의 모양이 바로 테이블입니다. 친구의 카카오톡 아이디, 이름, 연락처 등 3가지 정보를 표, 즉 테이블로 만들면 다음과 같습니다.

RDBMS에서는 모든 데이터가 테이블에 저장됩니다. 이 구조가 가장 기본적이고 중요한 구성이기 때문에 RDBMS는 테이블로 이루어져 있으며, 테이블은 열과 행으로 구성되어 있다는 것을 파악했다면 RDBMS를 어느정도 이해했다고 할 수 있습니다.

SQL: DBMS에서 사용하는 언어

SQL(Structured Query Language)은 관계형 데이터베이스에서 사용되는 언어로, ‘에스큐엘’ 또는 ‘시퀄’로 읽습니다. 관계형 DBMS 중 MySQL를 배우려면 SQL을 필수로 익혀야 합니다. SQL이 데이터베이스를 조작하는 ‘언어’이긴 하지만 일반적인 프로그래밍 언어(C, 자바, 파이썬 등)와는 조금 다른 특성을 갖습니다.

SQL은 특정 회사에서 만드는 것이 아니라 국제표준화기구에서 SQL에 대한 표준을 정해서 발표하고 있습니다. 이를 표준 SQL이라고 합니다. 그런데 문제는 SQL을 사용하는 DBMS를 만드는 회사가 여러 곳이기 때문에 표준 SQL이 각 회사 제품의 특성을 모두 포용하지 못한다는 점입니다. 그래서 DBMS를 만드는 회사에서는 되도록 표준 SQL을 준수하되, 각 제품의 특성을 반영한 SQL을 사용합니다.

다음 그림을 보면 3가지 DBMS 제품(오라클, SQL 서버, MySQL)이 모두 표준 SQL을 포함하고 있습니다. 그래서 표준 SQL을 익히면 대부분의 DBMS에 공통적으로 적용할 수 있습니다. 각 DBMS는 추가로 자신만의 기능도 가지고 있어서 이렇게 변경된 SQL을 오라클은 PL/SQL, SQL서버는 T-SQL, MySQL은 SQL로 부릅니다.

데이터베이스는 여러 사람이 공유하여 사용할 목적으로 체계화해 통합, 관리하는 데이터의 집합합니다.

'주소록' 과 같은 데이터를 저장하는 매체가 발전하여 현대의 데이터베이스가 되었다고 볼 수 있습니다.

DB의 기본 기능

데이터의 검색과 갱신

검색
갱신
- 등록
- 수정
- 제거

검색/갱신 때는 데이터 포멧과, 처리 성능에 유의해야 합니다.

동시성 제어

A가 '가'테이블에 한 레코드를 수정 할 때 B가 같은 레코드를 수정하려는 경우, 접근하지 못하게 하거나, 조회인 경우만 접근이 가능하거나, 접근에 제한을 두지 않는 등 여러 방식으로 갱신의 무결성을 제한합니다.

장애 대응

데이터는 매우 중요한 정보가 모여져 있기 때문에 DBMS는 데이터 보호와 장애 대책에 예민하다고 표현 할 정도로 철저히 관리합니다.

장애가 끊이지 않는 이유

엔지니어가 '서비스 레벨' 과 '비용' 이란 트레이드 오프의 딜레마로 고민하기 때문입니다.

보안

데이터베이스는 사용자로부터 보이지 않도록 설계됩니다

사용자는 서버를 의식할 팔요가 없습니다.

사용자에 가까운 기술은 대부분 클라이언트 기술 중심이라 서버의 기술은 의식되지 않습니다.

데이터베이스는 기밀성이 높습니다

데이터베이스는 사생활이나 개인정보와 같은 데이터를 다루고 있습니다.

그렇기 때문에 사용자가 데이터베이스에 접속할 수 없도록 제한한다. (실제로 시스템 개발에 종사하는 엔지니어도 기밀정보가 담긴 데이터베이스에 접근하기 힘듭니다.)

데이터베이스의 종류

계층형 데이터베이스

현대적인 데이터베이스 중 가장 최초로 등록된 데이터베이스로 조직도나 전체 구조도 같은 형태를 가집니다.

관계형 데이터베이스

2차원 표 형식으로 데이터를 관리하는 데이터베이스로, 현재 가장 많이 쓰이고 있습니다.

겍체지향 데이터베이스와 XML 데이터베이스

각각 '겍체'와 'XML'이라는 형식으로 데이터를 관리하는 데이터베이스다. 자주 쓰이지는 않습니다.

NoSQL 데이터베이스

'No only SQL'의 약자로 관계형 데이터베이스 다음으로 주목을 받아오고 있습니다.
이 타입의 데이터베이스는 관계형 데이터베이스에 있는 기능 일부를 포기하고 성능(처리속도)를 높입니다.
대량의 데이터를 고속으로 처리해야 하는 웹 서비스와 잘 맞아서 자주 쓰입니다.

RDB란

현재 주류를 이루는 데이터베이스
2차원 표(엑셀, 스프레드시트를 생각하면 됨) 형태
혁신성
- 역사적 : 소프트웨어를 사용해 2차원 표의 형태로 데이터를 관리하는 최초의 소프트웨어
- 기능적 : 프로그래밍 언어를 습득하지 않고 데이터를 조작할 수 있습니다.

SQL이란

자연어처럼 사용하는 데이터 조작

데이터베이스와 DBMS 차이

데이터베이스는 추상적 개념이고 DBMS는 구체적 구현입니다.

소프트웨어와 데이터베이스의 관계

시스템은 단순 데이터베이스로만 만들수 없다. 다른 여러 소프트웨어와 조합해서 만들어지는데 이 작업을 SI( System Integration ) 라고 합니다.

사용되는 소프트웨어는 아래처럼 분류됩니다.

DBMS는 가운데에 존재하는 '미들웨어' 중 하나입니다.

3가지 레이어의 특성과 관계

운영체제

운영체제(OS, Operating System) 란 시스템을 동작하게 하기 위한 일종의 토대 역할을 합니다.

자세히 말하자면 시스템 하드웨어를 관리하고, 응용 소프트웨어를 실행하기 위하여 하드웨어 추상화 플랫폼과 공통 시스템 서비스를 제공합니다.

상용 시스템을 개발할 때는 주로 아래의 OS를 사용합니다.

Window Window Server 시리즈
Linux Red Hat, CentOS
Unix HP-UX, AIX, Solaris

미들웨어

'OS에 설치하여 동작하는 것'을 미들웨어라고 합니다.

데이터베이스의 구현체(DBMS)는 기본적으로 대부분 OS에 호환되도록 만들었기 때문에 기술적으로 가능한 조합의 수는 매우 다양합니다.

이런 OS와 DBMS의 조합을 선택할 때는 주로 다음과 같은 점을 고려합니다.

예산
제품 기능
개발자와 운용자의 기술 조합

제품에 따라 기능이 다르다

OS와 DBMS의 조합을 변경하는 일을 마이그레이션이라고 합니다.

OS만 이행 : DBMS의 수정은 적습니다.
DBMS만 이행 : DBMS의 수정이 많습니다.
둘 다 이행 : 가장 위험합니다.

애플리케이션

애플리케이션( Application ) 이란 특정 기능을 가진 소프트웨어로 사용자에게 가장 가까운 소프트웨어입니다.

애플리케이션과 데이터베이스의 관계

사용자와 데이터베이스 사이에 애플리케이션이 있고, 사용자는 애플리케이션을 이용해 데이터베이스를 이용하므로 앞서 말했던 사용자 입장에서 데이터베이스를 몰라도 된다는 이유가 이 때문입니다.

우리는 왜 시스템에 돈을 내는가

'대가'를 얻기 위해서

시스템을 새롭게 만들거나 서비스로서 제안하는 목적은 '편리'를 제공하는 대가로 이익을 얻기 때문입니다.

즉, 돈을 벌기 위해서.

이익과 비용의 균형

결국 이익을 얻기 위해서 하는 일이므로 비용은 한정되어 있고, 그렇기에 비용에 대한 트레이드 오프가 발생합니다.

초기 비용과 운용 비용

초기 비용 : 최초에 지급 하는 돈 - 하드웨어 구매 비용, 서비스 제작을 위한 직원들 급여
운용 비용 : 서비스를 운용하는 기간에 계속해서 지급하는 돈 - 유지 보수 비용

데이터베이스의 초기 비용

데이터베이스의 초기 비용으로는 라이센스 비용이 있습니다.

유료 소프트웨어를 사용하는 경우 라이센스료를 기업에 지불해야 합니다.

기업은 라이센스료를 받은 대신 관리를 해주거나 편리한 기능을 제공해줍니다.

데이터베이스의 운용 비용

데이터베이스의 운용 비용으로는 기술 지원 비용이 있습니다.

데이터베이스를 사용하다 보면 오류가 발생해서 데이터가 적재되지 않거나 날아가는 등 문제가 생깁니다.

이런 경우 기술적인 Q&A 부터 긴급 수정 프로그램 배포 까지 개발자의 지원이 필요하고 이 지원을 받기 위해 비용을 지불합니다.

대표적인 기술 지원 서비스는 다음과 같습니다.

기술 Q&A
버그 수정을 위한 프로그램 배포
업데이트 관리
새로운 버전의 OS나 하드웨어에 대응
전문 기술자나 컨설턴트를 통한 문제 해결
노하우나 버그 정보 같은 기술 데이터베이스로의 접근 권리

초기 비용과 운용 비용의 조합

3가지 조합이 존재한다.

초기 비용 있음 + 운용 비용 입니다
- Oracle이나 SQL Server 등 일반 벤더 제품의 데이터베이스를 사용하는 경우로 가장 일반적입니다.
초기 비용 없음 + 운용 비용 있습니다.
- 오픈소스 소프트웨어를 사용해 라이센스료 지불 없이 사용하는 경우로 MySQL이 있습니다.
초기 비용 있음 + 운용 비용 있음
- 이는 유지 보수 계약을 맺지 않아 기술 지원이 없는 상태를 의미하므로 현실적으로 불가능합니다.

임대 모델과 구매 모델

임대 모델은 말 그대로 DBMS를 임대 하여 사용하는 것입니다.

장점 : 초기 비용이 없고, 관리(도입과 폐지, 이관)가 편리합니다
단점 : 오랜 기간 서비스를 운용하는 경우 결과적으로 비용이 더 많이 들 수 있고, 장기적으로 제공 업체가 운용 비용을 상향 할 수도 있습니다.

구매 모델 역시 마찬가지로 라이센스료를 지불에 DBMS를 구매하여 사용하는 것입니다.

장점 : 한 번 구매 이후 반영구적 사용, 전체 비용의 변동 위험이 적고, 장기적인 계획을 세울 수 있습니다.
단점 : 초기 비용의 필요, 이관이 어렵습니다.

아키텍쳐란

아키택쳐라는 말은 여러 의미가 있지만 주로

시스템을 만들기 위한 물리 레벨의 조합
시스템의 목적과 기능

이라는 의미로 쓰입니다.

아키텍쳐 설계

아키텍쳐 설계는 매우 심도있는 영역이여서 서버, OS, 기타 미들웨어, 저장소, 로드벨러서나 방화벽 같은 네트워크 기기까지 폭넓은 지식을 요구합니다.

이런 아키텍쳐 설계는 이전 장에서 설명한 '돈'의 영역과 밀접한 관련이 있습니다.

아키텍쳐는 변경이 어렵기 때문에 초반에 결정하는 편입니다.

데이터베이스의 아키텍쳐 - 역사와 개요

데이터베이스에 관한 아키텍쳐늬 역사는 크게 3가지가 있습니다.

Stand-alone (~ 1980)
클라이언트/서버 (1990 ~ 2000)
Web 3계층 (2000 ~ 현재)

Stand-alone

데이터베이스가 동작하는 기계가 LAN이나 인터넷에 연결되지 않고 독립되어 동작하는 구성

Stand-alone 장점

구축이 매우 간단하다.
외부에서 접속이 불가능하여 보안성이 높습니다.

Stand-alone 단점

물리적으로 떨어진 장소에서 접근할 수 없습니다.
복수 사용자가 동시에 작업할 수 없습니다.
가용성이 낮습니다.
- 서버가 1대 뿐이라 장애 발생 시 서비스가 정지합니다.
확장성이 부족합니다.
- 서버가 1대 뿐이라 성능이 한계인 경우 기기의 성능을 업그레이드 하는 방법 밖에 없습니다.

클라이언트/서버

데이터베이스 서버 1대에 복수의 사용자가 접근하는 구성을 말하여, 클라이언트와 서버 2개의 레이어로 구성되기 때문에 '2계층 구성'이라고도 부릅니다.

이어서 말할 이유 때문에 기업이나 조직 내의 닫힌 네트워크(LAN)에서 주로 쓰입니다.

클라이언트/서버 장점

복수 사용자가 물리적으로 떨어진 상황에서 네트워크를 이용해 접근 할 수 있습니다.

클라이언트/서버 단점

사용자가 데이터베이스에 직접 접속하기 때문에 보안상의 위험이 큽니다.
불특정 다수의 사용자가 이용하는 애블리케이션의 관리 비용이 많이 듭니다.
- 이 때에는 사용자의 기기에 직접 어플리케이션을 설치하여 사용하였고, 모든 사용자가 사용할 수 있도록 버전 관리나 대응 등 비용이 많이 들었습니다.
- 모바일 기기에서 어플을 깔아서 사용하는 것을 생각해 봅니다.

Web 3계층

비즈니스 로직을 담당하는 애플리케이션을 서버에서 관리해 이용을 절감하는 방식으로 아래처럼 구성되어 있습니다.

현재 가장 일방적으로 쓰이는 방식

애플리케이션 계층
웹 서버 계층
데이터베이스 계층

Web 3계층 장점

설치를 하지않고 브라우저를 통해 접속이 가능합니다.
사용자가 애플리케이션 관리를 할 필요가 없습니다.
사용자가 직접적으로 데이터베이스에 접근하지 않습니다.

데이터베이스의 아키텍쳐 - 가용성과 확장성

앞서 말한 Stand-alone 구성의 단점 중 2가지 (확장성 부족, 가용성 낮음) 문제가 남아있습니다.

가용성을 높이는 2가지 전략

고품실-소수전략 : 시스템을 구성하는 각 컴포넌트의 신뢰성을 높여 장애 발생률을 낮게 억제하여 가용성을 높입니다.
저품실-다수전략 : 시스템을 구성하는 각 컴포넌트의 여분을 준비해 둡니다.

클러스터란

동일한 기능의 컴포넌트를 병렬화하는 것을 '클러스터링'이라고 부릅니다.

이런 클러스터 구성으로 시스템의 가동률을 높이는 것을 '여유도를 확보한다' 혹은 '다중화' 라고 합니다.

예시로 고장률이 10%인 서버의 대수를 늘리면 고장률이 아래처럼 변화합니다.

서버 1대 10%
서버 2대 1%
서버 3대 0.1%

이로 인해 2가지 사실을 알 수 있습니다.

가동률 100%는 불가능하다.
서버 대수가 증가할수록 1대를 추가함에 따라 얻는 가동률이 낮아집니다.

DB 서버의 다중화 - 클러스터링

DB와 타 서버의 차이

간단히 병렬화를 통해 대수를 증가시킬 수 있는 웹 서버나 다른 서버와 달리 DB는 데이터를 저장하는 영속 계층입니다.

DB 서버의 아키텍처는 DB 서버(계산, 업무 로직)와 저장소(데이터 보존)을 묶어서 생각해야 합니다.

기본적인 다중화

저장소는 그대로 두고 DB 서버를 다중화 하는 방식입니다.

DB 서버의 동작 방식에 따라 2가지로 나뉩니다.

Active-Active 클러스터를 구정하는 컴초넌트를 동시에 가동합니다.
Active-Standby 실제로는 Active 만 동작하고 나머지는 대기(Standby) 한다. (문제 상황 발생 시 동작함)

Active-Active 특징

시스템 다운시간이 짧다.
성능이 비교적 좋다.
- 좋기는 하지만 병목 현상으로 큰 차이는 없을 수도 있습니다.

Active-Standby 구성

Active-Standby 구성은 다시 'Cold-Standby'와 'Hot-Standby'로 나뉩니다.

Cold-Standby : 평소에는 작동하지 않고, Active DB가 다운될 시점에 작동합니다.
Hot-Standby : 평소에도 Standby DB가 작동합니다.

가격 비교

Active-Active
Hot-Standby
Cold-Standby

번호 순으로 비용이 많이 듭니다.

DB 서버의 다중화 - 리플리케이션

DB 서버와 저장소 세트를 복수로 준비해 다중화 하는 방식이다.

주의할 점

Active 측 저장소의 DB는 항상 사용자로부터 갱신된다. 따라서 Standby 측 DB도 갱신을 해서 데이터 정합서을 유지할 필요가 있다.

그래서 동기화 작업을 하는데, 갱신 주기를 어떻게 할 것인가 에서 트레이드 오프가 발생하고,

동기화가 잘 되었는지 확인할지 혹은 하지 않을지 결정하는 부분에도 트레이드 오프가 발생한다.

Shared Nothing

기존의 Active-Active 구성처럼 디스크를 공유하는 것을 Shared Disk 라고 한다.

Shared Disk 방식의 Active-Active 구성은 어딘가에서 한계점에 도달한다. 이런 문제를 해결하기 위해 고안된 것이 Shared Nothing이다. (샤딩 이라고 부르기도 한다.)

Shared Nothing는 네트워크 이외의 자원을 모두 분리하는(아무것도 공유하지 않는) 방식이다.

Shared Nothing의 장점

DB 서버와 저장소의 세트를 늘려서 저장소가 병목이 되는 것을 방지하고 있다.
비용 대비 성능이 좋다.
구현이 쉽다.
- Shared Disk 방식은 복잡한 동기화 구조를 요구하지만 Shared Nothing은 같은 구성의 DB를 횡으로 나열하여 구조가 간단하다.

Shared Nothing의 단점

저장소를 공유하지 않으므로 결국 각각의 DB 서버가 동일한 1개의 데이터에 엑세스 할 수 없다.
- 이런 문제에 터하기 위해 한 DB 서버가 다운되었을 때 다른 DB 서버가 이어받는 커버링 구성 등을 고려해야 한다.

아키텍처 패턴 정리

------- 사진 ------------- 추가 예정

100% 장애 대책은 없다.

장애 대책에 대한 여러가지를 알아봤지만 장애가 발생할 가능성이 0%이 되지는 않는다. 따라서 우리는 장애 이후 '짧은 시간 안에 복구'를 생각해야 한다.

커넥션

애플리케이션과 DBMS를 연결하는 것을 의미한다.

연결하는 방식

클라이언트가 서버프로세스와 연결하는 방식에는 대표적으로 두 가지가 있다.
아래 구조는 오라클을 예시로 가져온 것이다.

전용서버 방식(Dedicated Server)

클라이언트 세션과 서버프로세스가 1:1 로 매핑된다.
오라클의 가장 일반적인 방식이다.
데이터베이스와 물리적인 커넥션을 맺는다.

공유서버 방식(Shared Server)

클라이언트 세션과 서버프로세스가 1:N 로 매핑된다.

커넥션과 세션

여러 DBMS는 동시에 여러 개의 커넥션을 유지하는 것이 가능한데, 어떤 커넥션이 어느 사용자를 위한 것인지 알기 위해 MySQL의 'connection id'와 같이 특정 값을 할당하여 관리한다.

이 커넥션의 시작과 종료 사이에 사용자는 DBMS와 다양한 교한을 하게 되는데, 그 교환의 시작과 종료까지의 단계를 세션(Session)이라고 한다.

커넥션과 세션은 매우 유사한 개념이라서 같은 의미로 사용되는 경우도 있지만, 정확히는 커넥션이 확립된 후에 세션이 만들어진다.

관리 명령

DBMS나 정상적으로 동작하는지 감시하거나 DBMS의 정보수집을 하는 등의 용도로 사용한다.

관리 명령에서 기억해야 할 점

DBMS는 SQL문 이외에도 관리 명령이 있다.
관리 명령의 종류나 문법은 DBMS마다 다르다.

특히 중요한 부분은 후자로, 표준 구문을 사용하는 SQL문과 달리 관리 명령은 DBMS마다 치이가 크다는 것을 알아둬야 한다.

관계형 데이터베이스의 계층

데이터베이스는 여러 데이터를 효율적으로 관리하기 위해 여러 계층으로 구성되어 있다.

인스턴스

안스턴스는 데이터베이스 계층 위에 존재하는 물리적 개념으로, DBMS가 동작할 때의 단위이다.

그래서 OS입장에서는 프로세스라고 부르기도 한다.

데이터베이스

인스턴스 아래에 존재하며 여러 스키마를 가진다. (데이터를 관리하는 기능의 집합체라는 의미도 가지고 있지만 여기에서는 그 뜻이 아니라 '계층'을 의미한다.)

스키마

'틀'이라는 뜻을 가진 단어이다.

우리가 사용하는 컴퓨터의 폴더에 해당하는 계층으로, 하나의 스키마 아래에는 여러 테이블이 존재할 수 있다.

용도별로 나누거나 특정 사용자만 접근할 수 있게 하는 등의 권한 관리도 할 수 있다.

전체 구조

하나의 인스턴스 아래에 여러 데이터베이스, 하나의 데이터베이스 아래에 여러 스키마, 하나의 스키마 아래에 여러 데이터베이스를 가지는 구조이다.

계층 구조가 이해하기 힘든 이유

위에서 설명했던 구조는 어디까지나 ANSI 정한 표준이자 원칙일 뿐이고 굳이 지켜야할 의무는 없다.

따라서 이 계층을 지키는 DBMS로는 PostgreSQL, SQL Sever, DB2 가 있고 스키마와 데이터베이스 한 계층을 DBMS로는 Oracle, MySQL이 있다.

즉, DBMS 마다 계츨 구조가 다르다는 사실을 모르고 있다면 다른 DBMS를 사용했을 때 혼란이 홀 수 있으니 주의해야 한다.

Oracle, MySQL의 계층 구조

MySQL

MySQL에서 데이터베이스와 스키마는 동의어로 아래와 같은 3계층 구조를 가진다.

Oracle

엄밀히 말하면 4계츨 구조를 가지고 있지만 한 인스턴스 아래에는 한 데이터베이스를 져야 한다는 독자적 제약이 있어 실질적으로 3계층 구조처럼 쓰인다.

1. 아키텍처개관

가. ORACLE 아키텍처

정의

데이터베이스 : 물리적인 디스크에 저장된 데이터집합(데이터파일, 리두로그파일, 컨트롤파일)
인스턴스 : 공유메모리(SGA)와 이를 엑세스하는 프로세스 집합

★ 하나의 인스턴스는 하나의 데이터베이스를 엑세스(Single), 여러개의 인스턴스는 하나의 데이터베이스를 엑세스(RAC)

나. SQL Server 아키텍처

정의

하나의 인스턴스당 최고 32,767개의 데이터베이스를 정의해서 사용
기본적으로 시스템데이터베이스가 만들어지면, 사용자데이터베이스를 추가하여 생성하는 구조

시스템데이터베이스 : mster, model, msdb, tempdb 등
사용자데이터베이스 : 데이터파일(mdf), 트랜잭션로그파일(ldf), 보조데이터파일(ndf)

2. 프로세스

서버프로세스 : 전면에 나서 사용자가 던지는 각종 명령을 처리
백그라운드프로세스 : 뒤에서 묵묵히 주어진 역할을 수행

가. 서버프로세스(Server Process)

사용자 프로세스와 통신하면서 사용자의 각종 명령어 처리
ORACLE : 서버프로세스
SQL Server : Worker thread

처리절차
- 사용자의 요청
- SQL 파싱
- 커서를 열어서 SQL을 실행하면서 블록 READ
- 읽은 데이터를 정렬하여 요청한 결과집합을 만들어 네트워크를 통해 전송

클라이언트가 서버프로세스와 연결하는 방식(예 오라클)

1) 전용서버 방식(Dedicated Server)
- 클라이언트 세션과 서버프로세스가 1:1 로 매핑
- 오라클의 가장 일반적인 방식
- 클라이언트 요청에 의해 리스너 프로세스는 dedicated server 생성
- 새로운 dedicated server 프로세스는 리스너에 의해 커넥션 권한을 상속받음
- 데이터베이스와 물리적인 커넥션을 맺음

2) 공유서버 방식(Shared Server)
- 클라이언트 세션과 서버프로세스가 1:N 로 매핑
- 클라이언트 요청에의해 리스너 프로세스는 현재 사용가능한 dispatcher pool 탐색확인
- 리스너는 사용가능한 dispatcher커넥션 정보를 클라이언트에 되돌려줌
- 클라이언트는 리스너 접속을 끝내고 바로 dispatcher 로 접속

나. 백그라운드프로세스

ORACLESQL Server설명

SMON(System Monitor)	Database cleanup / Shrinking Thread	장애가 발생한 시스템을 재기동할 때 인스턴스 복구를 수행하고, 임시 세그먼트와 익스텐트를 모니터링한다
PMON(Process Minitor)	Open Data Services(OPS)	이상이 생긴 프로세스가 사용하던 리소스를 복구한다
DBWn(Database Writers)	Lazywriter Thread	버퍼 캐시에 있는 더티 버퍼를 데이터 파일에 기록
LGWR (Log Writer)	Log writer Thread	로그 버퍼 엔트리를 redo 로그 파일에 기록한다
ARCn(Archiver)	N/A	꽉찬 리두로그가 덮어 쓰여지기 전에 archive로그 디렉토리로 백업한다
CKPT(Checkpoint)	Database Checkpoint Thread	checkpoint 프로시스는 이전의 checkpoint 가 일어났던 마지막 시점 이후의 데이터베이스 변경 사항을 데이터파일에 기록하도록 트리거링하고, 기록이 완료되면 현재 어디까지 기록했는지를 컨트롤 파일과 데이터 파일 헤더에 기록한다. 좀더 자세히 설명하면 wirte Ahead Logging 방식을 사용하는 DBMS는 리두로그에 기록해 둔 버퍼 블록에 대한 변경사항 중 현재 어디까지를 데이터 파일에 기록했는지 체크 포인트정보를 관리해야 한다. 이는 버퍼캐시와 데이터 파일이 동기화된 시점을 가리키며, 장애가 발생하면 마지막 체크포인트 이후 로그 데이터만 디스크에 기록함으로써 인스턴스를 복구할수 있도록 하는 용도로 사용된다.이 정보를 갱신하는 주기가 길수록 장애 발생시 인스턴스 복구 시간도길어진다.
RECO(Recoverer)	Distributed Transaction Coordinator(DTC)	분산 트랜잭션 과정에 발생한 문제를 해결한다

3. 파일구조

가. 데이터파일1) 블록(=페이지)

대부분의 DBMS에서는 I/O 블록단위로 이루어짐
데이터를 읽고 쓸때의 논리적인 단위
SQL 성능을 좌우하는 가장 중요한 성능지표
옵티마이저의 판단에 가장 큰 영향을 미치는 요소

항목오라클SQL Server

명칭	블록	페이지
블록크기	2KB,4KB, 8KB, 16KB, 32KB, 64KB	8KB

2) 익스텐트(Extent)

테이블스페이스로부터 공간을 할당하는 단위

항목오라클SQL Server

크기	다양한크기의 익스텐트	항상 64KB(페이지크기가 8KB이므로)
오브젝트	단일오브젝트사용	2개이상의오브젝트

균일익스텐트(Uniform)
- 64KB 이상의 공간을 필요로 하는 테이블이나 인덱스를 위해 사용됨
- 8개 페이지 단위로 할당된 익스텐트를 단일 오브젝트가 모두 사용
혼합익스텐트(Mixed)
- 한 익스텐트에 할당된 8페이지를 여러 오브젝트가 나누어 사용
- 모든 테이블이 처음에는 혼합 익스텐트로 시작하지만 64KB가 넘으면서 두번째부터는 균일익스텐트 사용

3) 세그먼트(Segment)

테이블, 인덱스,Undo 처럼 저장공간을 필요로하는 데이터베이스 오브젝트 (한개 이상의 익스테트 사용)
파티션은 오브젝트와 세그먼트가 1:M (파티션을 만들면 내부적으로 여러개의 세그먼트가 만들어짐)
한 세그먼트에 할당된 엑스텐트가 여러 데이터파일에 흩어져 저장됨(디스크 경합감소.I/O 분산효과)

오라클SQL Server

세그먼트	힙구조 또는 인덱스구조 오브젝트

4) 테이블스페이스(Tablespace)

세그먼트를 담는 콘테이너로서 여러개의 데이터파일로 구성됨
사용자는 데이터파일을 직접 선택할수 없으므로 실제 파일을 선택하고 익스텐트를 할당하는것은 DBMS의 몫

오라클SQL Server

테이블스페이스

파일그룹

나. 임시파일

대량의 정렬이나 해시 작업을 수행하다가 메모리 공간이 부족해지면 중간 결과집합을 저장하는 용도
오라클에서는 임시 테이블스페이스를 여러개 생성해두고, 사용자마다 별도의 임시 테이블스페이스를 지정해 줄 수 있음

 

create temporary tablespace big_temp 
tempfile '/usr/local/oracle/oradata/ora10g/big_temp.dbf' size 2000m; 

alter user scott temporary tablespace big_temp;

다. 로그파일

DB 버퍼 캐시에 가해지는 모든 변경사항을 기록하는 파일
로그 기록은 Append 방식으로 이루어지기 때문에 상대적으로 매우 빠름
빠른 커밋 지원

로그파일

리두로그(오라클)
- 트랜잭션의 데이터 유실 방지,
- 마지막 체크포인트이후 사고 발생 직전까지 수행되었던 트랜잭션을 Redo 로그를 이용해서 재현함(캐시복구)
- 최소 두개이상의 파일로 구성하며 round-robin 방식 이용하여 사용

트랜잭션로그(SQL Server)
- 데이터파일(데이터베이스)마다 트랜잭션 로그 파일이 하나씩 생성됨(ldf)
- 가상로그파일이라고 불리는 더 작은 세그먼트 단위로 나뉨
- 가상로그파일 개수가 너무 많아지지 않도록 옵션을 지정(로그파일을 넉넉한 크기로 만들어 자동 증가가 발생하지 않도록 하거나, 증가단위를 크게 지정)

Archved(=Offline) Redo 로그

Archived Redo 로그
- 오라클에서 온라인 리두로그가 재사용 되기 전에 다른 위치로 백업해둔 파일
- 디스크가 깨지는 등의 물리적인 저장매채 장애에 대해서 복구하기 위해 사용
- SQL Server는 Archived Redo 로그에 대응되는 개념 없음

4. 메모리구조

시스템 공유 메모리영역

오라클SQL Server

System Global Area(SGA)

Memory Pool

여러 프로세스가 동시에 엑세스할 수 있는 메모리영역
모든 DBMS는 공통적으로 사용하는 캐시 영역이 있음(DB 버퍼캐시, 공유풀, 로그 버퍼)
그 외에 Large Pool, Java Pool, 시스템 구조와 제어 구조를 캐싱하는 영역 포함하고 있음
여러 프로세스가 공유되기 때문에 내부적으로 Latch, 버퍼Lock, 라이브러리 캐시 Lock/Pin같은 엑세스 직렬화 매커니즘 사용

프로세스 전용 메모리영역

오라클은 프로세스 기반의 아키텍처로 서버 프로세스가 자신만의 전용 메모리 영역을 가짐 (Process Global Area(PGA))
데이터를 정렬하고 세션과 커서 정보를 저장
쓰레드기반의 아키텍처를 사용하는 SQL Server 는 프로세스 전용 메모리 영역을 갖지 않는다.

가. DB 버퍼캐시

데이터파일로부터 읽어들인 데이터 블록을 담는 캐시영역
사용자 프로세스는 서버 프로세스를 통해 DB 버퍼 캐시의 버퍼 블록을 동시에 엑세스(내부적으로 Buffer Lock을 통한 직렬화)
Direct Path Read 매커니즘이 작동하는 경우를 제외하면, 모든 블록 읽기는 버퍼 캐시를 통해 이루어짐
디스크에서 읽을때도 버퍼캐시에 적재한 후 읽음
데이터 변경도 버퍼캐시에 적재된 블록을 통해 이루어짐.
변경된 블록(더티버퍼) 은 주기적으로 DBWR 프로세스에 의해 데이터파일에 기록
디스크 I/O는 물리적으로 액세스암이 움직이면서 헤드를 통해 이루어지는 반면, 메모리I/O는 전기적신호에 불과하기 때문에 디스크I/O와는 비교할수 없을 정도로 빠름 .

위와 같은 이유로 버퍼캐시가 필요함

1) 버퍼블록상태

Free Buffer
- 인스턴스 기둥호 아직 데이터가 읽혀지지 않아 비어 있는 상태이거나, 데이터파일과 서로 동기화 되어 언제든지 덮어써도 되는 상태
Dirty Buffer
- 버퍼가 캐시된 이후 변경이 발생하지만, 아직 디스크에 기록되지 않아 데이터파일 블록과 동기화가 필요한 버퍼 블록. 이 버퍼 블록이 재사용 되려면 디스크에 먼저 기록되어야 하고 디스크레 기록된 순간 Free 버퍼로 변경
Pinned Buffer : 읽기 또는 쓰기 작업이 현재 진행중인 버퍼 블록

2) LRU알고리즘

버퍼 캐시는 유한한 자원이므로 모든 데이터를 캐싱해 둘 수 없기 때문에 사용 빈도가 높은 데이터 블록 위주로 버퍼 캐시가 구성 되도록 LRU 알고리즘을 사용
모든 버퍼 블록헤더를 LRU 체인에 연결해 사용 빈도 순으로 위치를 옮기다가(Touch count가 높을수록 MRU) Free 버퍼가 필요해지면, 엑세스 빈도가 낮은(LRU) 쪽 데이터 블록부터 밀어내는 방식

나. 공유풀(shared pool)

딕셔너리캐시와 라이브러리 캐시로 구성되며 버퍼 캐시처럼 LRU 알고리즘을 사용

오라클SQL Server

Shared Pool

Procedure Cache

1) 딕셔너리 캐시

테이블, 인덱스같은 오브젝트는 물론 테이블스페이스, 데이터파일, 세그먼트, 익스텐트, 사용자, 제약사항과 같은 메타정보 저장

2) 라이브러리캐시

SQL 실행에 관련된 모든 객체에 대한 정보 관리
서버 프로세스가 SQL을 작업할때 사용되는 작업공간
SQL에 대한 분석정보 및 실행계획 저장
공유 SQL을 저장하기 위해 사용

라이브러리 캐시는 캐싱된 SQL과 그 실행계획의 재사용성을 높이는 것이 수행 성능을 높이고 DBMS 부하를 최소화 하는 핵심원리임
바인드변수 사용 및 기준에 맞는 SQL 작성으로 재사용성을 높여 줘야 함.

다.로그버퍼

Only Recovery를 위해 사용됨.
DB버퍼에 가해지는 모든 변경사항을 로그퍼버에 먼저 기록

Physiolosical logging
- physical logging과 logical logging의 장점을 결합한것으로 변경된 데이터에 대한 before/after 이미지를 저장하오 opcode(명세서)를 기록하여 완벽한 복구를 보장

page fix rule
- 변경이 시작되는 시점부터 완료되는 시점까지 해당 블록을 보호해주는 아키텍처로 os에서 세마포어를 할당받아서 세마포어가 해당 블록을 보호

log a head
- 데이터 변경작업시에 DBWR에 의한 블록 변경보다 로그를 먼저 기록하는 기법

log force at commit
- 커밋시 리두로그를 먼저 기록하는 기법, 기록하는 속도가 빠른 리두를 먼저 기록하게 하여 중간에 발생하는 장애로부터 완벽한 복구를 보장하는 기법

logical odering of redo
- 로그를 기록할때 정해진 위치가 아닌 순서와 무관하게 기록하되, scn과 RBA 를 이용하여 복구에 대한 순서를 결정하여 빠른 복구 보장

라. PGA(Process Global Area)

오라클의 서버 프로세스는 자신만의 PGA 메모리 영역을 할다받아 이를 프로세스에 종속적인 고유 데이터를 저장하는 용도로 사용
PGA 는 다른 프로세스와 공유되지 않은 독립적인 메모리 공간으로 똑같은 개수의 블록을 읽더라도 SGA 버퍼 캐시에서 읽는것보다 훨씬 빠름

1) UGA(User Global Area)

각 세션을 위한 독립적인 공간
Dedicated Server : PGA 에 UGA 영역 할당
Shared Server: SGA의 Large Pool 또는 Shared Pool 에 UGA 영역 할당

2) CGA(Call Global Area)

오라클은 하나의 데이터베이스 call을 넘어서 다음 call까지 계속 참조되는 정보를 UGA 에 담고, call이 진행되는 동안 필요한 데이터는 CGA에 담는다
Parse Call, Execute Call, Fetch Call 마다 매번 항당 받음
Call이 진행되는동안 Recursive call이 발생하면 그 안에서도 Parse, Execute, Fetch 단계별로 CGA 할당
할당된 공간은 call이 끝나자마자 해제되어 PGA에 반환

3) Sort Area

데이터 정렬을 위해 사용되며, 부족할때마다 chunk 단위로 조금씩 할당됨
세션마다 sort_area_size 파라미터로 설정가능
9i 이상부터는 workarea_size_policy 파라미터를 auto로 설졍하면 내부적으로 알아서 sort area를 할당해줌

구분Sort Area 할당위치

DML	CGA 영역에 할당
SELECT	수행중간단계에 필요한 sort area는 CGA에 할당, 최종 결과집합을 출력하기 직전 단계에서 필요한 sort area는 UGA에 할당

SQL Server는 PGA영역이 없으며 , 정렬을 위해서는 Memory Pool 안에 있는 버퍼캐시에서 수행하며, 세션관련정보는 Memory Pool 안의 Connection Context 영역에 저장

5.대기이벤트

DBMS 내부에서 활동하는 수많은 프로세스간에서는 상호작용이 필요하며, 그 과정에서 다른 프로세스가 일을 마칠때까지 기다려야하는 상황이 발생
그때마다 해당 프로세스는 자신이 일을 계속 진행할 수 있는 조건이 충족될때까지 수면(Sleep)상태로 대기

오라클SQL Server

대기이벤트(Wait Event)

대기유형(Wait Type)

"Response Time Analysis" 성능방법론에서 정의한 서버 응답시간

 
Reponse Time = Service Time + Wait Time
               CPU Time     + Queue Time

서비스시간(Service Time = CPU Time) : 프로세스가 정상적으로 동작하며 일을 수행한 시간
대기시간(Wait Time = Queue Time) : 프로세스가 잠시 수행을 멈추고 대기한 시간

Response Time Analysis 방법론은 Cpu Time과 Wait Time을 각각 break down 하면서 서버의 일량과 대기시간을 분석
Cpu Time은 파싱작업에 소비한 시간인지 쿼리 본연의 오퍼레이션 수행을 위해 소비한 시간인지 분석
Wait Time은 각가 발생한 대기 이벤트를 분석해서 가장 시간을 많이 소비한 이벤트 중심으로 해결방안 모색

가. 라이브러리캐시 부하

라이브러리 캐시에서 SQL 커서를 찾고 최적화 하는 과정에서 경합이 발생하여 나타난 대기이벤트
- latch : shared pool
- latch : library cache

라이브러리 캐시와 관련해서 자주발생하는 대기이벤트로 수행중인 SQL이 참조하는 오브젝트에 다른 사용자가 DDL문장을 수행할때
- library cache lock
- library cache pin

나. 데이터베이스 call과 네트워크 부하

애플리케이션과 네트워크 구간에서 소모된 시간에 의해 나타난 이벤트
- SQL*Net message from client : client로부터 다음 명령이 올때까지 idle 상태로 기다릴때 발생(데이터베이스 경합과 관계없음)
- SQL*Net message to client : 메시지를 보냈는데 메시지를 받았다는 신호가 늦게 도착하는경우 이거나 , 클라언트가 너무 바쁠경우.
- SQL*Net more data to client: 메시지를 보냈는데 메시지를 받았다는 신호가 늦게 도착하는경우 이거나 , 클라언트가 너무 바쁠경우.
- SQL*Net more data from client : 클라이언트로부터 더 받을 데이터가 있는데 지연이 발생한 경우

다. 디스크 부하

디스크 I/O 발생할 때 나타나는 대기 이벤트
- db file sequential read : Single Block I/O. 한번의 I/O call에 하나의 데이터 블록만 읽음. 인덱스 블록을 읽을때 발생
- db file scattered read : Multi Block I/O . Table Full Scan 또는 Index Fast Full Scan 시 나타남
- direct path read
- direct path write
- direct path write temp
- direct path read temp
- db file parallel read

라. 버퍼캐시 경합

버퍼캐시에서 블록을 읽는 과정에서 경합이 발생하여 나타나는 대기 이벤트
- latch : cache buffers chains
- latch : cache buffers lru chain
- buffers busy waits
- free buffer waits

해소 방법은 I/O부하 해소 방법과 비슷함

마. LOCK관련 대기이벤트

Lock과 관련된 대기이벤트
- enq : TM - contention
- enq : TX - row lock contention
- enq : TX - index contention
- enq : TX - allocate ITL entry
- enq : TX contention
- latch free : 특정 자원에 대한 래치를 여러차례(2000번 가량) 요구했지만 해당 자원이 계속 사용중이어서 잠시 대기 상태로 빠질때마다 발생
Lock은 사용자 데이터를 보호하는 반면, Latch는 SGA에 공유되어 있는 갖가지 자료구조를 보호할 목적으로 사용하는 가벼운 LOCK
Latch도 일종의 Lock 이지만 큐잉(Queueing) 매커니즘을 사용하지 않음
특정자원에 액세스하려는 프로세스는 래치 획득에 성공할때까지 반복해서 시도하나, 우선권은 부여받지 못함 (처음시도한 래치가 맨 나중에 래치획득에 성공할수도 있음)

그 외 대기이벤트
- log file sync
- checkpoint completed
- log file switch completion
- log buffer space

트랜잭션이란?

데이터베이스의 상태를 변화시키기 해서 수행하는 작업의 단위를 뜻한다.

하나 이상의 쿼리가 트랜잭션의 단위가 된다.

예를 들면,
A가 B에게 송금 할 때

A의 잔고에서 돈을 빼냄
B의 잔고에 A가 송금한 만큼 돈을 추가함

위 두가지 처리가 하나의 트랜잭션이 된다.

트랜잭션의 4가지 특성

원자성 - Atomicity

트랜잭션의 결과는 전부 성공하거나 전부 실패해야한다.

트랜잭션 진행 중 실패가 일어난다면 ROLLBACK을 실행해 트랜잭션 실행 이전으로 돌아간다.

예시

"트랜잭션이란?"에서 설명한 예시에서 1번이 완료된 이후 2번에서 실패가 일어났지만 1번이 그대로라면 A는 돈을 잃고, B는 돈을 받지 못하는 문제가 발생한다.

일관성 - Consistency

일련의 데이터 조작 전후에 그 상태를 유지해야한다.

데이터베이스 오브젝트에 정합성 제약을 추가하여 유지한다.

예시

각각의 유저가 고유한 ID를 가져야 한다면 ID 컬럼에 UNIQUE 조건을 추가하여 ID 컬럼의 값이 중복되지 않도록 할 수 있다.

고립성 / 격리성 - Isolation

일련의 데이터 조작을 여러 사용자가 동시에 실행되도 각각의 처리가 모순 없이 실행되는 것을 보장한다.

여기에서 설명한 '모순 없다'는 것은 무슨 뜻일까?

복수의 트랜잭션이 순서대로 실행되는 경우와 같은 결과를 얻을 수 있는 상태를 말한다.

이것을 트랜잭션 격리 수준(Transaction Isolation Level)이라고 하는데, 자세한 내용은 다른 글을 참고하길 바란다.

트랜잭션 격리 수준 - Transaction Isolation Level

예시

A와 B, 두 사용자가 있다. 하나의 컬럼의 값을 변경하려고 한다.

계좌을 조회 합니다.
계좌에 1을 뺀 값을 넣습니다.

1이 진행되는 중에 두 사용자가 같은 계좌을 조회한다면 같은 값을 조회하게 됩니다.

이를 10이라고 가정했을 때, 2를 진행하게 되면 A는 10 - 1인 9로 값을 변경합니다.

마찬가지로, B 역시 9로 값을 변경합니다.

두 사용자 모두 같은 계좌에서 1 씩 감소시켰고, 결과는 8 이 되야하지만 9입니다.

이러한 일을 막기 위해서 테이블이 수정 될 때 다른 사용자가 접근하지 못하도록 LOCK을 걸어서 후속 처리를 BLOCK합니다.

지속성 - Durability

일련의 데이터 조작을 완료하고 완료 통지를 받는 시점에 그 조작은 영구적으로 되어 그 결과를 잃지 않는 것을 말합니다.

이는 시스템이 정상일때 뿐만 아니라 데이터베이스나 OS의 이상 종료, 즉 시스템 장애도 견딜 수 있다는 뜻입니다.

지속성을 보장하기 위해 많은 DBMS에서는 트랙잭션 조작을 하드디스크에 로그 라는 형태로 기록하고 있습니다.

시스템에 이상이 발생하면 로그를 이용해 이상 발생 전의 상태까지 복원합니다.

다른 커넥션에선 어떻게 보일까

기본적으로 DDL 이나 DML에 의한 데이터 저장은 트랜잭션이 커밋되기 전까지는 다른 커낵션에서 보이지 않습니다.

하지만 이에 상관없이 다른 커녁션에서 보이는 경우가 있습니다.

오토커밋 설정

트랜잭션의 개시가 명시적으로 지정되지 않았을 때 구별하는 방법으로 2가지 모드가 있습니다.

하나의 SQL 문이 하나의 트랜잭션으로 구분됩니다.
사용자가 COMMIT 또는 ROLLBACK을 실행하기 전까지가 하나의 트랜잭션이 됩니다.

여기서 1 번 (오토커밋)인 경우 자신이 COMMIT을 명시하지 않아도 자동적으로 COMMIT이 되기 때문에 다른 커넥션에서 보이게 됩니다.

DDL에 따은 암묵적인 커밋

DBMS 마다 차이가 있지만 Oracle이나 MySQL에서는 DDL 문 실행시 암묵적인 커밋이 발생합니다.

잠금 타임아웃과 교착 상태

잠금 타임아웃이란

'갱신'과 '참조'는 서로를 블록하지 않지만, '갱신'과 '갱신'이 부딪치는 경우 늦게 온 갱신이 대기 상태가 됩다.

이 때 잠금을 건 쪽이 언제 잠금을 풀지 알 수 없으니 기다리지 않거나, 기다린다면 얼마나 기다릴지 설정할 수 있습니다.

기다리는 시간이 설정했던 시간보다 길어진다면 잠금 타임아웃이 발생하는 것입니다.

교착 상태란

예시

트랜잭션 A와 B 가 있고, 테이블 a, b가 있습니다.

트랜잭션 A는 테이블 a의 잠금을 얻고 b를 갱신하고자 합니다.
트랜잭션 B는 테이블 b의 잠금을 얻고 a를 갱신하고자 합니다.

이 경우 아무리 기다려도 상황이 바뀌지 않는 상태가 되는데 이를 교착 상태라고 합니다.

교착 상태의 대책

트랜잭션을 자주 커밋합니다.
- 더 작은 단위가 되어 교착상태의 가능성을 낮춥니다.
정해준 순서로 테이블에 액세스하게 합니다.
필요없는 경우 읽기 잠금의 사용을 피합니다.
쿼리에 의한 잠금 범위를 더 좁히거나 잠금 정도를 더 작은 것으로 합니다.
한 테이블에서 복수 행을 복수 연결하여 교착 상태가 자주 일어난다면 테이블 단위의 잠금을 사용합니다.
- 이 경우 동시성을 떨어지지만 교착상태는 처리할 수 있어 결과적으로 좋은 결과가 나오기도 합니다.

해서는 안되는 트랜잭션 종류

별 이유가 없다면 아래 방식의 트랜잭션은 사용하지 않는 것이 좋습니다.

오토커밋

여러 DBMS에서 기본적으로 오토커밋을 사용하는데 간단한 쿼리의 실행과 테스트를 하는 경우에는 편리하지만 그 이외의 경우에는 부하가 커 추천하지 않습니다.

긴 트랜잭션

대량 처리를 한개의 트랜잭션으로 실행합니다.
아무것도 하지 않는 트랜잭션을 유의합니다.
트랜잭션 중에 대화(사용자가 반응해야 진행되는) 처리를 넣습니다.
처리 능력 이상의 트랜잭션 수

시작하며

7장에서는 트랜잭션에는 ACID 라는 특성을 다뤘습니다.

ACID의 'D' 는 지속성(Durability)으로, 트랜잭션이 완료되었다는 통지를 사용자가 받은 시점부터 그 결과는 영속화되어 결과를 잃어버리지 않는 것을 말합니다.

이는 서버나 OS의 비정상적인 종료 등의 시스템 장애에도 대응 할 수 있다는 뜻입니다.

지속성을 지키기 위해 어떤 방법을 사용하는지 알아보자.

동기화 방법

대부분 DBMS에선 디스크(HDD, SSD 등)에 데이터를 보존합니다.

지속성을 실현하기위해 '쓰기'를 전부 '동기화 쓰기'로 하면 좋겠지만, 데이터베이스의 쓰기는 디스크의 임의 장소에 무작위로 액세스 하여 쓰기를 실행하기 때문에 실용적이지 않습니다.

그래서 지속성과 성능이 양랍하도록 구현하는데, 일반적으론 아래와 같은 방법을 사용합니다.

로그 선행 쓰기

로그 선행 쓰기(WAL, White Ahead Log)는 데이터베이스의 데이터 파일 변경을 직접 수행하지 않고, 로그로 변경 내용을 기술한 로그 레코드를 써서 동기화하는 구조입니다.

WAL에는 다음과 같은 이점이 있습니다.

디스크에 연속해서 쓰기 때문에 무작위로 쓰는 것보다 성능이 좋습니다.
디스크에 쓰는 용량과 횟수를 줄일 수 있습니다.
데이터베이스에 버퍼를 이용해 데이터베이스의 데이터 파일로의 변경을 효율성 높게 수행합니다.

데이터베이스 버퍼

커밋 시에는 WAL에 변경 내용을 쓰기 때문에 데이터 파일의 변경 내용을 트랜잭션이 커밋됨과 동시에 동기화할 필요가 없습니다.

하지만 트랜잭션마다 비동기적인 쓰기를 하면 로그와 데이터 파일 간 일관성을 유지하기 어렵습니다.

따라서, 일반적인 DBMS는 데이터베이스 버퍼를 준비해 데이터 파일로의 입력을 데이터베이스 버퍼로 일원화해서 단순화 하고 있습니다.

이로인해 효율적으로 데이터의 일관성을 유지할 수 있게 됩니다.

갱신의 흐름은 다음과 같습니다.

버퍼 풀(메모리)에 갱신 대상의 데이터를 포함한 페이지가 있는지 찾는다. 있으면 사용하고, 없으면 디스크에서 페이지를 가져옵니다.
버퍼 풀의 해당 페이지에서 갱신을 수행합니다.
2 의 갱신 내용이 커밋과 함께 로그에 기록된다. 버퍼 풀에서 갱신 되었지만 디스크에 써지지 않은 페이지는 버퍼 풀 내에서 더티 페이지(메모리의 내용과 디스크의 내용이 다른 상태)로 다룹니다.
데이터 페이지는 적절한 순간에 정리되어 데이터 파일로 써진다. 이 작업을 '체크포인트' 라고 합니다.
갱신과 동시에 1 부터 다시 반복한다. 4 가 완료된 시점에서 이전 로그 파일을 불필요해지기 때문에 제거됩니다.

부연 설명 - 오라클 기준

로그 파일 역시 파일이기 때문에 파일을 작성할 때 비효율적인 동기화 쓰기를 작성하지 않고 버퍼를 사용합니다.

여기서 "메모리 버퍼캐시가 휘발성이여서 로그를 남기는데 로그도 버퍼를 사용한다면 영속성을 지킬 수 없지 않을까?"는 생각이 들 수 있습니다.

오라클에서는 DBWR(Dirty 블록 버퍼에서 데이터파일로 보냄)와 LGWR(로그 버퍼에서 파일로 보냄) 프로세스는 주기적으로 각각 Dirty 블록과 Redo 로그버퍼를 파일에 기록한다. 또한, LGWR 프로세스는 서버 프로세스가 커밋이 발생했다고 신호를 보낼 때도 활동을 시작합니다.

즉, 적어도 커밋시점에는 로그 버퍼 내용을 로그 파일에 기록한다는 뜻으로, 이를 Log Force at Commit이라고 합니다.

커밋 시점에 로그 파일이 디스크에 안전하게 기록했다면, 그 시점부터 트랜잭션의 영속성은 보장됩니다.

TMI
Commit은 로그가 디스크에 기록됬다는 신호를 받기 전까지 작업을 진행하지 않는 Sync방식이다. 그래서 Commit은 생각보다 느립니다.

크래시 복구

WAL, 데이터베이스 버퍼, 데이터베이스 파일 3가지를 연계하여 지속성을 담보하면서 현실적인 성능으로 DBMS가 동작하고 있습니다.

크래시(에러 상황)가 발생한 경우 어떻게 복구하는지 알아봅니다.

크래시가 발생하면 다음과 같은 상태가 됩니다.

WAL 마지막으로 커밋된 트랜잭션의 갱신 정보를 가집니다.
테이터베이스 버퍼 크래시로 내용이 전부 소실됩니다.
테이터베이스 파일(디스크) 최후 체크포인트 파일까지의 갱신 정보를 가집니다.

크래시 이후 DBMS(여기선 MySQL)는 3과 1의 체크포인트 이후 갱신 정보를 사용해 데이터베이스 파일을 크래시 시점의 커밋된 최신 상태로 수정합니다.

쉽게 설명하자면 3은 체크포인트 시점까지의 갱신 정보를 가지고 있고, 1은 커밋된 트랜잭션의 정보를 가지고 있습니다.
따라서 로그를 사용해 디스크에 수행되지(체크포인트 되지 않은) 않은 트랜잭션을 수행합니다.

이 동작을 '롤 포워드(Roll-Forwar)'라고 합니다.

하지만 이와 같은 구조도 논리적인 파괴(DDL 문에 의한 테이블의 파괴 등)나 물리적인 파손(디스크 장치의 고장 등)에는 대응할 수 없습니다.

그렇기에 정상적으로 동작하고 있을 때, 주기적으로 백업하여 이를 이용해 복원이나 복구하는 것이 좋습니다.

백업과 복구

PITR란?

데이터베이스를 백업하고, 장애가 발생하면 백업으로 복원한다. 하지만 단순이 백업 시점으로만 되돌릴 뿐 백업 후에 데이터베이스에서 수행한 갱신은 반영되지 않습니다.

일반적인 DBMS는 실행된 갱신을 기록한 로그를 보존해서 백업한 데이터베이스에 순차 반영해 백업 이후의 임의의 시점으로 복원할 수 있다.

이처럼 특정 시점에서 데이터 변경을 포함한 복원이나 복구를 PITR(Point-in-time Recovery = 특정 시점 복구)라고 부릅니다.

DBMS별 PITR

DBMS 마다 PITR에 이용되는 로그의 이름과 특성이 다릅니다.

DBMSOracleMySQLPostgreSQLDB2SQL Server

로그 이름	REDO 로그	바이너리 로그	WAL 로그	트랜잭션 로그	트랜잭션 로그
아카이브 지정	⭕	❌	⭕	⭕	⭕
아카이브 시 이름	ARCHIVELOG	❌	WAL 아카이브	아카이브 로깅	완전 복구 모델
비 아카이브 시 이름	NOARCHIVELOG	❌	(없음)	순환 로깅	완전 복구 모델

아카이브 지정이란?

PITR에 사용하는 로그는 대부분 WAL을 이용하는데, WAL을 크래시 복구에만 사용한다면 체크포인트 이전의 로그는 불필요하게 되어 해당 디스크 영역은 삭제하거나 재이용(덮어쓰기) 할 수 있습니다.

하지만 이렇게 된다면 PITR을 수행할 때 필요한 로그가 없는 사태가 발생하게 된다. 따라서 크래시 복구용으론 불필요한 로그도 PITR용으로 보존하기 위한 모드가 '아카이브 지정'입니다.

백업의 3가지 관점

핫 백업과 콜드 백업

핫 백업은 '온라인 백업'이라고도 하며 백업 대상의 데이터베이스를 정지하지 않고 가동한 채로 백업 데이터를 얻습니다.

'데이터베이스의 기능'으로 백업합니다.

콜 백업은 '오프라인 백업'이라고도 하며 백업 대상의 데이터베이스를 정지한 상태로 백업 데이터를 얻습니다.

'OS의 기능'으로 백업한다. 데이터베이스 정지 중에는 일반적으로 데이터 저장 파일을 OS로 다루는 상태가 되므로 이를 백업해 백업 데이터를 얻습니다.

논리 백업과 물리 백업

논리 백업은 SQL 기반의 텍스트 형식으로 백업 데이커가 기록되고, 물리 백업은 데이터 영역을 그대로 덤프(데이터 파일이나 화면에 출력)하는 이미지로 바이너리 형식으로 기록됩니다.

논리백업과 물리백업의 장단점

논리백업

장점

텍스트를 변경해 내용 일부를 수정할 수 있습니다.
이식성이 우수하다. (CSV 등은 변경없이) 동일한 DBMS의 다른 버전이나 다른 DBMS에 복원이 가능합니다.
단점
물리 백업보다 크기가 큽니다.
바이너리와 텍스트 상호교한에 들어가기 위한 백업과 복원의 동작 속도가 느립니다.

물리백업

장점

최소 크기로 데이터를 얻을 수 있습니다.
데이터 교환이 없거나 적어서 백업과 복원 속도가 빠릅니다.
단점
복원 단위는 도구에 따라 다르며 일부 데이터의 교환이나 적용 등이 불가능합니다.
플랫폼 의존 바이너리는 동일한 DBMS라도 호환하지 않습니다.

풀 백업과 부분 백업

풀 백업은 전체 백업이라고도 하며 데이터베이스 전체 데이터를 매일 백업하는 방식입니다.

부분 백업은 우선 풀 백업을 한 후에 이후 갱신된 데이터를 백업하는 방식입니다.

풀 백업과 부분 백업의 장단점

풀 백업

장점

백업 데이터가 한군데에 모여 있어서 복원 처리가 단순합니다.

단점

데이터베이스 전체를 백업하므로 백업에 걸리는 시간이 깁니다.
갱신량이 적어도 매번 데이터베이스 전체를 백업하므로 백업 데이터를 저장하는 데 충분한 용량이 필요합니다.

부분 백업

장점

갱신한 데이터만을 대상으로 하므로 백업에 필요한 시간이 짧고, 백업 데이터의 용량이 작아도 문제 없습니다.

단점

복원에는 풀백업과 부분백업이 필요해서 복원 절차가 복잡합니다.

증분 백업의 2가지 방법

차등 백업(Differential)은 풀 백업 이후 갱신된 데이터를 백업합니다.

증분 백업(Incremental)은 최근 백업(풀 백업에 한정되지 않음)한 이후에 갱신된 데이터를 백업한다. 증분 백업은 데이터의 양이 차등 백업보다 적지만 복원 시 모든 증분 백업을 차례로 적용해야 해서 절차가 복잡합니다.

롤 포워드 리커버리

앞서 소개한 롤 포워드와 비슷하게, 아카이브(MySQL에선 바이너리 로그)를 증분 백업으로 보존하고 이를 사용해 풀 백업 시점 이후 임의 시점까지 복원하는 것을 '롤 포워드 리커버리'라고 합니다.

현재의 데이터베이스 = 풀 백업한 데이터 + 풀 백업 후 얻은 모든 증분 백업

롤 포워드란?

WAL의 체크포인트 이후의 갱신정보를 사용해 크래시가 일어났던 시점까지 커밋된 최신 상태로 수정하는 동작을 의미합니다.

데이터베이스 관리 시 주의점

백업 파일들은 DB와 물리적으로 떨어진 곳에 각각 보관해야 안전합니다.
장애 대비 방법을 선택할 때 상황에 맞는 적절한 처리가 필요합니다.
- 24시간 가동해야하는 경우에는 핫백업이 필요합니다.
- VLDB(Very Large Data Base)를 운용한다면 느린 논리 백업 대신 물리 백업을 해야합니다.
- 갱신 범위가 매우 한정되어 있다면 차등 백업이 유효할 수 있습니다.
- 데이터베이스를 정지해도 되는 상황이라면 콜드백업을 수행합니다.

성능이란

데이터베이스를 다루다 보면 필연적으로 성능 문제가 발생한다. 따라서 가능한 초기부터 성능에 대한 지식을 가지고 있어야 합니다.

성능을 측정하는 2가지 지표

처리 시간 or 응답 시간

특정 처리의 시작부터 종료까지 걸린 시간을 나타냅니다.

이 일괄 처리에 1시간이 걸렸습니다.

처리율

특정 처리를 단위 시간에 몇 건 처리가 가능한지를 나타냅니다.

트랜잭션을 초당 50건 처리한다. = 50 TPS

중요한 점은 초, 분 같은 단위 시간의 지표가 없으면 '처리율'이 아닙니다.

150만 명이 이용하고 있다. ❌
연간 10만 명이 이용하고 있다. ⭕

정점과 한계점

처리율은 중요한 성장 지표로, 시스템의 자원용량을 결정합니다.

동시 실행 처리 수가 많아질수록 처리율이 떨어지며, 필요로 하는 자원 수도 증가합니다.

이 때 최초로 한계에 다다른 자원(시점?)을 버틀낵 포인트라고 합니다.

이처럼 처리율과 응답 시간이 극단적인 저하를 시작하는 시점을 한계점이라고 합니다.

이러한 정점을 생각해 자원을 확보하는 것을 '사이징' 혹은 '개퍼시티 플랜'이라고 합니다.

주기형과 돌발형

정점이 주기적으로 일어나는 경우(ex:대학 수강신청)에는 어느정도 대비가 쉽지만 돌발적으로 일어나면 예측과 대응이 어렵고, 정점이 아닐때 자원 낭비가 심합니다.

이런 돌발형을 대응하는 수단 중 하나로 Cloud Server가 뜨고 있습니다.

데이터베이스와 병목의 관계

데이터베이스에서 병목이 되는 이유

취급하는 데이터양이 가장 많습니다

요즘 '빅데이터' 같은 개념의 등장으로 데이터의 중요도가 증가하면서 데이터 보관 총량이 증가하는 추세입니다.

지원 증가를 통한 해결이 어렵습니다

데이터베이스의 병목 지점은 저장소이기 때문에 스케일 아웃이 어렵습니다.

Shared Nothing을 제외한 모든 방식이 스케일 아웃이 불가능합니다.

이런 제한 때문에 데이터베이스는 전통적으로 튜닝 기술이 발달했다. 튜닝은 애플리케이션을 효율화해 같은 양의 자원이라도 성능응 향상하게 하는 기술입니다.

성능을 결정하는 요인

DBMS 기능 중 쿼리 평가 엔진에 대해서 다루는데 "SQL 레벨업"의 1장 내용과 비슷하여 정리하지 않았습니다.

LIST

저작자표시

Auto-GPT스토리

[데이터베이스(Database, DB)란?] Database(DB), DBMS, SQL의 개념

IT관련 용어 정리 [데이터베이스] DataBase 란?

데이터베이스(DB:database) 의 역사

DBMS? 그건 뭐죠?

데이터베이스란?

DBMS란?

데이터베이스의 특징

SQL(Structured Query Language)

[데이터베이스 이해하기] Database(DB), DBMS, SQL의 개념

3줄 요약 KeyPoint

데이터베이스(Database, DB)란?

DBMS란?

DBMS의 종류

DBMS의 분류

계층형 DBMS

망형 DBMS

관계형 DBMS

SQL: DBMS에서 사용하는 언어

DB의 기본 기능

데이터베이스의 종류

우리는 왜 시스템에 돈을 내는가

아키텍쳐란

데이터베이스의 아키텍쳐 - 역사와 개요

데이터베이스의 아키텍쳐 - 가용성과 확장성

DB 서버의 다중화 - 클러스터링

DB 서버의 다중화 - 리플리케이션

100% 장애 대책은 없다.

관계형 데이터베이스의 계층

트랜잭션의 4가지 특성

다른 커넥션에선 어떻게 보일까

잠금 타임아웃과 교착 상태

해서는 안되는 트랜잭션 종류

백업과 복구

롤 포워드란?

성능이란

데이터베이스와 병목의 관계

티스토리툴바