데이터베이스 성능을 개선하는 방법: 5가지 단계

성능 모니터링 솔루션 배포
최신 상용 버전의 Couchbase 사용
인프라 규모를 적절히 조정하세요
준비된 명령문 사용
인덱스 최적화

데이터베이스 성능을 개선하는 데는 여러 단계가 있습니다. 하지만 먼저 이상적인 데이터베이스 성능이란 무엇일까요? 이 글에서는 데이터베이스 전문가로서 제 경력에서 도움이 되었던 몇 가지 영역을 안내해 드리겠습니다. 아래의 각 단계는 데이터베이스 최적화의 세계에 대해 더 자세히 알아볼 수 있는 출발점입니다. 이 중 일부는 다른 것보다 더 폭발적인 이점을 제공하지만 모두 조사해 볼 가치가 있습니다. 각 환경은 다르며 내부 및 외부 고객의 요구 사항을 충족하기 위해 여러분과 여러분의 팀이 다른 접근 방식을 필요로 할 수 있다는 점을 기억하세요. 마지막으로, 데이터베이스 성능을 개선하는 방법에 관해서는 저희가 할 수 있는 모든 방법으로 도와드리겠습니다.

데이터베이스 성능 모니터링 솔루션 배포

세계에서 가장 빠른 NoSQL 데이터베이스를 모니터링 없이 사용하는 것은 종이를 방화벽으로 사용하는 것만큼이나 현명하지 못한 일입니다. 놀랍게도 종이는 한때 모터스포츠에서 엔진과 레이싱 드라이버 사이의 방화 가드로 사용되었습니다! 마찬가지로 믿을 수 없을 정도로 일부 회사는 올바른 모니터링에 필요한 시간과 비용을 투자하지 않습니다. 물론 독자 여러분은 이미 모니터링 솔루션을 구현하고 모든 기본 사항이 충족되는지 확인하고 있는 깨어 있는 사람 중 한 명이기 때문에 여러분은 아닙니다(제가 한 일을 보셨나요?). 그렇지 않더라도 걱정하지 마세요, IPO에 대한 자세한 내용은 여기에서 확인할 수 있습니다.) 또는 할 일 목록의 맨 위에 있습니다.

가장 먼저 결정해야 할 것은 무엇을 모니터링해야 하는지입니다. 무엇을 달성하려고 하나요? 평가 결과 필요한 모든 것을 갖추지 못했다고 판단되면 비즈니스 기준을 충족하기 위해 구매하거나 구축해야 하나요?

모니터링 및 최적화를 전문으로 하는 툴 업계에서 10년 넘게 독립 소프트웨어 공급업체(ISV)로 일해 온 저는 이미 구매 대 구축 논쟁과 모니터링 솔루션에서 무엇을 찾아야 하는지에 대해 수천 개의 글을 썼습니다. 요약하면, 일반적으로 자본 대 운영 비용의 싸움과 정치적 환경에서 가장 중요하게 생각하는 것이 무엇인지로 귀결됩니다:

• 재정 지출 및 수익 창출 관점에서 시간의 가치는 어느 정도인가요?
• 인수의 ROI는 얼마인가요?

데이터베이스 성능을 측정하는 방법과 관련하여 성능 개선 영역을 구체화하기 위해서는 이러한 근본적인 질문에 답해야 합니다.

물론 배포할 수 있는 모니터링 솔루션을 제공하는 여러 회사가 있습니다. 여기에서는 이러한 회사의 이름을 밝히지 않으므로 자주 사용하는 검색 엔진에 몇 가지 키워드를 입력하면 쉽게 찾을 수 있습니다. 이 섹션의 나머지 부분에서는 모니터링을 위한 몇 가지 기본 모니터링 기능과 오픈 소스 옵션에 대해 소개하겠습니다.

메트릭을 가장 쉽게 볼 수 있는 첫 번째 방법은 Couchbase 웹 콘솔을 이용하는 것입니다. 관련 권한이 있는 사람은 누구나 사용 가능한 수많은 메트릭을 보거나 사용자 지정 대시보드를 만들 수 있습니다.

기본 대시보드의 예는 아래에서 확인할 수 있습니다. 시간 프레임, 버킷을 변경하고 개별 노드를 자세히 살펴볼 수 있는 기능에 주목하세요.

대시보드를 만들려면 다음과 같이 하세요. 대시보드 탭을 클릭한 다음 대시보드 선택 또는 나만의 대시보드 만들기라고 표시된 드롭다운 목록을 클릭합니다. 이 예에서는 현재 차트를 사용하지 않고 빈 캔버스로 시작합니다.

