데이터 모델링: 수동 보조 인덱스

우리는 종종 Couchbase Server를 문서 데이터베이스라고 설명합니다. 이는 좋은 설명입니다: 카우치베이스는 JSON 문서 저장소로서 탁월한 성능을 발휘합니다.

하지만 Couchbase Server용 데이터를 모델링할 때는 키-값 저장소처럼 생각하면 도움이 될 수 있습니다.

핵심 가치 사고와 문서 사고

그렇다면 키-값 저장소와 문서 저장소의 실질적인 차이점은 무엇일까요? 대부분 데이터를 쿼리하는 방식에 관한 것입니다.

키-값 데이터베이스는 데이터를 불투명한 단위로 저장하는 경향이 있어 하나의 인덱스, 즉 키 자체를 제공합니다. 키만 사용하여 데이터를 눈에 띄지 않는 덩어리로 저장하고 검색할 수 있습니다. 이는 복잡하지 않기 때문에 일반적으로 빠르지만 매우 무딘 도구이기도 합니다.

반면에 문서 저장소는 문서 내부의 데이터에 대한 추가 인덱스를 제공하므로 데이터를 쿼리하는 방법이 훨씬 더 자유롭습니다. 물론 모든 데이터베이스 시스템에서의 쿼리에는 리소스 비용이 발생합니다.

데이터 모델을 설계할 때는 어떤 접근 방식을 취할지 선택해야 합니다. 그러기 위해서는 장단점을 이해해야 합니다.

장단점

Couchbase는 데이터에 대한 키 값 액세스 및 문서 쿼리 스타일의 액세스를 제공합니다.

두 가지 접근 방식 모두 장점과 단점이 있습니다:

현재 및 곧 Couchbase 보기로 N1QL에서 쿼리하면 엄청난 유연성을 얻을 수 있습니다. N1QL이 일반적으로 사용 가능하고 이를 지원하는 인덱싱이 제공되면 아마도 이 블로그의 많은 부분이 쓸모없어질 것입니다.

하지만 지금은 쿼리 유연성을 크게 포기하지 않고도 즉각적인 일관성, 캐시된 밀리초 미만의 응답 시간, 선형 확장 프로필 등 Couchbase의 키-값 모델의 모든 이점을 유지할 수 있습니다. 이를 위한 방법은 수동 보조 인덱스를 만드는 것입니다.

조회에 관한 모든 것

사용자 프로필을 Couchbase에 저장한다고 가정해 보겠습니다. 가장 먼저 선택해야 할 것은 프로필을 어떻게 키화할 것인지입니다.

사용자가 이메일 주소를 사용하여 시스템에 로그인한다고 가정해 보겠습니다. 즉, 사용자가 로그인하면 최소한 그 사용자에 대한 한 가지 정보는 알 수 있습니다. 이메일 주소로 사용자 프로필을 키로 지정하면 다음과 같은 로그인 프로세스가 이루어집니다:

1. 사용자가 로그인 양식에 이메일 주소(예: lily@example.com)와 비밀번호를 입력합니다.
2. 키가 있는 문서를 Couchbase에서 가져옵니다. lily@couchbase.com
3. 사용자 프로필의 해시와 비교하여 비밀번호를 확인합니다.
4. 성공하면 로그인이 완료되고 릴리는 업무를 처리합니다.

좋아요, 쉬웠어요.

얼마 후 릴리가 이메일 주소를 변경하고 시스템에서 이를 업데이트하려고 합니다. 당연히 릴리는 업데이트된 이메일 주소를 사용하여 로그인하고 싶을 것입니다.

이를 처리하는 방법에는 세 가지 옵션이 있습니다:

• 새 이메일 주소로 키가 지정된 완전히 새로운 사용자 프로필 문서를 만들고 이전 이메일 주소는 삭제합니다.
• 리디렉션 문서 만들기
• 처음부터 조회 문서를 사용하여 수동 보조 색인을 생성하세요.

첫 번째 옵션은 조금 우아하지 않은 것 같습니다. 예를 들어 시스템의 다른 곳에서 문서를 참조하고 있었다면 이제 이러한 참조는 막다른 골목이 될 것입니다.

리디렉션

