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

데이터베이스 기술 동향

• 서비스를 시작하고 나서의 사양 변경은 수시로 일어나서는 안 되지만, 사양을 변경하고 싶을 때 데이터베이스 제품 구현 상 사정으로 인해 불가능하다 라는 사례는 제품인 이상 최대한 막아야 함

• 구현 전략
• 클라이언트 측의 처리가 일체 정지되는 일이 없이 서비스 도중에 정의를 바꿀 수 있다
• 본래 테이블 정의조차 하지 않고도 일정 이상의 품질로 동작하도록 하는.

온라인에서의 정의 변경

• MySQL 등의 여러 데이터베이스에서 테이블 정의를 변경하는 동안은 전체 테이블에 락을 걸고 업데이트를 일체 하지 못하게 됨. 테이블 크기가 크면 클수록 정의 변경에 시간이 걸려 갱신을 할 수 없는 시간도 길어짐

스키마 없는 데이터베이스

• 테이블 정의 변경이 빈번히 발생한다면 그냥 테이블 정의를 하지 않고도 운용할 수 있는 제품이 있으면 좋겠는데 라는 생각을 할 수도 있음

• MySQL같은 RDB에서 이것을 실행하려면 기본 키 또는 일부 인덱스와 같은 대표적인 데이터 항목을 밝혀낸 후 나머지를 TEXT의 형태로 정의하는 방법(혹은 JSON, XML)

• RDBMS에서는 놀라운 방식이지만 NoSQL이라면 선택의 여지가 없기 때문에 잘 사용됨

• 애플리케이션 측에서의 로직의 영향이 어느 정도 증가하게 됨

대량의 데이터를 고속으로 처리하는 기술

• 데이터베이스의 매력 중 가장 알기 쉬운 것은 대량의 데이터에서 원하는 항목을 빠르게 검색할 수 있는 것

• 그렇다고 해도 마법이 아니기에 그 고속성을 항상 발휘할 수 있는 것은 아님

인덱스 성능의 저하 요인

• 데이터베이스의 참조/ 갱신 성능을 생각하는 데 있어 가장 중요한 것은 인덱스

• 필요한 검색 조건에 맞는 인덱스가 있으면 테이블 전체를 읽지 않고 원하는 데이터를 몇 단계를 거쳐 취득할 수 있어 매우 빠르게 처리 가능

• 그러나, 다수의 인덱스를 준비하게 되면 업데이트 성능 저하라는 부작용이 발생함

• 데이터베이스에서 표준으로 사용 되고 있는 인덱스는 B+Tree(및 그 파생형)라는 트리형 구조. 참조 및 갱신 모두 O(logmN)으로 처리할 수 있으며, 매우 빠른 것이 특징임 B+Tree 인덱스의 약점은 모든 액세스가 랜덤 액세스라는 점

• 트래픽이 방대해지고 1회 처리에서 여러 서비스와 연계되거나 하면 서버 측에는 부담이 되는 처리가 상당히 많아짐. 또한 데이터베이스 측에서는 감사 및 고객 서비스와 같은 목적으로 데이터를 일정 기간 보관할 필요가 있음.