저장을 클릭하면 차트용 그룹을 새로 만들지 묻는 메시지가 표시됩니다. 그룹을 추가한 후 다음을 클릭합니다. 차트 추가하기.

차트를 추가할 때 표시할 크기와 데이터 메트릭을 선택할 수 있습니다. 이 특정 예에서는 결합된 보기가 아닌 개별 노드를 표시합니다. 메트릭이 무엇인지 잘 모르는 경우 메트릭 위로 마우스를 가져가면 도구 설명이 표시됩니다.

이 글의 뒷부분에서 인덱스에 대해 이야기할 것이므로, 이 유휴 시스템에서 4개의 인덱스 카운터를 선택하여 시스템이 표시할 수 있는 데이터의 종류를 보여주었습니다:

보시다시피, 대시보드를 손쉽게 만들 수 있으며 환경에 가장 적합한 방식으로 가장 중요한 메트릭에 집중할 수 있습니다.

직접 소매를 걷어붙이고 데이터를 조사하는 것을 선호한다면 다음을 살펴보는 것이 더 흥미로울 수 있습니다. cbstats 또는 REST API를 통해 클러스터 통계 가져오기. 볼 수 있는 메트릭이 너무 많으므로 여기서는 자세히 설명하지 않겠습니다. 대신 수집할 수 있는 항목에 대해 자세히 알아보려면 다음을 참조하세요. 카우치베이스 모니터링 가이드.

관심 있는 메트릭을 선택한 후에는 Grafana에서 시각화할 수 있으며, 이 훌륭한 블로그 게시물에서 그 과정을 안내해 드립니다. Prometheus, Grafana 및 CouchBase로 통합 가시성 대시보드를 구축하는 방법.

최신 Couchbase Enterprise 버전 사용

Couchbase의 상용 버전이 무료 버전보다 훨씬 뛰어난 기능을 제공한다는 것은 놀라운 일이 아닙니다. 이 섹션에서는 Couchbase Enterprise Edition에서 즉시 활용할 수 있는 핵심 기능 몇 가지를 다룹니다.

Couchbase의 다양한 버전 간의 차이점에 대한 전체 목록은 다음을 참조하세요. https://www.couchbase.com/products/editions.

노드 수량
예상할 수 있듯이 커뮤니티 에디션에서 허용되는 노드 수는 상용 버전보다 훨씬 적습니다. 현재 노드 수는 5개로 제한되어 있지만, 이는 변경될 수 있으므로 항상 최신 문서를 확인해야 합니다.

데이터베이스 성능 문제가 발생하는 이유는 무엇이며 해결 방법은 무엇인가요? 몇 가지 이유가 있는데, 가장 큰 이유는 확장성이며, 이는 성능에 영향을 미칩니다. 노드를 5개 이상으로 확장하지 못하면 대규모 데이터 세트에서 문제가 발생하는 것은 당연한 일입니다. 더 많은 하드웨어를 사용하지 못하는 것은 메모리 우선 아키텍처에서 문제가 될 것입니다. 예상대로 Enterprise는 압축 등을 통해 여러 가지 방법으로 이 문제를 완화합니다.

압축
이는 성능을 개선하고 총소유비용을 낮게 유지하는 데 있어 핵심적인 요소입니다. RAM에 더 많은 문서를 저장할 수 있다면 하드웨어가 줄어들고 비용이 절감됩니다. 또한 배포와 관리가 간소화되어(너무 어렵지 않다는 뜻이 아닙니다) 비용을 더욱 절감할 수 있습니다.

압축은 높은 데이터 밀도, 즉 쉽게 말해 "메모리에 들어갈 수 있는 것보다 훨씬 많은 데이터"가 있는 시나리오에서 더 중요할 수밖에 없습니다. 따라서 최종 사용자에게 다시 제공하기 위해 디스크에서 데이터를 보존하고 불러와야 합니다. 일반적으로 디스크는 메모리보다 속도가 느리기 때문에 데이터가 작을수록 디스크에서 더 빨리 읽을 수 있습니다.

인덱싱
레거시 관계형 애플리케이션을 NoSQL로 바로 마이그레이션하려는 경우, JSON용 SQL 언어인 SQL++를 사용하게 될 가능성이 높습니다. 또한 스키마와 테이블을 포팅하고 동일한 인덱스를 사용해야 할 것입니다. Couchbase 7.0에서는 확실히 이 작업을 수행할 수 있지만, 커뮤니티 에디션과 엔터프라이즈 에디션 간에 인덱스가 작동하는 방식에 몇 가지 차이점이 있습니다.

