빅 데이터를 이용한 색인 및 쿼리가 어렵다는 것은 누구도 의심하지 않습니다. 빅 데이터는 빠른 속도와 다양성, 방대한 양으로 여러분에게 빠르게 다가옵니다! 초당 10만 건의 업데이트와 TB 단위의 데이터를 스캔해야 한다면, 탄탄한 인덱싱이 없다면 이 작업을 실시간으로 수행할 수 없습니다! 이런 앱들을 상상해 보세요:
- 살펴본 모든 항공편과 호텔의 가격을 책정하고 기록하는 여행 앱!
- 최고의 플레이어를 위해 정확한 점수판을 표시해야 하는 바이럴 온라인 게임!
- 사기 탐지 앱은 최근 활동을 살펴보고 활성 신용 카드 거래가 합법적인 거래인지 판단해야 합니다!
대량의 데이터 수집을 처리해야 하지만 응답 시간으로 밀리초를 타협할 수 없는 쿼리에 대한 사용 사례입니다! 렌더링할 수 없는 경우 여행 일정, 스코어 보드 또는 실시간으로 사기 대응모든 베팅이 종료되었습니다! 좋아요! 불가능할 것 같지만 물어보세요: "이런 유형의 데이터를 어떻게 실시간으로 색인하고 쿼리할 수 있을까요?"
분산 데이터베이스 시스템에서의 인덱싱
분산 시스템은 두 가지 유형의 인덱싱을 제공합니다;
- 로컬 인덱스: 클러스터에서 각 노드는 로컬로 보유하고 있는 데이터를 색인합니다. 이는 빠른 인덱싱에 최적화되어 있습니다. 그러나 데이터 수집이 증가하면 로컬에서 인덱스 유지 관리가 들어오는 워크로드와 경쟁하게 되고 클러스터가 커지면(노드가 많아지면) 분산 수집이 쿼리 대기 시간에 도달하게 됩니다. 이 쿼리를 상상해 보세요: "8월 한 달간 가장 활동적인 상위 10명의 사용자 찾기“
|
1 2 3 4 5 6 7 8 9 10 |
#SQL은 다음과 같이 표시됩니다. 선택 고객_이름, 총_로그인.jan_2015 FROM 고객_버킷 어디 유형="고객_프로필" 주문 BY 총_로그인.jan_2015 DESC LIMIT 10; 쿼리에 대한 #index는 다음과 같이 표시됩니다. INDEX 켜기 고객_버킷(고객_이름, 총_로그인.jan_2015) 어디 유형="고객_프로필"; |
다음은 로컬 인덱스가 있는 클러스터에서 쿼리가 수신되는 즉시 수행되는 단계입니다:
- 어느 노드도 답을 알 수 없습니다! 따라서 Scatter는 로컬 인덱스를 사용하여 각 노드에서 로컬로 "TOP 10"을 파악해야 합니다.
- Gather는 'TOP 10'을 조정 노드로 다시 가져옵니다.
- 마지막 단계는 모든 노드의 결과를 결합하여 상위 10명의 활성 사용자를 다시 정렬하고 파악하여 결과를 클라이언트로 다시 전송하는 것입니다.
이 작업이 100개의 노드에서 수행되었고 101번째 노드를 추가했다고 가정해 보겠습니다! 이 쿼리를 실행할 때 더 빨라지는 것은 없습니다. 새 노드를 포함한 모든 노드는 여전히 동일한 작업을 수행합니다. 사실 101번째 노드는 쿼리 지연 시간을 악화시킵니다!
참고로 Couchbase Server는 로컬 인덱싱을 수행합니다. 이를 맵/보기 축소라고 하며, 몇 초의 지연 시간을 견딜 수 있는 복잡한 대화형 보고 앱 및 대시보드 앱에 매우 유용합니다. 보기에 대해 자세히 알아보기 여기.
- 글로벌 인덱스: 인덱스는 독립적으로 분할되어 노드의 데이터와 멀리 떨어져 배치됩니다. 데이터를 색인하려면 네트워크 액세스가 필요하기 때문에 변이를 따라잡기가 어려울 수 있습니다. 그러나 글로벌 인덱스는 쿼리에는 환상적으로 작동합니다. 위의 동일한 쿼리를 상상해 보세요. 이제 인덱스는 한두 개의 노드에 위치합니다(아래 예처럼 대륙별로 분할되어 있을 수도 있습니다).
|
1 2 3 4 5 6 7 8 9 10 |
쿼리에 대한 #index는 다음과 같이 표시됩니다. INDEX 켜기 고객_버킷(고객_이름, 총_로그인.jan_2015) 어디 유형="고객_프로필" AND 대륙="유럽"; INDEX 켜기 고객_버킷(고객_이름, 총_로그인.jan_2015) 어디 유형="고객_프로필" AND 대륙="America"; INDEX 켜기 고객_버킷(고객_이름, 총_로그인.jan_2015) 어디 유형="고객_프로필" AND 대륙="아시아"; |
다음은 글로벌 인덱스가 있는 클러스터에서 쿼리가 수신되는 즉시 수행되는 단계입니다:
- 이제 답을 알고 있는 글로벌 인덱스가 있는 노드가 생겼습니다! 따라서 여기서는 분산이 필요하지 않습니다! 인덱스에서 상위 로그인 횟수를 검색하기만 하면 됩니다.
- 마지막 단계는 결과를 클라이언트로 다시 전송하는 것입니다.
이전 예제의 100개 노드에서 101번째 노드가 이제 실제 작업을 수행할 수 있습니다! 쿼리 지연 시간이 훨씬 빨라졌습니다!
카우치베이스 서버에서는 인덱스 서비스를 사용하여 GSI를 클러스터 내의 별도 영역에 독립적으로 배포할 수도 있습니다. 즉, 핵심 데이터 작업(삽입/업데이트/삭제)을 수행하는 데이터 서비스 노드가 클러스터의 다른 부분에서 진행되는 인덱싱과 경쟁할 필요가 없습니다. 이 배포 토폴로지를 MDS라고 부르며, 자세한 내용은 다음과 같이 확인할 수 있습니다. 여기.
맵/축소 뷰와 GSI의 차이점 및 아키텍처에 대한 자세한 설명도 확인할 수 있습니다. 여기.
카우치베이스 서버는 이러한 방식으로 작동하는 GSI(글로벌 보조 인덱스)를 제공합니다. 카우치베이스 서버는 GSI를 위한 두 가지 스토리지 옵션, 즉 표준 GSI와 메모리 최적화 GSI를 제공합니다. 표준 GSI는 4.0부터 제공되었습니다. 그러나 메모리 최적화 GSI는 4.5에 새로 추가되었습니다. In 이 게시물의 2부다음을 수행할 수 있습니다. 자세히 알아보기 메모리 최적화 글로벌 인덱스와 그 차이점.
