관계형 데이터베이스

데이터를 파일에 적어 관리하던 시절에는 같은 사실이 여러 곳에 적혔습니다. 주문 기록 파일의 줄마다 회사 이름과 주소를 함께 적어 두는 식입니다. 그 회사의 주문이 8,000건이 되면 같은 사실이 8,000벌 존재합니다.

문제는 그 사실이 바뀔 때 드러났습니다. 회사가 이름을 바꾸면 8,000줄을 다 고쳐야 하는데, 실제로는 일부만 고쳐집니다. 그러면 같은 회사가 두 이름으로 존재하고, 청구서에는 옛 이름이 찍혀 나갑니다.

프로그램 쪽 부담도 있었습니다. 파일을 어떤 순서로 읽고 어디서 끊어 해석할지가 프로그램마다 따로 적혀 있어, 파일 형식을 바꾸면 그것을 읽는 프로그램 일곱 개를 함께 고쳐야 했습니다.

1970년에 제안된 관계 모형이 이 두 문제를 함께 다뤘습니다. 데이터를 표에 담고, 사실은 한 표에만 적고 나머지 표는 그 표의 행을 가리키는 값만 갖게 하는 방식입니다. 회사 이름은 회사 표에 한 번만 있고 주문 표에는 회사 번호만 들어갑니다. 읽는 방법도 표준 언어 하나로 통일해, 프로그램이 파일 구조를 알 필요가 없어졌습니다.

같은 사실이 여러 곳에 적히는 것을 막고, 데이터가 어중간한 상태로 남지 않도록 지켜 줍니다.

1. 중복을 없앱니다. 회사 이름을 회사 표에 한 번만 두고 주문 표는 번호로 가리키면, 이름이 바뀔 때 고칠 곳이 한 줄입니다. 이렇게 표를 쪼개는 설계를 정규화라 부릅니다.
2. 어긋난 값이 들어오지 못하게 막습니다. 주문 표의 회사 번호 칸을 회사 표에 걸어 두면 존재하지 않는 회사의 주문이 만들어지지 않습니다. 칸마다 들어갈 수 있는 종류도 미리 정해 두어 가입일 칸에 엉뚱한 글자가 섞이지 않습니다.
3. 절반만 반영되는 사고를 막습니다. 잔액을 깎고 주문을 만드는 두 동작을 하나로 묶어 두면, 중간에 실패했을 때 둘 다 없던 일이 됩니다. 이 묶음을 트랜잭션이라 부르고, 지켜야 할 네 성질에는 ACID라는 이름이 붙어 있습니다.
4. 무엇을 원하는지만 적으면 찾는 방법은 데이터베이스가 고릅니다. 지난달에 가입한 회원 중 결제가 없는 사람을 뽑아 달라고 SQL로 적으면, 어느 표를 먼저 읽고 어떤 순서로 맞출지는 데이터베이스가 정합니다. 그래서 데이터가 백 배로 늘어도 같은 문장을 그대로 씁니다.
5. 같은 데이터에서 속도를 뽑아냅니다. 자주 찾는 칸에 인덱스를 걸어 두면 백만 줄을 훑던 질의가 몇 줄만 읽고 끝납니다. 책 뒤의 찾아보기와 같은 장치입니다.

표 구조를 미리 정해 두는 것이 부담이 되는 자리에서는 다른 계열을 고릅니다. 갈리는 기준은 데이터를 어떤 모양으로 담느냐입니다.

1. NoSQL은 표 모양을 미리 정하지 않아도 되는 계열입니다. 기록마다 들어 있는 항목이 달라도 되고 항목을 더할 때 구조를 고치지 않습니다. 형태가 자주 바뀌는 데이터나 초기 단계에 유리합니다. 대신 기록끼리 이어 주는 일을 프로그램이 직접 합니다.
2. 키-값 저장소는 열쇠 하나에 값 하나를 매달아 두고 열쇠로만 꺼냅니다. 구조가 단순한 만큼 빠르고, 로그인 상태나 자주 쓰는 계산 결과를 잠깐 얹어 두는 자리에 씁니다.
3. 벡터 데이터베이스는 문장의 뜻을 숫자 목록으로 바꿔 저장하고 글자가 아니라 의미가 가까운 것을 찾아 줍니다. 환불 어떻게 하나요와 돈 돌려받고 싶어요를 같은 질문으로 묶는 검색이 여기서 나옵니다.
4. 데이터 웨어하우스는 분석용으로 따로 모아 둔 저장소입니다. 서비스가 쓰는 데이터베이스에 큰 집계 질의를 돌리면 사용자 화면이 함께 느려지므로, 분석할 데이터를 복사해 옮겨 두고 거기서 돌립니다.

넷 가운데 하나를 고르는 것이 아니라 함께 쓰는 쪽이 보통입니다. 회원과 주문 같은 핵심 데이터는 관계형에 두고, 로그인 상태는 키-값 저장소에, 분석은 웨어하우스에 맡기는 구성이 흔합니다.

"이건 관계형으로 갑시다. 회원과 결제가 어긋나면 안 되는 데이터예요."

절반만 반영되는 사고를 막아야 하는 데이터라는 판단입니다.

"표를 쪼개 두면 회사 이름 바뀔 때 한 줄만 고치면 됩니다."

중복을 없애는 설계를 제안하는 말입니다.

"이 질의가 3초 걸려요. 인덱스를 걸어야 할 것 같습니다."

같은 데이터에서 속도를 끌어내야 한다는 뜻입니다.

페이지덱에서는 태오가 회원과 팀과 문서 권한을 관계형에 두었습니다. 문서 하나에 권한이 여럿 붙고 누구에게 준 것인지가 정확해야 하는데, 표끼리 걸어 두면 없는 계정에 권한이 생기는 일을 데이터베이스가 막습니다.

문서 본문은 다른 저장소에 둡니다. 편집 기록이 계속 쌓이고 모양도 문서마다 달라 표에 맞추기가 어색하기 때문입니다. 지현이 주간 사용량을 보는 화면은 웨어하우스에 복사된 데이터로 그립니다. 예전에 서비스 데이터베이스에서 바로 집계를 돌렸다가 월요일 오전 문서 목록이 느려진 일이 있었습니다.

SQL과 관계형 데이터베이스를 같은 것으로 보는 경우가 가장 많습니다. 늘 붙어 나오는 말이라 자연스러운 오해입니다. 하지만 하나는 데이터를 담는 방식이고 하나는 그 데이터에 말을 거는 언어입니다. 관계형 제품은 여럿이고 각자 문법이 조금씩 다르며, 표 구조를 쓰지 않는 제품도 SQL과 비슷한 언어를 제공합니다. 둘을 하나로 묶어 두면 저장 방식을 고르는 회의에서 언어 이야기만 하다 끝납니다.

NoSQL이 더 새로우니 그쪽이 낫다고 보는 것도 흔합니다. 이름이 관계형 다음에 나온 것처럼 들리고, 속도가 빠르다는 이야기가 함께 붙어 다닙니다. 다만 그 빠름은 대개 지켜 주던 것을 덜 지키는 대가입니다. 칸의 종류를 미리 정하지 않으면 반년 뒤에 같은 항목이 세 가지 이름으로 저장돼 있고, 표끼리 걸어 두지 않으면 없는 계정에 붙은 권한을 프로그램이 스스로 걸러야 합니다. 새것과 낡은 것의 문제가 아니라 무엇을 데이터베이스에 맡기고 무엇을 프로그램이 질지 정하는 문제입니다.