첫째, 두 가지 엔진을 사용합니다. 둘째, 엔터프라이즈 버전에서는 파티셔닝을 사용할 수 있습니다. 파티셔닝의 장점은 사용자가 인덱스를 여러 노드에 분할하여 한 노드의 코어에 국한되지 않고 더 많은 코어를 사용할 수 있다는 것입니다. 더 광범위한 인덱스에서는 성능에 상당한 차이를 만들 수 있습니다.

범위 및 컬렉션
커뮤니티 에디션에서는 범위와 컬렉션을 사용할 수 있지만, Couchbase가 제공하는 모든 서비스에서 사용할 수 있는 것은 아닙니다. Couchbase를 처음 사용하고 범위 및 컬렉션에 대해 들어본 적이 없지만 관계형 데이터베이스에 익숙한 경우 범위는 스키마와 비슷하고 컬렉션은 테이블과 비슷할 것입니다.

Couchbase가 관계형 데이터베이스가 되는 것처럼 들리지만, 실제로는 관계형과 분산 NoSQL의 세계를 융합하는 엔터프라이즈 애플리케이션을 위한 최신 데이터베이스입니다. 기존 모놀리식 시스템에서 마이크로서비스를 지원하는 새로운 분산 메모리 우선 아키텍처로 마이그레이션하는 것이 그 어느 때보다 쉬워지고 있습니다.

범위와 컬렉션을 추가함으로써 여러 내부 프로세스를 재설계하여 이전 버전보다 훨씬 빠른 성능을 구현하는 동시에 클러스터에서 지원하는 인덱스 수와 같은 기능도 늘릴 수 있었습니다.

데이터베이스 성능을 향상시키는 방법과 관련하여, 이 새로운 기능은 멀티테넌트 환경을 지원하는 기능을 강화하여 총 소유 비용을 절감합니다. Couchbase 7.0에서 범위 및 컬렉션을 구현하는 방법에 대해 자세히 알아보려면 이 블로그를 확인하세요. 범위 및 컬렉션으로 Couchbase에서 멀티테넌트 앱 배포를 간소화하는 방법.

인프라 규모를 적절히 조정하세요

관계형 배경을 가진 저는 모든 데이터와 플랫폼이 제공하는 다양한 구성 요소가 단일 서버에 있다는 점에서 많은 제약이 있었습니다. 이것은 관계형 플랫폼에 대한 이야기가 아닙니다. 그러나 여러분은 이미 이러한 플랫폼의 확장에 대해 잘 알고 있고, 비용이 얼마나 많이 드는지 알고 있으며, 이러한 플랫폼으로 다시 설계하고 확장하는 것이 얼마나 어려운지 잘 알고 있을 것입니다.

여기에서 다차원 스케일링(MDS) 이 들어왔을 때 위의 이유 때문에 즉시 제 관심을 끌었습니다. 더 이상 시스템에 제약을 받지 않았죠. 추가 성능이 필요한 서비스만 스케일업하거나 스케일아웃할 수 있었죠. MDS에 대해 들어본 적이 없다면 위에 링크한 문서를 빠르게 읽어보세요. TLDR의 핵심은 여러 머신에 여러 서비스를 설치할 수 있다는 것입니다. 모든 머신에 걸쳐 스트라이핑하거나 각 서비스별로 전용 머신에 스트라이핑할 수 있습니다. 전용 머신은 워크로드를 격리하고 시스템의 어느 한 부분이 다른 부분에 부정적인 영향을 미치지 않도록 보장하므로 프로덕션 환경에서 사용하는 것이 좋습니다. 물론 비용을 절감하기 위해 개발, QA, 사전 제작 등 비프로덕션 환경에서는 리소스를 공유할 수도 있습니다.

격리가 왜 그렇게 중요한가요? 좋은 질문입니다. 모든 것은 하나의 시스템에서 모든 것을 처리하고 공유 리소스를 고르게 활용하지 못하는 모놀리식 방식으로 돌아갑니다. 관계형 데이터베이스에서 이러한 문제를 경험하지 않으셨더라도, 리소스가 전체적으로 할당되어 있다고 생각했던 CPU가 다른 곳에 할당된 가상 머신에서 이러한 문제를 경험하신 적이 있으실 것입니다.

