또한 단편화라고도 파티션은, 대용량 데이터 스토리지, 단일 노드의 저장 한계보다 큰 데이터 저장 용량을 해결하는 일반적인 솔루션, 그것은 다른 노드에 분할 데이터를 기억하는 것이 필요하고, 각각 일반적으로 단일 파티션이 될 수있다 데이터베이스는 다수의 분할을 지원할 수 있지만, 작은베이스로 이해, 분할 다중 파티션의 개념을 도입, 외부 서비스가 동시에 성능을 향상시킬 수있다.
개념은 종종 함께 언급 파티션 사본의 각 파티션은 여러 노드에 저장되도록하여 파티션 복제 일반적으로 조합, 복사된다. 각 레코드 ⼀ 파티션에 속하는 경우에도이 방법, 여전히 결함 허용 시력을 달성하기 위해 여러 가지 서로 다른 노드에 저장할 수 있습니다. 많은 기술적 또는 분할 프레임의 큐를 rocketmq 카프카 partion을로 구현 MQ 메시지 파티션 항목 하에서, 예를 들어, 반사 등; 예를 들어, SQL / NoSQL의 분할 데이터 저장 샤드 ElascticSearch 단편으로서 구현 , 포인트 테이블 등의 MySQL을.
파티션에 진행중인 여러 주요 논의,이 파티션 키 파티션 재조정 전략과 요청 라우팅 처리 메커니즘, 그리고 마지막으로 ES (ElascticSearch) 쿼리 요청 처리, 예를 들어, 파티션에서 쿼리 요청 처리 흐름을 분석 할 수 있습니다. 몇 마디의 사람은 가자 ~ 말했다
몇 가지 주요 방법으로 파티션
당신이 확산 될 데이터 요구를 많이 저장하는 경우, 어떻게 파티션을? 현재 구역은 또한 데이터에 대한 요청을 처리하는 분산하면서 파티션이 균형되지 않은 경우 그래서, 그것은 일부 파티션이 데이터 또는 쿼리를 많이 가지고 원인이됩니다, 다양한 노드에 흩어져 균형 자료이며, 그것은 종종 기울기 말했다된다. 데이터 스큐는 핫 스폿의 고부하 노드의 형성을 야기 핫스팟 랜덤 라우팅 방식은 각 파티션에 해시 데이터를 사용할 수 피할 수있다. 쿼리를 저장 한 후, 그래서 후속 라우팅 쿼리 요청을 용이하게하기 위해, 고정 된 분할에 따른 해시 키 것으로 때문인 것으로 특정 데이터 만이 아니라 임의의 데이터 저장 영역을 분할한다. 일반적인 방법은 해시 키 분할에 따라 분할 키 영역 분할에 따른다 :
분할 범위에 따른
영역 분할에있어서, 각 파티션은 시간적 로그 간단한 공통는 다른 파일로 분할되고, 따라서 데이터를 저장할 수있는 타임 스탬프 같은 데이터의 연속 기록의 기간을 지정하는 것이되는데, 이러한 디스플레이 라이브러리 서 연속 번호와 같은 데이터를 저장, 행 번호 ID에 따라 동일한 선반에 저장된 데이터. 이러한 타임 스탬프에 의한 불균일 등의 지역 데이터 일으킬 때때로 분할 범위에 따르면, 시간 및 원인 데이터 파티션보다 일정 기간이 균형되지 않은 시간 데이터의 적은 소정 기간 일 수있다.
키 해시 분할
원인 부하 불균형에 대한 데이터의 범위에 따라 분할되므로, 일반적인 응용 시나리오 (비 순차 형 데이터)를 소정의 키를 분할 인화 해시 함수를 사용하는 경우를 결정하기 위해 변형 및 ⻛ 고온의 위험을 방지한다. 좋은 해쉬 함수는 많은 언어가 내장되어 내 해시 함수 무작위로 분할하려고하지만, 일부 장면은 키에 적합한 자바의 의해 Object.hashCode (같은 파티션)과 루비 개체 # 해시하지 않을 수 있습니다 ⼀ 당신은 다른 프로세스에서 서로 다른 해시 값을 가질 수있다.
파티션은 기존 데이터 파티션의 변화가 발생할 수 있기 때문에 올바른 해시 함수로, 때로는 동일한 파티션에 분포의 특정 범위 내에서 데이터의 해시를 만들고 싶어, 당신은 일관된 해싱이 감소 할 수있다 일관된 해싱을 사용할 수 있습니다 영향의 매핑입니다.
핫 이슈
해시 분할은 모든 요청이 동일한 파티션에 충돌 한 극단적 인 경우가있을 수 있습니다 핫스팟을 줄일 수 있지만, 피할 수 없습니다. 핫 파티션 아이디어는 문제를 해결하는 것입니다 : 하나는 데이터에 대한 단축키로 다시 초점을 파티션 분할 작업이다 다시 라우팅 분산 된 여러 개의 파티션을, 핫 데이터의 뜨거운 데이터 중복 (예 : 복사) 증가가, 증가 서비스를 제공하기 위해 함께 노드를 복사합니다.
파티션 재조정
시간이 지남에 따라 데이터 파티션은 다음과 같이 변경해야합니다 :
- 당신이 부하를 처리하기 위해 더 많은 CPU를 추가 할 수 있도록 쿼리는 증가 처리량.
- 데이터 수집은 확대 ⼩ 증가, 당신은 디스크에 더 많은 RAM을 추가하고 저장할 수 있도록.
- 기계, 기계의 실패에 대한 책임을 인수하기 위해 다른 시스템의 필요성을 실패합니다.
이러한 모든 변화는 다른 시간에 대한 노드 ⼀ 모바일 노드로부터 데이터 요청이 필요합니다. 일반적으로 평형 상태에서 외부 서비스를 분할, 등화 된 데이터 후에 가능 재조정 : 프로세스 노드에 다른 시간에 대한 클러스터 노드 ⼀에서 움직임은로드 밸런싱 (reblancing) 다음과 같은 일반적인 요구 사항을 재조정이라고합니다 노드 사이의 데이터 이동은 재조정 일정 속도에만 필요합니다. (일반적으로 모듈 해시 파티션 형태로 모든 데이터의 대부분 그리고 재분할 모듈로 밸런싱, 큰 비용을 필요로 사용된다.)
파티션의 수가 고정
파티션 밸런싱 동작의 확장을 방지하기 위해, 노드는 더 분할하고, 각 노드에 할당 된 다수의 파티션을 생성 할 수 ⽐. 데이터베이스 클러스터에 10 개 노드를 실행하는 경우 예를 들어, 그래서 100 파티션이 각 노드에 할당에 대해 확대, 1000 파티션으로 ⼀ 분할에서 시작할 수 있습니다. 예를 들어, ES는 생산 환경은 일반적으로 다음 확장 작업을 용이하게하기 위해, 일정 마진을 유지하기 위해 파티션 수를 설정에 대한 권장합니다, 그래서 파편에 ES는 변경할 수 없습니다 런타임에 슬라이스를 재조정이 방법을 사용하는 것입니다. 이 경우, 파티션의 수는, 노드 사이의 단지 지식 파티션의 데이터 이동을 변경하지 않습니다, 키는 변경되지 않습니다 조닝 지정했습니다. ⼀ 유일한 변화는 노드 파티션입니다. 이러한 변화는 확대 된 개방형 네트워크는 데이터를 전송 양, 그래서 전송 중에 약간의 시간이 소요됩니다 원래 파티션은 여전히 읽기 및 쓰기 작업을 받아 들일 것, 바로이 아니다. 아래 그림과 같이 :
동적 분할
시나리오 키 범위의 경우, 고정 된 파티션을 가진 경계의 고정 된 수의 편리 불편 제공 : 오류가 경계 발생하는 경우, 모든 모든 데이터 ⼀ 파티션에서 데이터 또는 다른 파티션을 비어의 원인이 될 수 있습니다. 시계는 자동으로 파티션 경계가 편리 성가신에서 제공-구성을 다시합니다. 따라서, 키 데이터베이스 (예컨대 HBase를하고 RethinkDB)의 동적 범위는 파티션을 생성하는 파티션. 파티션 ⻓ 오면서
(HBase와의 기본값이 10기가바이트 것이다) 위에 배치 ⼩로 확대되면, 두 파티션에 대한 반 데이터의 각 파티션으로 분할된다. 데이터 량을 삭제하고 파티션이 임계 값 축소 확대 될 경우, 반대로, 상기 B 트리 유사한 인접 파티션 병합 과정과 유사 할 수있다.
⼀ 동적 파티션의 장점은 데이터의 총량 파티션의 수에 적응된다. 소량의 데이터 만하면 오버 헤드 ⼩하므로, 파티션의 소수를 충분히이고, 상기 임계 값이 초과 될 때 데이터의 확대 량 파티션 트리거링 각 파티션이 제한 ⼀ 구성 가능한 최대 값 ⼩ 확대한다면 작동.
재조정 작업 트리거, 결국에 의해 트리거해야 할 때 인공 또는 프로그램에 의해 자동으로 트리거는 무엇입니까? 이 프로그램은 자동으로 트리거 노드가 자동 재조정이 때문에 외부 환경의 일부의 구현에 미치는 영향이 될 수 있습니다 끊고 우리의 기대, 따라서, 도달하지 않을 수 있습니다, 일반적으로 검출 노드의 부하가 너무 높거나 (네트워크 하트 비트를 통해 발견) 적당한 용액 재조정 및 후속 처리를 실행 재조정하여 정비 요원, 수작업 알리기 위해 경고 할 때 자동으로 실행되는 것으로된다.
요청 라우팅 처리
当处理请求时，如何确定哪个节点执行呢？随着分区再平衡，分区对节点的分配也发生变化，为了回答这个问题，需要有⼈知晓这些变化：如果我想读或写键“foo”，需要连接哪个节点IP地址和端⼝号？这个问题本质上就是服务发现，它不仅仅体现在数据库，任何网络通信场景都有这个问题，特别是如果它的⽬标是⾼可⽤性（在多台机器上运⾏冗余配置），都需要服务发现。概括来说，请求路由处理，有以下几种处理方案：
- 允许客户联系任何节点（例如，通过循环策略的负载均衡（Round-Robin Load Balancer））。如果该节点恰巧拥有请求的分区，则它可以直接处理该请求;否则，它将请求转发到适当的节点，接收回复并传递给客户端。
- ⾸先将所有来⾃客户端的请求发送到路由层，它决定了应该处理请求的节点，并相应地转发。此路由层本身不处理任何请求；它仅负责分区的负载均衡。
- 要求客户端知道分区和节点的分配。在这种情况下，客户端可以直接连接到适当的节点，⽽不需要任何中介代理。
以上所有情况的关键问题是，做出路由决策的组件（可能是节点之一、客户端或者路由代理）如何知道分区-节点之间的映射关系。映射关系可以使固定写死在代码中，也可以是配置在配置中心中。许多分布式数据系统都依赖于⼀个独⽴的协调服务，⽐如ZooKeeper来跟踪集群元数据。 每个节点在ZooKeeper中注册⾃⼰，ZooKeeper维护分区到节点的可靠映射。 其他参与者（如路由层或分区感知客户端）可以在ZooKeeper中订阅此信息。 只要分区分配发⽣的改变，或者集群中添加或删除了⼀个节点，ZooKeeper就会通知路由层使路由信息保持最新状态。
执行查询
请求处理查询可分为两种场景，单节点查询和集群查询，前者一般是针对一类数据的查询并且该类数据存储在同一个节点上，后者是同时发给多个节点，最后再做聚合操作。集群查询也称为并行查询，通常⽤于分析的⼤规模并⾏处理（MPP, Massively parallel processing） 关系型数据库产品在
其⽀持的查询类型⽅⾯要复杂得多。⼀个典型的数据仓库查询包含多个连接，过滤，分组和聚合操作。
ES的查询处理流程
ES使用开源的Lucene作为存储引擎，它赋予ES高性能的数据检索能力，但Lucene仅仅是一个单机索引库。ES基于Lucene进行分布式封装，以支持集群管理、分布式查询、聚合分析等功能。
从使用的直观感受看，ES查询分为2个阶段，query和fetch阶段。在query阶段会从所有的shard上读取相关document的docId及相关的排序字段值，并最终在coordinating节点上收集所有的结果数进入一个全局的排序列表后，然后获取根据from+size指定page页的数据，获取这些docId后再构建一个multi-get请求发送相关的shard上从_source里面获取需要加载的数据，最终再返回给client端。
query阶段：
fetch阶段：
所有的搜索系统一般都是两阶段查询，第一阶段查询到匹配的DocID，第二阶段再查询DocID对应的完整文档，这种在Elasticsearch中称为query_then_fetch，还有一种是一阶段查询的时候就返回完整Doc，在Elasticsearch中称作query_and_fetch，一般第二种适用于只需要查询一个Shard的请求。由上图可知，ES允许客户联系任何节点，如果该节点恰巧拥有请求的分区，则它可以直接处理该请求;否则，它将请求转发到适当的节点，接收回复然后聚合并传递最终的聚合结果给客户端。
小结
大数据量场景在单台机器上存储和处理不再可⾏，则分区⼗分必要。分区的⽬标是在多台机器上均匀分布数据和查询负载，避免出现热点（负载不成⽐例的节点）。这需要选择适合于您的数据的分区⽅案，并在将节点添加到集群或从集群删除时进⾏再分区。
常见的键值分区方式有按照范围分区、按照键的散列分区两种。请求的处理机制一般有客户端处理、代理处理、服务节点处理3种方式，不管哪种方式，都需要其知道分区-节点之间的映射关系，一般映射关系是保存在配置中心上，比如zookeeper。
推荐阅读