• 이와 같이 처리하는 데이터가 대량으로 되었을 경우, 데이터 조작처리(CRUD)가 느려지게 되면 성능 면에서 큰 리스크를 책임져야 하는데, DB측의 처리 로직은 아래와 같은 작업을 이용하는 방법이 있음
레인지 파티셔닝
• 인덱스의 성능이 떨어지는 가장 큰 요인은 인덱스 사이즈에 있음. 이 인덱스 크기를 줄일 수 있다면 성능 저하 없이 운용할 수 있다.
• 인덱스 사이즈를 컴팩트 하게 하는 유력한 방법 중 하나로 레인지 파티셔닝이 있음
• 특정 파티션에만 액세스를 집중시킬 수 있으면 전체 인덱스 크기보다도 압도적으로 액세스 범위가 좁아지므로 그 파티션은 메모리에 올릴 수 있어 액세스 성능을 향상시킬 수 있음
• 특정 파티션에만 액세스를 집중시키는 방법? → 거대한 데이터의 대부분은 시간적인 국소성이 매우 높다는 특징이 있음. 예로, 일기와 Twitter와 잡담이나 행동 로그의 경우, 데이터 양은 방대하게 되지만 사용자로부터 참조되는 데이터는 최근의 것에 한정됨
• 따라서 1주일, 1개월 단위로 파티션을 자르면 인덱스의 크기는 1주간, 1개월분에 한정되는 한편, 최신(현재 시간) 파티션에 액세스가 집중하기 때문에 그 파티션에 속하는 인덱스의 내용은 거의 확실하게 캐시됨. ⇒ 참조/갱신 성능도 저하를 억제할 수 있음
B+Tree 이외의 인덱스
• 메모리에 들어가지 못할 정도로 인덱스의 크기가 비대한 경우에 업데이트 성능이 저하되는 문제는 B+Tree 인덱스의 구조에 크게 기인함. 레인지 파티셔닝은 이 문제를 방지하는 현실적인 방법으로 잘 활용되는 중
• 그러나, 기술의 발전에 의해 레인지 파티셔닝 없이도 업데이트 성능을 일정 수준으로 유지하는 인덱스 기술도 등장하고 있음
• 예로, TokuDB라는 데이터베이스가 갖는 Fractal Tree 라는 인덱스에서는 보조 인덱스의 크기가 아무리 커져도 INSERT의 성능이 항상 일정한 라인으로 빠른 속도를 낼 수 있다는 성질을 가지고 있음
• 이 때문에 기존대로라면 메모리 크기를 웃도는 상황에서 단번에 성능이 침체 되었던 부분이 성능의 저하를 막을 수 있게 되었다는 장점이 있음
• 고속의 하드웨어 ( 빠른 SSD를 사용, SSD의 대두로 느린 랜덤 액세스의 성능은 옛날만큼 심각한 문제는 아니게 됨)
트랜잭션
정합성이 있는 복제 실현
• 트랜잭션을 지원하지 않으면 오류가 발생했을 때 일관성이 보장되지 않는다는 큰 문제가 있음
• 예를 들어 슬레이브가 다운되었을 때, 슬레이브는 어디까지 업데이트를 완료하고 어디에서 복제를 다시 시작하면 좋은가 라는 정보를 필요로 함
• 그러나 트랜잭션을 지원하지 않으면 이 정보가 맞다는 보장이 전혀 없음 ⇒ 데이터를 처음부터 다시 작성해야 함(매우 시간이 걸리는 작업)
일관성이 있는 백업 보장
• 일관성 있는 백업을 온라인에서(갱신을 멈추지 않고) 하려면 트랜잭션 메커니즘이 필요함
• 복제가 있으면 백업은 필요 없다 라고 생각하고 있다면 당장 생각을 바꿔야 함
• 오퍼레이션 실수와 잘못된 업데이트 등을 마스터에서 실시하면 슬레이브 에서는 그것이 즉시 복제되어 올바른 결과를 가진 서버는 어디에도 없게 된다. ⇒ 정기적인 백업이 중요
• 트랜잭션 메커니즘을 제공하지 않을 때는 데이터 불일치가 당연히 발생할 거라는 각오 쯤은 해둬야 함

샤딩과 파티셔닝

• 샤딩은 하나의 데이터를 여러 서버에서 나누어서 가져가는 것 → 쓰기 작업 자체를 나누어서 진행.

• 파티셔닝은 하나의 서버에서 데이터를 나누어서 관리하여, 특정 부분의 데이터에 액세스를 집중하도록 하는 것

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

NoSQL 데이터베이스

그 외의 주제(Write Once, Write Scaling)