데이터베이스를 지탱하는 기술3(11장~12장)

데이터베이스 기술의 현재와 미래

데이터 모델링 : 서비스 중에서 어떤 데이터 항목을 취급할지를 정리하고 그것을 테이블 관계에 반영하는 것

데이터베이스 제품 측에서의 구현 전략은 '클라이언트 측의 처리가 일체 정지되는 일이 없이 서비스 도중에 정의를 바꿀 수 있다' 라는 방향성과 '본래 테이블 정의조차 하지 않고도 일정 이상의 품질로 동작하도록 하는' 방향성을 지닌 제품이 등장하고 있다.

 

온라인 상태에서의 정의 변경을 제품에서의 기능으로서 갖추지 못한 현재의 mysql에서는 이것을 어떻게든 처리하기 위한 눈물겨운 노력을 하고 있다.

1. 트리거를 사용하여 변경 내용을 기록하고 나중에 한꺼번에 반영

이 구조를 제대로 작동시키기 위해서는 '잠금을 걸지 않고 SELECT한다' 와 '시작 시점에서 커밋된 데이터를 읽는다(읽는 동안 테이블의 내용이 갱신되어도 시작 시점에서 커밋된 데이터를 읽어들인다' 라는 두 가지 기능 중요(트랜잭션 기반)

2. 복제 구성 활용

마스터 한대, 슬레이브 두 대의 구성이라면 슬레이브에서 먼저 정의 변경. 정의 변경을 하는 동안 갱신이 멈춰 버리기 때문에 애플리케이션에서는 정의 변경을 하지 않은 쪽의 슬레이브로 참조를 향하게 한다. 이것을 양쪽의 슬레이브에서 각각 시행한다. 다음은 현재 마스터를 두 대의 슬레이브 중 하나로 전환하여 현재 마스터를 슬레이브로 교체한다. 그리고 그 새로운 슬레이브에서도 정의 변경을 한다. 이렇게 순차적으로 정의 변경해 나감으로써 정지 상태를 최대한 줄일 수 있다.

 

스키마 없는 데이터베이스

MYSQL 같은 RDBMS에서 기본 키 또는 일부 인덱스와 같은 대표적인 데이터 항목을 밝혀낸 후 나머지를 misc TEXT 등의 형태로 큰 문자열로 정의하는 수가 있다. 이 중에는 JSON, XML, 압축한 데이터를 밀어 넣을 수 있다.

 

인덱스 성능의 저하 요인

B+Tree 인덱스의 약점은 모든 액세스가 랜덤 액세스라는 점이다. HDD는 랜덤 액세스가 매우 느리다. 인덱스가 메모리에 들어가 있는 상태이면 참조/ 갱신의 성능이 모두 매우 빠르지만, 일단 메모리에 들어가지 못한 경우는 HDD에 대한 랜덤 액세스가 발생되기 때문에 성능은 크게 악화된다. 이러한 경우 데이터베이스에서는 레인지 파티셔닝, B+Tree 이외의 인덱스, 고속의 하드웨어, 트랜잭션을 이용해야 한다.

 

레인지 파티셔닝

인덱스의 성능이 떨어지는 가장 큰 요인은 인덱스 사이즈에 있다. 인덱스 사이즈를 컴팩트하게 하는 유력한 방법 중 하나로 레인지 파티셔닝이 있다. 이 기능은 테이블 및 인덱스를 물리적으로 한 개로 정리해서 관리하는 것이 아니라 내부적으로 복수로 분할하여 관리하는 방식이다. 특정 파티션에만 액세스를 집중시킬 수 있으면 전체 인덱스 크기보다도 압도적으로 액세스 범위가 좁아지므로 그 파티션은 메모리에 올릴 수 있어 액세스 성능을 향상시킬 수 있다.

 

B+Tree 이외의 인덱스

레인지 파티셔닝의 메커니즘 없이 업데이트 성능을 일정 수준으로 유지하는 인덱스 기술도 등장하고 있다. ex) TokuDB라는 데이터베ㅐ이스가 갖는 Fractal Tree라는 인덱스에서는 보조 인덱스의 크기가 아무리 커져도 INSERT의 성능이 항상 일정한 라인으로 빠른 속도를 낼 수 있다는 성질을 가지고 있다.

 

* 트리거(Trigger)는 특정 테이블에 INSERT, DELETE, UPDATE 같은 DML 문이 수행되었을 때, 데이터베이스에서 자동으로 동작하도록 작성된 프로그램입니다. 즉! 사용자가 직접 호출하는 것이 아니라, 데이터베이스에서 자동적으로 호출하는 것이 가장 큰 특징입니다. 

 

분석계 처리 및 열 지향 데이터베이스

DWH(데이터웨어하우스)가 성능 문제를 일으키기 쉬운 이유는 데이터양과 레코드 수가 많아지는 것이다.

DWH의 큰 특징 : 테이블 정의상에 많은 열을 가지고 있는 반면, SQL 문에서는 그 중 극히 일부 열만을 사용

기존의 데이터베이스에서의 처리 단위는 레코드다. 열 1~10까지의 경우는 한 개 레코드 내의 각 열의 값이 물리적으로 인접하게 된다. 웹 어플리케이션과 같이 기본 키 겁색으로 1레코드만 처리하도록 하지 않기 때문에 낭비

인덱스 설계가 매우 어렵다.

 

열 지향 데이터 베이스

기존의 데이터베이스가 행(레코드)을 처리 단위로 하고 있는 반면, 열 지향 데이터베이스에서는 열(칼럼)을 처리 단위로 한다.

장점

필요한 열만 액세스되기 때문에 I/O 효율이 높다.

압축 효율이 좋다.

로드 처리가 고속이다.(B+트리는 열 값을 정렬이 끝난 상태로 유지할 필요가 있다)

단점

기본 키 검색 등 좁은 범위의 처리가 느리다.

제품으로서의 성숙도가 낮다.

 

NOSQL

사용자 id로의 기본 키 검색 같은 간단한 처리는 mysql에서 초당 10만 쿼리를 판정할 수 있다. 그런데 NOSQL에서 실행하면 초당 30만 쿼리 이상 처리량을 내는 것이 가능하다. 이런 단순한 작업을 보고 SQL문과 같은 복잡한 언어를 사용하지 않고 프로그래밍 언어와 라이브러리 함수를 사용하여 직접 데이터를 액세스하는 편이 훨씬 고속으로 되는 것은 아닌가 하는 생각에 NOSQL이 주목을 끌게 되었다. 또한 분산 데이터베이스로서의 용도도 한다. 

NOSQL은 테이블을 연 채로 둔다. 그 결과 경합이 크게 줄고 성능이 향상된다.

 

단점

메모리 안에서의 기본 키 검색이 압도적으로 빠르다. 하지만 NOSQL은 일부 용도에 있어 우수한 성능을 내기 위해 최적화한 것이라는 특성을 갖고있다. 트랜잭션, 스키마가 없고 기본 키 이외의 인덱스를 사용할 수 없다.

 

캐시, 세션 데이터로 많이 쓰인다.

 

RDBMS와 NOSQL의 하이브리드 구성을 하기도 한다. 어떤 때에는 데이터베이스를 RDBMS로 사용하고 어떤 때에는 NOSQL로 사용한다라는 대표적인 제품이 MYSQL CLUSTER(NDB)이다.