1- Couchbase에는 관리 작업을 위한 Restful API가 있습니다.
Couchbase의 웹 콘솔은 관리용 Restful API의 소비자에 불과합니다. 따라서 일반적으로 웹 콘솔에 로그인해야 하는 거의 모든 작업을 자동화할 수 있습니다:
API 설명서를 확인할 수 있습니다. 여기
2- AWS에 빠르게 배포할 수 있습니다.
카우치베이스는 쉽게 설치할 수 있습니다. 다양한 플랫폼에서또는 도커. 그러나 프로덕션 수준의 배포가 필요한 경우, 저희의 테라폼 템플릿 또는 AWS 빠른 시작.
3- 쿠버네티스 또는 오픈 시프트 상에서 실행 가능
카우치베이스는 다음에 배포할 수 있습니다. Kubernetes 또는 OpenShift. 또한 연산자를 사용하여 클러스터에 새 노드 가입, 데이터 재조정, 로그 통합 등과 같은 인프라 관리의 상당 부분을 자동화할 수 있습니다.
지금까지 개발자는 두 가지 선택지 사이에 갇혀 있었습니다: 개발자가 직접 데이터베이스를 관리하거나 타사에 의존하는 것입니다. 데이터베이스를 미세 조정할 수 있는 유연성을 잃지 않으면서 데이터베이스를 유지 관리하는 데 필요한 대부분의 작업을 자동화할 수 있는 세 번째 옵션으로 Kubernetes/OpenShift가 등장했습니다.
4- 카우치베이스는 대규모 확장 가능
익숙한 대부분의 데이터베이스와 달리 Couchbase는 동일한 클러스터에서 수백 개의 노드로 확장할 수 있도록 설계되었습니다. 다양한 아키텍처 기능 덕분에 고성능과 선형 확장성을 결합할 수 있습니다: 투명한 샤드, 다차원 스케일링, 마스터리스 아키텍처, 데이터베이스 변경 프로토콜단일 장애 지점 없음 등
5- 전체 텍스트 검색 색인을 만들 수 있습니다.
대부분의 사용자 대면 애플리케이션은 결국 일종의 고급 검색을 구현해야 합니다. 이러한 종류의 기능을 구현하려면 일반적으로 데이터를 Solr 또는 Elastic Search와 같은 타사 도구로 푸시해야 합니다. 그러나 이러한 도구를 추가하면 이러한 도구에 개체/문서 변경 사항을 푸시하는 데 필요한 모든 코드는 말할 것도 없고 인프라의 비용과 복잡성이 크게 증가합니다.
Couchbase 5.0부터는 웹 콘솔에서 간단하게 전체 텍스트 검색 인덱스를 생성하고 데이터베이스에서 바로 전체 텍스트 검색을 시작할 수 있습니다:
또한 다음과 같은 지원도 제공됩니다. 지리공간 쿼리 그리고 파티션/복제 색인:
6- 다양한 데이터 시각화 도구와 쉽게 연결할 수 있습니다.
과거에 NoSQL 데이터베이스가 실패했던 이유 중 하나는 데이터베이스를 애플리케이션의 데이터를 저장하는 데만 사용하지 않고 보고서와 분석을 실행하는 데도 사용했기 때문입니다. 이것이 바로 우리가 데이터베이스를 쿼리하는 매우 강력한 SQL과 유사한 방식인 N1QL을 만든 이유 중 하나입니다.
물론 데이터베이스를 쿼리하는 것은 절반의 기록에 불과합니다. 대부분의 경우 그래프, 경향을 표시하고 대시보드를 만드는 등의 작업도 필요합니다. 그렇기 때문에 다음과 같은 다양한 시각화 도구와 Couchbase를 연결할 수 있습니다. Talend, Tableau, Knowi 및 기타 여러 가지.
대량의 보고서를 생성해야 하지만 애플리케이션 성능에 영향을 미치고 싶지 않다면 새로운 분석 서비스.
7- 엔드 투 엔드 데이터 압축 지원
대부분의 클라우드 제공업체에서는 높은 네트워크 트래픽, 디스크 사용량, 메모리로 인해 매달 막대한 비용이 발생할 수 있습니다. 이 문제를 해결하기 위해 Couchbase는 엔드투엔드 압축을 지원하여 클라이언트에서 캐시, 디스크 스토리지까지 데이터를 압축된 상태로 유지하고 데이터 센터 간에 데이터를 복제할 수 있습니다.
아래 그림은 클라이언트 애플리케이션에서 데이터가 압축되는 스토리지에 이르는 데이터 흐름의 다양한 단계를 보여줍니다.
이에 대한 자세한 내용은 다음에서 확인할 수 있습니다. 여기.
8- 쿼리 감사 가능
저장하는 데이터가 어떤 식으로든 민감한 데이터인 경우, 특정 문서에 대해 실행되는 쿼리를 감사하여 보안 계층을 추가하는 것을 고려할 수 있습니다. 감사는 보안 -> 감사에서 활성화할 수 있습니다:
감사할 이벤트 유형과 감사하지 않을 이벤트 유형을 선택할 수도 있습니다:
로그는 지정한 디렉터리 내에 audito.log라는 파일에 저장됩니다. 이에 대해 자세히 알아보려면 다음과 같이 하세요. 이 문서 확인.
9- 노드가 자동으로 실패하도록 구성할 수 있습니다.
분산 시스템에서는 느린 노드가 완전히 실패한 노드보다 더 해로울 때가 있습니다. 클러스터의 모든 통계를 면밀히 관찰하지 않는다면 이러한 느린 노드를 인식하는 것은 간단한 작업이 아닙니다. Couchbase 5.5부터는 제대로 작동하지 않는 인스턴스를 자동으로 실패하도록 클러스터 관리자를 구성할 수 있습니다:
또한 다른 문제가 발생할 경우 알림을 정의할 수도 있습니다:
다음을 참조하세요. 이 문서 자동 페일오버에 대해 자세히 알아보려면
10- 응답 시간 관찰 가능성
개발팀/DBA가 클러스터의 문제를 더 쉽게 파악할 수 있도록 많은 노력을 기울였습니다. Couchbase에는 이미 다음과 같은 진단 도구 세트가 있습니다. Java SDK에 내장된 메트릭에서 N1QL의 고급 메트릭 및 프로필 정보또는 Couchbase Server 5.0에 도입된 임계값 및 로깅에 대해 설명합니다.
하지만 버전 5.5부터는 응답 시간 관찰 기능이라는 새로운 기능을 도입하여 시스템 배포자가 (조정 가능한) 임계값을 기준으로 응답 시간을 매우 간단하게 관찰할 수 있는 방법을 제공하게 되었습니다.
오픈트레이싱 형식을 사용하는 이 기능은 느린 요청과 그에 대한 세부 정보를 시간 간격마다 기록하므로 성능이 저하된 작업을 쉽게 식별할 수 있습니다.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 |
4월 04, 2018 9:42:57 AM com.카우치베이스.클라이언트.핵심.추적.임계값 로그 리포터 로그 오버 임계값 경고: 운영 over 임계값: [ { "top" : [ { "서버_미국" : 8, "local_id" : "41837B87B9B1C5D1/000000004746B9AA", "local_address" : "127.0.0.1:55011", "operation_id" : "get:0x6", "dispatch_us" : 315, "remote_address" : "127.0.0.1:11210", "total_us" : 576 }, { "서버_미국" : 8, "local_id" : "41837B87B9B1C5D1/000000004746B9AA", "local_address" : "127.0.0.1:55011", "operation_id" : "get:0x5", "dispatch_us" : 319, "remote_address" : "127.0.0.1:11210", "total_us" : 599 }, { "서버_미국" : 8, "local_id" : "41837B87B9B1C5D1/000000004746B9AA", "local_address" : "127.0.0.1:55011", "operation_id" : "get:0x4", "dispatch_us" : 332, "remote_address" : "127.0.0.1:11210", "total_us" : 632 }, { "서버_미국" : 11, "local_id" : "41837B87B9B1C5D1/000000004746B9AA", "local_address" : "127.0.0.1:55011", "operation_id" : "get:0x3", "dispatch_us" : 392, "remote_address" : "127.0.0.1:11210", "total_us" : 762 }, { "서버_미국" : 23, "local_id" : "41837B87B9B1C5D1/000000004746B9AA", "local_address" : "127.0.0.1:55011", "operation_id" : "get:0x1", "decode_us" : 9579, "dispatch_us" : 947, "remote_address" : "127.0.0.1:11210", "total_us" : 16533 }, { "서버_미국" : 56, "encode_us" : 12296, "local_id" : "41837B87B9B1C5D1/000000004746B9AA", "local_address" : "127.0.0.1:55011", "operation_id" : "upsert:0x2", "dispatch_us" : 1280, "remote_address" : "127.0.0.1:11210", "total_us" : 20935 } ], "서비스" : "kv", "count" : 6 } ] |
응답 시간 관찰 가능성은 기본적으로 켜져 있으며, 정상 요청을 기록하지 않도록 임계값을 이미 정의해 놓았습니다. 클러스터의 한계를 뛰어넘고 싶다면 더 작은 임계값을 수동으로 설정할 수도 있습니다. 자세한 내용은 다음을 참조하세요. 여기.
