분류

Couchbase Java SDK 1.2의 새로운 기능

[이 블로그는 https://nitschinger.at/ 에서 신디케이트되었습니다.]

모든 Java SDK 사용자를 위해 몇 가지 멋진 추가 기능을 준비했습니다. 이 게시물에서는 이를 자세히 다루고 생산성을 높일 수 있는 방법을 보여드립니다.

이 블로그 게시물은 1.2.0과 1.2.1 사이에 리스너 지원 및 메트릭 수집 등에 영향을 주는 약간의 변경 사항이 있었으므로 1.2.1 릴리스를 실행하고 있다고 가정합니다.

Maven 중앙 배포

1.2.0 릴리스부터 Java SDK는 Maven Central에서 직접 배포됩니다. 즉, 더 이상 Couchbase 리포지토리를 포함할 필요가 없습니다. 다음 Maven 코드만으로도 충분히 시작할 수 있습니다(그룹아이디가 변경되었음에 유의하세요):

<종속성>
<종속성>
<groupId>com.couchbase.client>
<artifactId>카우치베이스-클라이언트>
<버전>1.2.1>
>
>

이렇게 하면 최신 spymemcached 종속성도 자동으로 로드됩니다(1.2.0의 경우 2.10.0). 변경된 내용을 자세히 살펴보기 전에 여기 는 빠른 참조를 위한 릴리스 노트입니다.

리스너 지원

지금까지는 비동기 요청의 결과를 가져오는 두 가지 방법이 있었습니다. 하나는 현재 스레드를 이렇게 차단하는 것입니다:
// 비동기 연산 수행(즉시 반환)
OperationFuture<부울> setFuture = 클라이언트.set("key", "value");

// 현재 스레드 차단
부울 결과 = setFuture.get();

또는 차단되지 않는 미래 메서드를 반복할 수 있습니다. 선물 목록을 다룰 때 특히 유용합니다.
목록<OperationFuture<부울>> 선물 = new ArrayList<OperationFuture<부울>>();
에 대한 (int i = 0; i < 100; i++) {
선물.추가(클라이언트.set("key-" + i, "value"));
}

동안 (!선물.isEmpty()) {
이터레이터<OperationFuture<부울>> iter = 선물.이터레이터();
동안 (iter.hasNext()) {
OperationFuture<부울> 미래 = iter.다음();
만약 (미래.isDone()) {
iter.제거();
}
}
}

이제 1.2.0부터 응답을 처리하는 새로운 방법인 리스너를 추가할 수 있습니다. 이 아이디어는 작업이 완료되면 실행될 콜백을 미래에 제공하는 것입니다. 간단한 예가 여기에 나와 있습니다:
OperationFuture<부울> setFuture = 클라이언트.set("key", "value");
setFuture.추가 리스너(new OperationCompletionListener() {
오버라이드
public void onComplete(OperationFuture<?> 미래) 던지기 예외 {
시스템.out.println(미래.get());
}
});
참고 .get() 메서드를 호출하면 결과가 이미 계산되었으므로 더 이상 차단되지 않습니다. 콜백 메서드에 무엇을 입력하든 스레드 풀에서 비동기적으로 실행됩니다. 이 접근 방식이 얼마나 유연한지 알아보기 위해 100개의 퓨처가 완료될 때까지 기다리는 위의 예제를 다시 작성해 보겠습니다.
final 카운트다운 래치 래치 = new 카운트다운 래치(100);
에 대한 (int i = 0; i < 100; i++) {
OperationFuture<부울> 미래 = 클라이언트.set("key-" + i, "value");
미래.추가 리스너(new OperationCompletionListener() {
오버라이드
public void onComplete(OperationFuture<?> 미래) 던지기 예외 {
래치.카운트다운();
}
});
}
래치.기다림();
여기서는 카운트다운 래치 는 현재 스레드가 백 번 카운트다운되는 동안 대기합니다. 우리 상황에 정확히 필요한 것이지만 코드가 훨씬 더 읽기 쉽습니다. 더 중요한 것은 새 요청을 실행하거나 웹 서비스를 쿼리하거나 결과를 계산하는 등의 다른 작업을 수행할 수 있기 때문에 훨씬 더 유연하다는 점입니다.
기본값을 재정의할 수도 있습니다. 실행자 서비스 구현을 사용자 정의 구현으로 대체할 수 있습니다. 기본 동작(기본적으로 상한이 설정된 cachedThreadPool)이 사용자의 요구에 맞지 않는 경우 이 방법이 필요할 수 있습니다. 또한 여러 개의 카우치베이스클라이언트 인스턴스를 생성하여 모든 인스턴스에서 동일한 서비스를 공유할 수 있습니다.
// 빌더 생성
카우치베이스커넥션팩토리빌더 빌더 = new 카우치베이스커넥션팩토리빌더();

// 고정 스레드 5개로 스레드 풀 만들기
실행자 서비스 서비스 = 실행자.새로운 고정 스레드 풀(5);

// 빌더에서 설정
빌더.설정 리스너 실행자 서비스(서비스);

// 인스턴스 생성
카우치베이스클라이언트 클라이언트 = new 카우치베이스클라이언트(빌더.빌드 카우치베이스 연결(…));

향상된 프로파일링 기능

실행 중인 애플리케이션에 대한 인사이트를 얻는 것은 언제나 어려운 일이므로, 저희는 사용자가 더 쉽게 인사이트를 얻을 수 있도록 하기 위해 노력했습니다. 선택한 구성 수준에 따라 프로파일링하는 메트릭이라는 라이브러리를 통합했습니다.
사용하려면 먼저 이 선택적 종속성을 추가해야 합니다:
<종속성>
<groupId>com.codahale.metrics>
<artifactId>metrics-core>
<버전>3.0.1>
>
빌더에는 프로파일러를 활성화할 수 있는 방법이 있습니다:
카우치베이스커넥션팩토리빌더 빌더 = new 카우치베이스커넥션팩토리빌더();
// 메트릭 수집 활성화
빌더.setEnableMetrics(MetricType.성능);
를 보면 MetricType 열거형에서 선택할 수 있는 값은 세 가지입니다: OFF(메트릭 수집을 해제), PERFORMANCE(성능 관련 메트릭만 수집), DEBUG(성능 메트릭을 포함한 모든 종류의 메트릭을 수집) 중에서 선택할 수 있습니다. 메트릭 라이브러리는 매우 효율적이지만 메트릭 수집은 애플리케이션에서 일부 리소스를 빼앗아간다는 점을 염두에 두세요.
기본적으로 메트릭 정보는 30초마다 콘솔에 인쇄됩니다. IDE에서 다음 테스트 코드를 실행하여 어떻게 표시되는지 확인할 수 있습니다:
카우치베이스커넥션팩토리빌더 빌더 = new 카우치베이스커넥션팩토리빌더();
빌더.setEnableMetrics(MetricType.성능);

카우치베이스커넥션팩토리 참조 =
빌더.빌드 카우치베이스 연결(배열.asList(new URI(“https://127.0.0.1:8091/pools”)), "default", “”);
카우치베이스클라이언트 클라이언트 = new 카우치베이스클라이언트(참조);

동안(true) {
클라이언트.set("foo", "bar");
스레드.수면(100);
}

이제 30초 정도 기다리면 콘솔에 다음과 같은 출력이 표시됩니다:
10/8/13 12:04:14 오후 ============================================================

- 히스토그램 ----------------------

[MEM] 읽기당 OS에서 읽은 평균 바이트 수

count = 893

최소 = 24

최대 = 24

평균 = 24.00

stddev = 0.00

중앙값 = 24.00

75% <= 24.00

95% <= 24.00

98% <= 24.00

99% <= 24.00

99.9% <= 24.00

[MEM] 쓰기당 OS에 기록되는 평균 바이트 수

count = 893

최소 = 38

최대 = 38

평균 = 38.00

stddev = 0.00

중앙값 = 38.00

75% <= 38.00

95% <= 38.00

98% <= 38.00

99% <= 38.00

99.9% <= 38.00

[MEM] 평균 와이어 작동 시간(µs)

count = 893

최소 = 179

최대 = 1730

평균 = 263.80

stddev = 75.43

중앙값 = 251.00

75% <= 280.00

95% <= 351.90

98% <= 425.36

99% <= 559.70

99.9% <= 1730.00

- 미터 ------------------------

[MEM] 요청 비율: 모두

count = 893

평균 속도 = 9.92 이벤트/초

1분 속도 = 9.85 이벤트/초

5분 속도 = 9.68 이벤트/초

15분 속도 = 9.63 이벤트/초

[MEM] 응답률: 모두(실패 + 성공 + 재시도)

count = 893

평균 속도 = 9.92 이벤트/초

1분 속도 = 9.85 이벤트/초

5분 속도 = 9.68 이벤트/초

15분 속도 = 9.63 이벤트/초

이 블로그 게시물에서는 이러한 모든 메트릭에 대해 자세히 설명하지 않으므로 보다 자세한 내용은 문서를 참조하시기 바랍니다. 한 가지 더 알려드리고 싶은 것은 메트릭 라이브러리에서도 JMX를 통해 이러한 메트릭을 노출할 수 있다는 것입니다. 출력 모드를 변경하는 시스템 속성을 설정하기만 하면 됩니다: net.spy.metrics.reporter.type=jmx. 기타 가능한 설정은 다음과 같습니다. csv 및 slf4j. 지정된 간격으로 정보를 인쇄하는 로거를 선택한 경우 다음을 설정하여 변경할 수 있습니다. net.spy.metrics.reporter.interval 를 30으로 설정합니다.
따라서 다음과 같은 줄을 넣으면 System.setProperty("net.spy.metrics.reporter.type", "jmx"); 위에 표시된 코드 앞에 (예를 들어) jConsole을 열고 애플리케이션의 MBeans 탭으로 전환할 수 있습니다. 그러면 메트릭 하위 섹션이 노출되어 로그에 표시되는 것과 동일한 메트릭이 포함되어 있습니다.

유효기간이 있는 CAS

1.2.0 이전에는 하나의 명령으로 다음과 같은 작업을 수행할 수 없었습니다. cas 업데이트와 동시에 새 만료일을 설정할 수 있습니다. 잠시 후 터치 연산은 효율적이지도, 원자적이지도 않았습니다. 이제 API는 새로운 cas() 메서드를 사용하여 만료 시간을 동시에 전달할 수 있습니다. 사용하기 쉽습니다:
클라이언트.cas("key", cas, newExpiration, value);
비동기식 변형은 1.2.1 버전부터 노출되었습니다.

속성을 통한 초기화

클러스터 IP 주소가 자주 변경되는 경우 유용하게 사용할 수 있는 기능 중 하나는 이제 카우치베이스클라이언트 객체를 호출합니다. 다음은 예시입니다:
시스템.setProperty("cbclient.nodes", "https://127.0.0.1:8091/pools");
시스템.setProperty("cbclient.bucket", "default");
시스템.setProperty("cbclient.password", "");

카우치베이스커넥션팩토리빌더 빌더 = new 카우치베이스커넥션팩토리빌더();
카우치베이스커넥션팩토리 참조 = 빌더.빌드 카우치베이스 연결();
카우치베이스클라이언트 클라이언트 = new 카우치베이스클라이언트(참조);

물론 애플리케이션 컨테이너에서 또는 시작 중에 이러한 속성을 설정할 수 있으므로 매우 유연하며 코드에 직접 연결되지 않습니다. 이러한 속성 중 하나를 설정하는 것을 잊어버리면 코드에서 다음과 같은 경고가 표시됩니다:
스레드 "main" java.lang.IllegalArgumentException에서 예외가 발생했습니다: 시스템 속성 cbclient.nodes가 설정되지 않았거나 비어 있습니다.
에서 com.couchbase.client.CouchbaseConnectionFactory.(CouchbaseConnectionFactory.java:160)
에서 com.couchbase.client.CouchbaseConnectionFactoryBuilder$2.(CouchbaseConnectionFactoryBuilder.java:318)
에서 com.couchbase.client.CouchbaseConnectionFactoryBuilder.buildCouchbaseConnection(CouchbaseConnectionFactoryBuilder.java:318)
에서 Main.main(Main.java:33)
at sun.reflect.NativeMethodAccessorImpl.invoke0(네이티브 메서드)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
에서 com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)

기타 변경 사항

위에 표시된 개선 사항 외에도 이번 릴리스에는 언제나 그렇듯이 수많은 소규모 버그 수정이 포함되어 있습니다. 다음 항목의 기본 폴링 간격은 ReplicateTo 그리고 PersistTo 로 낮아졌습니다. 10ms 를 사용하여 Couchbase Sever 2.2 릴리스에 적용된 성능 변경 사항을 고려합니다. 또한 클라이언트는 이제 CRAM-MD5` 인증 메커니즘을 서버가 지원하는 경우 자동으로 사용합니다(2.2 버전부터).
이 멋진 새 기능만으로도 지금 바로 업그레이드해야 할 충분한 이유가 될 것입니다! 예상대로 작동하지 않는 문제가 발생하면 고객 지원팀에 문의하거나 티켓을 개설해 주세요. 여기.
이 문서 공유하기
받은 편지함에서 카우치베이스 블로그 업데이트 받기
이 필드는 필수 입력 사항입니다.

Author

Posted by Michael Nitschinger, Principal Software Engineer, Couchbase

마이클 니칭어는 Couchbase의 수석 소프트웨어 엔지니어로 일하고 있습니다. 그는 JVM에서 최초의 완전 반응형 데이터베이스 드라이버 중 하나인 Couchbase Java SDK의 설계자이자 유지 관리자입니다. 또한 Couchbase Spark Connector를 작성하고 유지 관리하고 있습니다. Michael은 오픈 소스 커뮤니티에서 활발히 활동 중이며, RxJava 및 Netty와 같은 다양한 프로젝트에 기여하고 있습니다.

모든 게시물 웹사이트

댓글 하나

  1. 10월 14일: Couchbase NoSQL의 한 주 - Couchbase 블로그 4월 27, 2017에서 2:22 오후

    [...] 금주의 블로그 게시물: Couchbase Java SDK 1.2의 새로운 기능 [...]

댓글 남기기

카우치베이스 카펠라를 시작할 준비가 되셨나요?

구축 시작

개발자 포털에서 NoSQL을 살펴보고, 리소스를 찾아보고, 튜토리얼을 시작하세요.

Develop now
카펠라 무료 사용

클릭 몇 번으로 Couchbase를 직접 체험해 보세요. Capella DBaaS는 가장 쉽고 빠르게 시작할 수 있는 방법입니다.

Use free
연락하기

카우치베이스 제품에 대해 자세히 알고 싶으신가요? 저희가 도와드리겠습니다.

Contact us