아직도 확신이 서지 않으시나요? 그렇다면 지난 몇 년 동안 수백 개의 환경에서 본 일반적인 문제 중 분산된 격리 워크로드를 사용하면 피할 수 있는 세 가지 문제를 공유해 드리겠습니다.

일정 예약
제가 가장 많은 경험을 가진 관계형 데이터베이스는 협력 스케줄러를 사용합니다. 이 스케줄러는 운영 체제가 필요한 작업을 수행할 수 있도록 다른 프로세스에 CPU 요청을 양보합니다. 데이터베이스가 운영 체제를 인질로 잡고 있지 않으니 좋은 일처럼 들리네요! 그렇기도 하고 그렇지 않기도 합니다. 문제는 협동조합은 일반적으로 운영 체제와 다른 타사 애플리케이션을 구분하지 않는데, 이는 주로 시간이 지나면서 운영 체제가 변경되고 새로운 프로세스가 추가될 것이기 때문입니다.

다른 애플리케이션이 다른 공급업체에서 설치되었거나 경우에 따라 동일한 데이터베이스 공급업체에서 설치된 경우 문제가 발생합니다. 데이터베이스 엔진은 이러한 다른 애플리케이션이 CPU 시간을 요청할 때 양보합니다. 저는 다른 애플리케이션이 CPU를 요청했다는 이유만으로 상당한 시간 동안 CPU를 기다리는 수많은 시스템을 보았습니다. 물론 데이터베이스는 규칙을 준수할 뿐인데도 비난을 받습니다. 반대로 정말 고립된 분산 아키텍처였다면 이런 문제는 발생하지 않았을 것입니다.

캐시 부풀리기
요약하면, 많은 데이터베이스 공급업체는 플랜 캐시 또는 프로시저 캐시라는 메모리 영역을 생성합니다. 일반적으로 실행 또는 설명 계획이라고 하는 것을 계속 생성하는 것은 CPU를 너무 많이 사용한다는 생각에서입니다. 일단 계획이 만들어지면 이 메모리 영역에 저장됩니다. 문제는 디스크의 데이터에 대한 액세스 시간을 줄이기 위해 이 메모리 영역을 메모리에 데이터를 저장하는 동일한 시스템에서 공유할 때 발생합니다.

발생할 수 있는 일은 (데이터베이스에 따라 다르지만) 계획/프로시저 캐시가 사용 가능한 메모리 양을 상당히 많이 차지한다는 것입니다. 즉, 데이터에 사용할 수 있는 메모리가 줄어들고 물리적 디스크를 더 많이 사용해야 하므로 지연 시간이 증가하고 처리량이 크게 떨어집니다.

다시 말하지만, 쿼리 노드와 데이터 노드를 격리하여 분리하도록 시스템을 설계할 수 있습니다. 이는 메모리가 분리되어 있어 이런 일이 발생하지 않을 뿐만 아니라 CPU도 분리되어 있다는 것을 의미합니다. 계획을 만드는 것이 CPU 집약적이라고 말씀드린 것을 기억하세요.

인덱스 재구축
이 문제는 위의 시나리오와 몇 가지 공통점을 공유하지만 다양한 데이터베이스 엔진의 다른 부분을 사용합니다. 일부 데이터베이스 엔진은 데이터와 인덱스 페이지를 동일한 메모리 공간에 저장합니다. 아마도 이것이 어디로 가는지 예측할 수 있을 것입니다. 모든 환경에 인덱스 조각 모음 루틴이 있는 것은 아니지만, 일반적으로 인덱스가 크고 디스크 액세스 및 로깅을 많이 유발할 수 있으므로 중단을 가장 적게 유발하는 기간에 인덱스 조각 모음을 수행해야 합니다.

이 때문에 여러 회사에서 시스템이 가장 한가한 일요일에 인덱스 재구축을 수행하는 것을 보았습니다. 문제는 월요일 아침은 많은 사람들이 동시에 로그온하여 지난 주, 심지어는 지난 달, 분기 또는 연간 보고서를 실행하려고 하는 등 가장 바쁜 시간 중 하나라는 점입니다.

이것이 왜 문제일까요? 다시 공유 메모리 공간으로 돌아가 보겠습니다. 설명을 위해 현재 메모리 캐시에 50% 인덱스와 50% 데이터가 있다고 가정해 보겠습니다. 모든 인덱스를 다시 빌드하면 어떻게 될까요? 간단한 대답은 각 테이블/문서에서 데이터를 읽어와서 각 인덱스를 차례로 다시 빌드한다는 것입니다.

