Couchbase에서 데이터를 가져오고 내보내는 방법에는 여러 가지가 있습니다. 쿼리라고 하지 않고 일부러 들락날락이라고 한 것을 주목하세요. Couchbase에서 데이터를 입출력하는 모든 방법이 다른 데이터베이스에서처럼 쿼리하는 것은 아닙니다. Couchbase는 다양한 기능/기능 및 성능 특성을 제공하는 여러 가지 방법을 제공하며, 애플리케이션 요구 사항을 충족하기 위해 혼합하여 사용할 수 있습니다. 다양한 Couchbase 데이터 액세스 패턴을 나열한 다음 각 패턴의 실제 적용에 대해 자세히 살펴보겠습니다.
- 개체 ID(키)로 데이터 읽기/쓰기
- 뷰에서 데이터 읽기
- N1QL을 사용하여 데이터 읽기/쓰기/업데이트하기
- Solr 또는 Elastic을 통한 전체 텍스트 검색
각 방법의 사용 시기 및 장소
4.0 버전에 N1QL("니켈"로 발음)과 쿼리 및 인덱스 서비스가 도입되면서 Couchbase는 새로운 수준의 기능을 갖추게 되었습니다. N1QL은 거의 완벽한 SQL ANSI-92 준수를 제공합니다. (거의라고 표현한 이유는 N1QL이 관계형 데이터베이스에서는 유용하지만 문서 데이터베이스에서는 유용하지 않은 기능을 제외하기 때문입니다. 반대로, 문서 데이터베이스에는 필요하지만 관계형 데이터베이스에는 적합하지 않은 기능도 있습니다. 다시 말해, SQL ANSI-92의 하위 집합인 동시에 상위 집합입니다). 하지만 분명히 말씀드리자면, N1QL은 NOT 의도된 그리고 그래야만 하는 NOT 는 4.0 이전 버전의 카우치베이스가 가지고 있던 다른 데이터 읽기 및 쓰기 수단을 대체합니다. 단순히 데이터에 접근할 수 있는 또 다른 방법을 제공할 뿐입니다.
N1QL이 도입되면서 대부분의 사람들이 이 두 도구를 사용하던 전체 쿼리를 Couchbase가 지원하게 되면서 Solr과 Elastic의 필요성이 줄어들었습니다. 애플리케이션에 전체 텍스트 검색이 필요한 경우에는 여전히 필요합니다. 두 플랫폼 모두 이 기능을 제공하기 위해 Couchbase와의 뛰어난 통합 기능을 갖추고 있습니다.
데이터에 액세스하는 네 가지 수단은 각각 도구 상자의 도구이며 각기 다른 용도로 사용됩니다. 각 도구는 해당 사용 사례의 기능 및 성능 요구 사항에 따라 사용해야 합니다. 이러한 도구는 양자택일의 상황이 아니라는 점을 기억하세요. 이러한 도구를 적절히 혼합하여 사용할 수 있습니다. 예를 들어, 개체 ID를 내보내는 뷰를 쿼리한 다음 해당 ID를 병렬화된 BulkGet과 함께 Couchbase SDK를 사용하여 모든 개체를 읽거나 모든 개체에서 단순히 생성/읽기/업데이트/삭제(CRUD)를 수행하면 매우 빠르게 처리할 수 있습니다. 따라서 이러한 도구를 함께 사용하면 누구나 쉽고 유연하게 Couchbase에서 데이터를 가져오고 내보내는 데 사용할 수 있는 표준적이고 확장 가능한 방법을 제공합니다.
자세한 내용을 살펴보겠습니다...
개체 ID(키)로 데이터 읽기/쓰기
Couchbase의 핵심은 놀라운 키/값 데이터베이스이며 항상 그래왔습니다. 객체 ID를 통한 액세스는 사람들이 빠르게 이해하고 현명하게 사용하기 가장 어려운 개념 중 하나이기도 합니다(따라서 이 섹션의 길이가 길어졌습니다). 일단 이 기능을 이해하고 나면, 이 도구가 무엇을 제공하고 이 도구를 어떻게 적용할 수 있는지 알게 됩니다. 객체 ID를 통한 액세스는 구석에 숨어 있는 강력한 짐승으로 오해받고 있습니다. 이제 이 야수를 더 잘 이해하고 이를 어떻게 활용할 수 있는지 알아봅시다.
시작하기 전에 분명히 말씀드리자면, 개체 ID(키)를 통한 데이터 액세스는 다음과 같습니다. 항상 쿼리하는 것보다 더 빠릅니다. 데이터를 얻기 위해 답을 알고 있는 것과 데이터를 찾기 위해 질문(쿼리)을 해야 하는 것의 차이입니다. 도서관에 들어가서 특정 책이 필요하다고 가정해 봅시다. 책의 ID를 알고 있다면 1층 3열 4번 서가 오른쪽에서 세 번째 책으로 가면 됩니다. 그곳에 가서 책을 집어 들고 계산하고 나가면 됩니다. 책의 ID를 모른다면 사서나 컴퓨터에게 물어보고 가지고 있는 정보(저자, 제목 등)를 알려주면 책을 찾을 수 있는 위치로 안내해 주거나, 더 심하면 모든 책을 일일이 살펴보고 결국 책을 찾을 수 있습니다. 개체 ID만 알고 있으면 데이터를 인덱싱하여 조회할 필요 없이 Couchbase 관리형 캐시에서 필요한 데이터를 바로 가져올 수 있습니다. 액세스 시간이 매우 일정하고 지연 시간이 매우 짧아 매우 빠릅니다. 따라서 다른 액세스 방법과 성능을 비교하지 마세요. 각기 다른 기능적 요구 사항을 충족하기 위한 것이기 때문입니다.
이제 키/값 액세스에 대해 "어, 쿼리가 필요해요!"라고 말할 수 있습니다. 그럴 수도 있고 아닐 수도 있습니다. Couchbase에서 객체 ID로 데이터에 액세스하는 것은 매우 강력할 수 있는데, 객체 ID는 최대 250바이트까지 가능하며 객체 ID를 사용하는 방법에 따라 쿼리를 피할 수 있기 때문입니다. 개체 ID로 할 수 있는 작업의 진정한 힘은 각 개체 ID에 대해 표준화된 패턴을 사용하여 애플리케이션이 필요할 때 필요한 정확한 데이터를 추적할 수 있도록 구성할 때 발휘됩니다. 객체 ID를 전체 객체 모델링의 확장으로 생각하면 됩니다. 이 모든 것을 Couchbase의 아키텍처와 결합하면 애플리케이션이 내장된 관리형 캐시에서 필요한 데이터를 최대한 빠르게 가져올 수 있습니다. 하지만 한 가지 주의할 점이 있습니다. 기본적으로 Couchbase는 성능상의 이유로 각 객체에 대한 모든 객체 ID를 관리형 캐시에 저장합니다. 따라서 큰 키를 무리하게 사용하지 마세요. 예를 들어 2억 5천만 개의 개체에 250바이트의 데이터를 곱한 경우 클러스터 전체에서 키에만 약 58GB의 RAM이 필요합니다. 따라서 250바이트 키를 사용할 수 있다고 해서 반드시 사용해야 한다는 의미는 아닙니다. 심각한 규모에서는 문제가 될 수 있으므로 100바이트 이하로 유지하는 것이 좋습니다.
캐싱과 지속성 계층이 결합된 Couchbase의 아키텍처는 다른 데이터베이스, 특히 관계형 데이터베이스에 치명적일 수 있는 데이터 액세스 패턴에 탁월합니다. 관리되는 캐시에서 바로 여러 개체를 읽는 속도가 기존 데이터베이스보다 훨씬 빠릅니다. 그리고 다른 데이터베이스에서는 데이터베이스에 대한 왕복 횟수를 제한해야 합니다. Couchbase를 사용하면 문서를 읽고, 그 문서에서 데이터를 가져온 다음, 이를 기반으로 더 많은 개체를 읽을 수 있으며, 다른 데이터베이스가 한 번의 쿼리를 수행하고 결과를 반환하는 데 걸리는 전체 시간보다 동일하거나 더 짧은 시간 안에 가능합니다. 카우치베이스로 여러 번 이동하는 것에 대한 페널티가 현저히 낮으며 오히려 권장됩니다.
표준화된 개체 ID 패턴의 의미에 대해 몇 가지 예를 들어보겠습니다:
login-info::hernandez94
이 개체는 고유한 사용자 이름 hernandez94에 대한 로그인 정보를 사용자 프로필 저장소. 따라서 이 사용자를 인증해야 할 때는 로그인 정보만 포함된 이 JSON 문서만 가져오면 됩니다.
보안 질문::헤르난데즈94
동일한 사용자 프로필 저장소 예시에서 이 객체는 해당 사용자의 세 가지 보안 질문이 담긴 JSON 문서를 저장합니다. 사용자가 비밀번호를 잊어버렸을 때 앱은 이 오브젝트를 가져오기만 하면 됩니다. 또 다른 좋은 점은 보안 질문은 자주 액세스하지 않기 때문에 자주 사용되는 개체의 관리 캐시에서 제외될 수 있지만 괜찮다는 것입니다.
이와 같은 표준 개체 ID 패턴을 사용하면 애플리케이션에서 사용 가능한 정보로 이러한 개체를 생성한 다음 Couchbase에서 직접 이러한 개체와 상호 작용할 수 있음을 알 수 있습니다. 전체 데이터베이스 쿼리가 필요하지 않습니다. 객체 모델링 전략에 대해 더 자세히 알아볼 수 있지만 이는 이 글의 범위를 벗어납니다. 이에 대한 자세한 내용은 "성능 지향 아키텍처" 크리스 앤더슨의 글입니다.
애플리케이션에서 표준화된 개체 ID 패턴을 사용하는 방법에 대한 보다 구체적인 예는 다음을 참조하세요. 이 그리고 이 블로그 게시물을 참조하세요. 블로그의 특정 사용 사례가 귀하의 사용 사례에 적용되지 않더라도 개체 ID 패턴의 사용과 자신의 사용 사례에 적용하는 방법을 더 잘 이해하는 데 도움이 될 수 있습니다.
장점:
- 매우 빠르게 액세스할 수 있으며 클러스터의 크기가 올바르게 설정되어 있다면 개체는 이미 Couchbase 관리형 캐시에 있습니다.
- 개체 ID를 통한 데이터 검색의 유연성
- 데이터는 일관성이 강합니다. 즉, 항상 자신이 쓴 내용을 읽습니다.
- 노드 간에 데이터를 균등하게 분산하여 선형적으로 확장 가능
단점:
- 애플리케이션이 필요한 개체에 액세스하려면 더 많은 인텔리전스가 필요합니다.
- 고급 데이터 모델링
- 애플리케이션을 작성하기 전에 애플리케이션의 데이터 액세스 패턴에 대한 보다 심층적인 이해
뷰에서 데이터 읽기
Couchbase 4.0 이전까지는 개체 ID를 모르는 경우 뷰 인덱스가 Couchbase를 쿼리할 수 있는 유일한 방법이었습니다. 이제 N1QL을 구동하는 쿼리 및 인덱스 서비스가 생겼으니 Couchbase 보기가 무엇인지, 가장 잘하는 것이 무엇인지, 왜 여전히 중요한지 다시 한 번 살펴보겠습니다.
카우치베이스의 뷰는 인덱스를 생성하는 자바스크립트 맵 축소 함수입니다. 뷰는 변이가 발생하면 데이터베이스에 의해 자동으로 업데이트됩니다. 그러면 애플리케이션에서 해당 뷰 인덱스를 쿼리하여 개체 ID를 반환할 수 있습니다.
예를 들어, 경영진은 정기적으로 iOS 사용자 수, 사용 중인 앱 버전, 출신 국가를 파악해야 하지만 데이터베이스에 있는 30,000,000개의 사용자 문서에 대해 이 작업을 수행해야 합니다. 뷰는 데이터베이스에 데이터가 삽입되거나 업데이트될 때 해당 정보가 계산되므로 이 문제를 매우 잘 해결합니다. 따라서 미리 계산된 뷰를 쿼리해야 할 때 쿼리 비용이 상대적으로 저렴합니다.
한 가지 주의할 점은 뷰는 기본적으로 일관성이 유지된다는 것입니다. 뷰를 쿼리할 때 "stale=false"를 사용하여 뷰를 강제로 업데이트할 수 있습니다. 전에 반환하고 일관성을 유지할 가능성이 높습니다. 하지만 이에 대한 성능 페널티를 지불해야 합니다. 페널티는 데이터베이스에서 데이터가 얼마나 자주 변경되는지, 그리고 뷰가 어떻게 설계되었는지에 따라 달라집니다. stale=false가 설정된 뷰 쿼리를 충족하는 흐름은 앱이 클러스터 노드를 호출하고, 클러스터 노드에서 뷰 인덱스를 업데이트한 다음 결과를 애플리케이션으로 다시 반환하는 것입니다. 이제 삽입/업데이트 속도가 매우 빠르고 쿼리 속도가 높다고 상상해보면 어떤 문제가 발생할 수 있는지 알 수 있습니다. 주의하세요.
장점:
- 대용량 데이터에 대한 간편한 쿼리 기능 제공
- 서버 측에서 실시간으로 실행되는 자바스크립트로 프로그래밍하여 Couchbase의 다른 영역에서 사용할 수 없는 기능을 제공할 수 있습니다.
- 일단 생성되면 업데이트되거나 삽입될 때 모든 개체를 확인하여 포함시킵니다.
- 각 데이터 서비스 노드는 클러스터의 전체 데이터 중 자신의 데이터 부분만 처리합니다. 예를 들어, 4개의 노드로 구성된 클러스터에서 각 노드는 25%의 활성 데이터를 가지고 있으므로 보유한 25%의 데이터만 인덱싱합니다.
단점:
- 자바스크립트로 프로그래밍해야 합니다. 따라서 익숙해지기가 조금 더 복잡하지만 강력하기도 합니다.
- 뷰 인덱스는 인덱스 서비스가 아닌 데이터 서비스 노드에 분산되어 있습니다. 데이터 서비스의 일부로 노드가 많을수록 뷰 엔진이 애플리케이션에 대한 답을 얻기 위해 데이터를 가져와야 하는 노드가 많아집니다.
- 기본적으로 일관성이 유지되지만 stale=false로 쿼리할 수 있지만 성능 저하를 감수해야 합니다.
N1QL로 데이터 읽기 및 쓰기
이제 N1QL을 통해 전통적인 데이터 쿼리를 시작하겠습니다. SELECT this FROM that WHERE this = '우리가 아는 것' JOIN 그 다른 것과 함께. 개체 ID를 통한 액세스가 방 안의 짐승이라면 이 마법사는 강력한 마법사입니다.
N1QL과 이를 구동하는 쿼리 및 인덱스 서비스는 독립적으로 관리되는 서비스를 통해 성능과 확장성을 제공하면서 Couchbase의 데이터에 가장 유연하게 접근할 수 있도록 해줍니다. 분석, 복잡한 쿼리, 데이터 비교 등을 수행해야 하는 경우, N1QL은 바로 여러분이 찾고 있는 것입니다. 도서관에 가서 책이 필요하다고 비유하자면, N1QL로 쿼리하는 것은 사서가 사용자가 가지고 있는 데이터에 맞는 책을 가져다주는 것과 같습니다. "도서관에 있는 1998년부터 2014년 사이에 쓰여진 닐 게이먼 작가의 책이나 그래픽 노블을 모두 가져와 주세요."라고 요청하는 것입니다. 이렇게 하면 Couchbase가 사용할 수 있는 애플리케이션 기능의 종류가 상당히 달라집니다.
카우치베이스 클라이언트 SDK의 가장 큰 장점은 다른 방법을 사용하여 쿼리하기만 하면 SDK가 적절한 서비스와의 통신을 처리한다는 것입니다. 그 외에는 추가 작업을 할 필요가 없습니다. 앱에서 첫 번째 호출은 조인을 사용하는 복잡한 N1QL 쿼리일 수 있고, 다음 호출은 쿼리 결과를 사용하여 맵 축소 보기를 호출하여 미리 계산된 집계를 가져오는 것입니다. 이는 작업에 적합한 도구를 사용하는 것이 합리적이며 옵션을 제공하는 또 다른 예입니다.
이제 강력한 성능과 유연성을 확보했으니, 쿼리 서비스와 통합할 수 있는 다른 도구도 있습니다. Couchbase는 Simba Technologies와 협력하여 데이터 액세스를 위한 ODBC 및 JDBC 드라이버도 만들었습니다. 이를 통해 Excel이나 펜타호, Informatica 등과 같은 더 복잡한 BI 도구를 활용할 수 있습니다.
장점:
- 데이터베이스에서 데이터를 쿼리하여 필요한 답변을 얻을 수 있는 매우 유연한 기능입니다.
- 인덱스는 인덱스 노드를 서비스하는 노드에만 위치하며 클러스터 전체에 분산되어 있지 않습니다.
- 다차원 확장(MDS)을 사용하여 애플리케이션에 필요한 성능을 얻기 위해 필요한 서비스만 확장할 수 있습니다.
- SQL을 아는 개발자는 N1QL 작성으로 쉽게 전환할 수 있습니다.
- BI 도구와의 통합을 위한 ODBC 및 JDBC 드라이버
단점:
- 쿼리는 개체 ID를 통해 데이터에 액세스하는 것만큼 성능이 좋지 않은데, 이는 이미 살펴본 이유 때문입니다.
- 기본적으로 일관성이 유지되지만, stale=false로 쿼리하여 인덱스를 즉시 업데이트할 수 있지만 성능에 타격을 입게 됩니다. 하지만 대부분의 워크로드에서는 인덱스가 백그라운드에서 가능한 한 빨리 업데이트되므로 일관성이 유지됩니다.
Solr 또는 Elastic으로 전체 텍스트 검색
Couchbase는 Solr 및 Elastic(검색)과 통합됩니다. 플러그인을 통해 현재로서는 Couchbase에 없는 전체 텍스트 검색 기능을 제공합니다. 이에 대한 기능적 요구 사항이 있는 경우, 각 플러그인에는 모든 쓰기/업데이트 작업을 Solr 및/또는 Elastic으로 스트리밍할 수 있는 플러그인이 있습니다. 기본적으로 이러한 검색 서버는 전체 JSON 문서를 저장하지 않고 전체 텍스트 검색을 허용하는 데 필요한 내부 구성 요소(인덱스 등)만 생성합니다. 일단 문서가 검색 가능해지면, 애플리케이션은 해당 기능이 필요할 때 해당 도구를 참조하고, 검색 결과를 얻고, 필요한 경우 Couchbase에서 전체 문서를 읽습니다. 이렇게 하면 각 도구를 가장 잘 활용할 수 있고 각 도구에서 최고의 성능을 얻을 수 있습니다.
장점:
- 전체 텍스트 검색 기능 제공
- 애플리케이션은 이중 쓰기를 할 필요가 없으며, Couchbase에 쓰면 거기서부터 색인을 위해 Elastic/Solr에 자동으로 쓰기가 복제됩니다.
- 각 시스템은 필요한 작업을 처리하도록 확장할 수 있습니다.
단점:
- Solr 또는 Elastic을 위한 별도의 인프라를 유지해야 합니다.
- 결국 일관성
- 카우치베이스 클러스터에 완전히 통합되지 않음
- Couchbase SDK에 내장되어 있지 않으므로 애플리케이션은 이 중 하나 및 Couchbase와 대화해야 합니다.
"왜 그냥 Solr이나 Elastic을 사용하고 Couchbase는 아예 건너뛰지 않나요?"라고 질문하실 수도 있습니다. 그 이유는 간단합니다. 두 서비스 모두 그 기능에 있어서는 훌륭하지만, Solr이나 Elastic은 데이터베이스가 아니며 Couchbase의 성능이나 기타 강력한 기능을 가지고 있지 않기 때문입니다. 직접 테스트해 보면 둘 다 Couchbase에서 동일한 데이터를 가져오는 것보다 최소 2~3배 느릴 수 있다는 것을 알게 될 것입니다.
요약
Couchbase에서 데이터에 액세스하는 방법과 애플리케이션에 필요한 기능 및 성능 요구 사항에 따라 제가 설명한 도구를 혼합하여 필요한 결과를 얻을 수 있습니다. 원시 속도 및/또는 완전한 일관성이 필요하다면 개체 ID와 표준화된 키 패턴을 통한 액세스를 사용하세요. 데이터에 대해 질문해야 하는 경우에는 보기, N1QL 또는 전체 텍스트 검색을 사용하세요. 많은 문서를 가져와서 빠르게 업데이트해야 하는 경우, 보기와 개체 ID를 통한 액세스를 혼합하세요.
또 다른 장점은 액세스 방법 #1-3이 모두 Couchbase SDK에 내장되어 있으며, 애플리케이션에서 "각 방법이 마법을 수행하는 방법"이 난독화되어 있다는 것입니다. 따라서 이러한 모든 액세스 패턴을 결합하여 함께 작동할 수 있을 뿐만 아니라 노트북의 Couchbase 단일 노드에서 모든 기능을 사용하여 민첩하게 개발할 수 있을 뿐만 아니라 클러스터의 규모에 관계없이 동일한 코드로 작동할 수 있습니다. 따라서 클러스터에 3개 노드가 있든 80개 노드가 있든 상관없이 코드 변경 없이 애플리케이션을 확장할 수 있습니다.