대신 두 번째 옵션을 사용하여 새 이메일 주소로 키가 지정된 새 문서를 만들 수 있습니다. 문서 내용은 단순히 이전 이메일 주소가 됩니다. 물론 새 이메일 주소를 사용자 프로필 문서 자체에 배치해야 해당 이메일 주소를 이 사용자와 연결하기 위해 조회 문서가 필요하지 않습니다.

이제 로그인 프로세스는 다음과 같습니다:

1. 사용자가 로그인 양식에 이메일 주소(예: lily@newdomain.com)와 비밀번호를 입력합니다.
2. 키가 있는 문서를 Couchbase에서 가져옵니다. lily@newdomain.com.
3. 문서가 전체 사용자 프로필이 아닌 다른 이메일 주소(lily@example.com)임을 알 수 있습니다.
4. lily@example.com 문서를 가져옵니다.
5. 사용자 프로필의 해시와 비교하여 비밀번호를 확인합니다.
6. 성공하면 로그인이 완료되고 릴리는 업무를 처리합니다.

이것은 작동할 수 있습니다. 하지만 이메일 주소에서 GET을 수행할 때 어떤 내용을 받게 될지 알 수 없다는 점이 약간 복잡해집니다.

대신 처음부터 조회 문서를 사용하여 시작할 수 있습니다.

수동 보조 색인 사용

사용자 중 일부는 계정 사용 기간 동안 이메일 주소를 변경할 가능성이 매우 높습니다. 따라서 처음부터 이러한 가능성을 염두에 두는 것이 합리적입니다.

사용자의 프로필 문서에 이메일 주소로 키를 설정하는 대신 변하지 않는 다른 고유한 것으로 키를 설정해야 합니다. 변하지 않는 무언가를 찾고 있으므로 키 자체는 사용자 자신에 대한 어떤 것과도 관련이 없어야 합니다. 카우치베이스 서버는 이를 처리할 수 있는 쉬운 방법인 원자 카운터를 제공합니다.

원자 카운터를 증분 또는 감소와 양을 더하여 호출한 다음 결과 숫자를 반환할 수 있습니다. 새 사용자 프로필을 만들 때마다 카운터를 하나씩 증가시키면 고유하고 변하지 않는 키가 생성됩니다.

작동 방식을 살펴보겠습니다:

1. 사용자가 가입 절차를 완료합니다.
2. 카운터를 늘리면 1001이 반환됩니다.
3. 키 1001을 사용하여 사용자 프로필 문서를 만듭니다.

이제 사용자 프로필의 변경 사항이 키에 영향을 미치지 않습니다. 하지만 사용자가 1001과 같은 숫자 사용자 아이디를 외우게 하고 싶지 않다면 친숙한 사용자 아이디를 사용자 프로필과 일치시키는 다른 방법을 찾아야 합니다.

이것이 바로 수동 보조 색인이 필요한 이유입니다. 가입 절차에 한 단계를 더 추가해 보겠습니다:

4. 사용자의 이메일 주소에 키가 1001인 조회 문서를 생성합니다.

이제 로그인 프로세스는 다음과 같습니다:

1. 사용자가 로그인 양식에 이메일 주소(예: lily@newdomain.com)와 비밀번호를 입력합니다.
2. 키가 있는 문서를 Couchbase에서 가져옵니다. lily@newdomain.com.
3. 해당 문서의 값이 1001이므로 키가 1001인 사용자 프로필 문서를 GET합니다.
4. 사용자 프로필의 해시와 비교하여 비밀번호를 확인합니다.
5. 성공하면 로그인이 완료되고 릴리는 업무를 처리합니다.

대부분의 데이터베이스 시스템에서는 허용할 수 없는 지연이 발생할 수 있지만, Couchbase에서는 추가 조회가 밀리초 미만이어야 합니다. 따라서 도입할 수 있는 다른 수동 인덱스의 범위가 넓어집니다: 트위터 핸들, 전화번호, 도시 등 다양한 수동 인덱스를 도입할 수 있습니다.

물론 애플리케이션 계층에서 조금 더 많은 작업이 필요하지만, 그 대신 애초에 Couchbase Server를 선택하게 된 모든 속도와 확장성을 유지하면서 보조 인덱스의 유연성을 확보할 수 있습니다.

다음 시간에는 키 이름 지정에 대해 살펴보겠습니다.