실제로는 조금 더 복잡합니다. 그 결과 주말 전에 캐시에 있던 데이터가 긴급한 보고서가 모두 실행되는 월요일에는 더 이상 캐시에 남아 있지 않게 됩니다. 즉, 이러한 요청을 충족하는 데 필요한 모든 인덱스와 데이터를 가져오는 디스크 액세스 속도가 느려집니다. 다시 말하지만, 분산 격리 아키텍처를 사용하면 서로 다른 노드에서 별도의 서비스를 제공하므로 필요한 데이터가 여전히 메모리에 남아 있다는 이점을 누릴 수 있습니다.

이는 엔터프라이즈 에디션에 제공되는 혜택 중 일부에 불과합니다. 고려하고 싶은 경우 소프트웨어를 체험해 보세요, 에 문의하세요. 영업 팀. 이미 고객이고 정확한 노드 수를 보유하고 있으며 올바르게 아키텍처를 설계했는지 확인하려면 영업 담당자 및 영업 엔지니어에게 문의하면 기꺼이 도와드릴 것입니다.

준비된 명령문 사용

쿼리를 잘못 작성된 것과 고도로 최적화된 것의 두 가지 범주로 분류할 수 있습니다. (죄송합니다, 죄송하지 않습니다). "잠깐만요, 이 쿼리는 충분히 좋은데요."라고 생각하는 분도 계실 것입니다. 테스트 하네스에서는 그럴 수 있지만, 데이터베이스를 개선하는 방법에 관해서는 1,000명 이상의 사용자가 해당 시스템에서 어떻게 확장되는지 테스트할 준비가 되어 있나요? 아마 아닐 것입니다. 이제 왜 모니터링이 목록의 첫 번째 항목이 되었는지 아시겠습니까?

높은 처리량과 짧은 지연 응답 시간이 필요한 경우, 좋은 데이터 모델과 쿼리 에티켓이 필요합니다. 이미 카우치베이스 엔터프라이즈 에디션이 적합한 이유에 대해 다루었으며, 다음 섹션에서는 인덱스 최적화에 대해 다룰 예정입니다. 이 섹션에서는 준비된 쿼리에 대해 이야기하겠습니다. 생소할 수도 있지만 배울 가치가 있는 내용입니다.

모든 것이 그렇듯이 모든 결정에는 잠재적인 단점이 있습니다. 모든 SQL++ 쿼리에 준비된 문을 사용하라고 제안하는 것은 절대 아닙니다. 어느 부분이 합당한지 실사를 통해 확인해야 합니다.

이쯤 되면 준비된 문장이란 무엇일까요? 지난번 사이징 섹션에서 이에 대해 살짝 언급했습니다. 많은 데이터베이스 공급업체가 자사 제품에 추가하는 최적화 기능 중 하나는 실행 계획을 저장하는 것입니다. 이렇게 하면 실행할 때마다 계산해야 하는 비용이 줄어듭니다.

이 작업은 SDK와 CLI 또는 쿼리 워크벤치를 통해 수행할 수 있습니다. 아래 예제는 쿼리 워크벤치에서 작동하도록 설계되었습니다.

예 1 - Couchbase 7.0 이전 버전의 준비된 명세서:

예제 1은 5개의 호텔 문서에서 모든 데이터를 반환하는 간단한 쿼리를 보여줍니다. Couchbase 7.0 이상 버전만 사용했다면 'type' 속성을 보지 못했을 것입니다. 이 속성은 사용 중인 문서의 종류를 식별하는 데 사용되었습니다. 이 속성은 범위 및 컬렉션이 도입되면서 단계적으로 제거되었습니다.

예제 2 - Couchbase 7+에서 준비된 문, 버킷을 다음과 같이 설정해야 합니다. 여행 샘플 및 범위를 인벤토리 쿼리 워크벤치에서

예제 2는 실제 준비하고자 하는 쿼리에 좀 더 가까운 쿼리를 보여줍니다. 이 경우에는 문서의 모든 속성이 아닌 반환하고자 하는 속성만 신중하게 선택했습니다. 또한 매개변수와 ORDER BY 절을 포함하여 더 많은 술어를 추가했습니다. 이렇게 하면 좋은 인덱싱 전략으로 쿼리를 더 쉽게 지원할 수 있습니다.

