2017-10-24 30 views
0

Google Cloud Bigtable의 개발 인스턴스를 Python 클라이언트 google-cloud-happybase 패키지와 함께 사용하고 있습니다.Google Cloud BigTable 검색 속도

개발 목적으로 : - 내 테이블에는 18 열이있는 56.5k 행이 있습니다.

테이블 - 제 1 개 기둥 패밀리 각 행 요소의

- 평균 크기의 함유량이 9.5 바이트이다.

-Row 키는 평균 ~ 35 바이트

키가 균형 년 - 행

에 있습니다.

테이블에 scan() 함수를 사용할 때 각 행 키의 내용을 가져 오는 데 사용할 수있는 생성기를 얻습니다. 내가 발전기에서 내용을 읽을 때마다, 내가 예를 들어, 타이밍 일관성이없는 :

samp = table.scan(columns = ['sample_family:ContactId']) 
for i in range(56547): 
    start_time = timeit.default_timer() 
    samp.next() 
    elapsed = timeit.default_timer() - start_time 
    append_list.append(elapsed) 

년 - 중간 시간) (다음를 호출하는 것은

년 - 최대 시간 4.05e-06 초에게 있습니다 next() 호출은 .404 초이며, 0.1 초 이상 걸리는 호출이 여러 번 있습니다.

발전기의 모든 요소에 대해 next()를 호출하는 총 시간은 이상치 때문에 2.173 초이며 이상적으로는 (4.05e-06) * 56,547 ~ .229 초입니다. 정상적으로 배포되었습니다.

분명히 성능을 떨어 뜨리는 몇 가지 이상 치가 있습니다.

가 여기에있는 측정 기준에 부합하지 않는 내 질문은 왜 성능의이 유형을보고하고있다

: https://cloud.google.com/bigtable/docs/performance

내 생각 은 작업 부하가 크게 미만 < 300기가바이트 때문에, Bigtable을가 수도 큰 세트와 비교할 때 작은 데이터 세트의 성능을 최적화하는 데이터의 균형을 조정할 수 없습니다.

또한 내 개발 인스턴스가 17.1MB의 노드 1 개를 사용하고 있어도 문제가되지 않을 것이라고 생각합니다.

누군가가 내게 문제/문제에 대한 통찰력을 줄 수 있었는지 그리고 상황을 해결할 수있는 가능한 단계가 있는지 궁금합니다.

답변

0

Cloud Bigtable의 읽기 API는 스트리밍 API입니다. 스트림의 각 응답은 일련의 행입니다. 때로는 다음 응답을 기다릴 필요가 있지만 대부분의 경우 이미 메모리에있는 행을 가져옵니다. 다음은 서버 측 일괄가 응답이기 때문에,

  • 첫 번째 반응은 항상 느린 것 고려해야 할 몇 가지 추가합니다.

  • API는 순차적으로 행을 읽습니다. 요청을 병렬화하여 성능을 향상시킬 수 있습니다. Java에서는 스캔 세트에 시작/중지 키를 사용해야하는 위치를 파악할 수 있습니다. 불행히도 Table.region()은 현재 Python에서 사용할 수 없으므로이를 수정하려면 raised a bug입니다.

  • 참고 자료로 Cloud Bigtable Java 클라이언트를 작성했습니다. 추가 응답을 미리 가져 오기 위해 일부 성능 최적화를 추가했습니다.파이썬 클라이언트의 속도와 Java 클라이언트의 속도를 비교해야합니다. Java에 익숙하다면 성능을 비교하기 위해이 클라이언트와 동일한 테스트를 수행하십시오.

이 정보가 도움이되기를 바랍니다.