데이터 모델링은 그 자체로 방대한 주제이기 때문에 이 게시물에서 다루기에는 너무 길지만, 추가 정보를 얻을 수 있는 몇 가지 링크를 제공하고자 합니다.

건축가를 위한 무료 단기 강좌를 소개합니다, CB131를 통해 데이터 모델링을 비롯한 Couchbase 기본 사항을 다룹니다. 여기에서 심층 심화 과정을 구매할 수 있습니다, CD212를 통해 데이터 모델링 및 쿼리 접근 방식에 대해 자세히 알아보세요.

인덱스 최적화

올바른 색인을 만드는 것은 종종 과학이 아닌 예술로 여겨지지만, 사실은 두 가지 모두에 해당할 수 있습니다. 하지만 색인을 사용해 본 적이 없거나 들어본 적도 없을 수 있으므로 한 걸음 물러서서 생각해 봅시다.

인덱스는 일반적으로 데이터 값을 정렬된 방식으로 구체화한 사본으로 정의되며, 소스 데이터를 훨씬 빠르게 찾을 수 있게 해줍니다. 다른 종류도 있지만 이 설명은 소개를 위한 목적에 부합합니다. 책(단어가 인쇄된 종이로 만든 무거운 물건), 특히 논픽션 책을 기억하실 만큼 나이가 많으시다면 색인이라는 것이 거의 항상 있었습니다. 색인은 책 끝에 있는 섹션으로, 관련 페이지 번호와 함께 단어 목록(알파벳 순서)을 담고 있었습니다. 이를 통해 사용자는 책 전체를 훑어보지 않고도 특정 섹션을 찾아볼 수 있었습니다.

이는 데이터베이스 인덱스와 동일한 전제로, 많은 오버헤드 없이, 즉 필요 이상으로 많은 문서를 읽지 않고도 데이터를 효율적으로 찾을 수 있는 데이터의 또 다른 구체화된 사본을 제공하는 것입니다.

인덱싱은 방대한 주제이므로 여기서 다 다룰 수 없습니다. 일을 더 쉽게 하기 위해 Couchbase는 인덱스 어드바이저 기능을 사용하면 완벽한 인덱스를 만드는 데 드는 부담을 덜 수 있습니다. 이 기능은 쿼리 워크벤치에서 사용하거나 조언 명령을 사용합니다.

인덱스에 속성을 추가하는 순서와 카디널리티(값이 얼마나 고유한지)는 쿼리 성능에 큰 영향을 미칠 수 있습니다.

직접 인덱스를 만들고자 하는 분들을 돕기 위해 술어와 조인을 추가하는 순서는 다음과 같습니다:

1. 평등
2. IN
3. 미만
4. 사이
5. 그 이상
6. 배열 술어
7. 쿼리를 포함하도록 인덱스에 추가 필드를 추가하세요.

최신 Couchbase Enterprise 버전 사용 섹션에서 분할 인덱스에 대한 주제를 다루었습니다. 더 중요한 인덱스와 여러 인덱스 노드가 있는 경우 반드시 테스트해야 할 사항입니다.

인덱스 아키텍처를 통해 성능을 향상시키는 또 다른 데이터베이스 성능 개선 기법은 복제본을 추가로 도입하는 것입니다. 최대 2개의 복제본을 추가할 수 있으며, 각 복제본은 별도의 인덱스 노드에 상주해야 합니다. 이렇게 하면 데이터를 읽을 수 있는 노드가 하나가 아니라 세 개가 됩니다.

이것은 Couchbase가 사용하는 분산 아키텍처의 장점 중 하나에 불과합니다. 관계형 데이터베이스는 일반적으로 읽기 가능한 인덱스 복사본이 하나만 있어 병목 현상을 일으킬 수 있습니다.

리소스

어떤 학습 방법을 선호하든, 시간이 많든 적든 위에서 공유한 아이디어와 아래 요약된 링크를 살펴보는 것만으로도 분명 도움이 될 것입니다. 행복한 최적화!

• 카우치베이스 모니터링 가이드
• Prometheus, Grafana 및 CouchBase로 통합 가시성 대시보드를 구축하는 방법
• 범위 및 컬렉션으로 Couchbase에서 멀티테넌트 앱 배포를 간소화하는 방법
• 다차원 스케일링 
• CB131: 카우치베이스 준건축가 인증 과정
• CD212: Couchbase NoSQL 데이터 모델링, 쿼리, 검색 과정
• 카우치베이스 인덱스 어드바이저
• 다양한 버전의 Couchbase 비교