Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Imported Korean translation from sag76
Sv translation
languageen

ClustrixDB breaks each representation (primary key + table or other index) into smaller, more manageable segments called “slices”, each of which is assigned a portion of the representation’s rows. There are multiple copies of each slice, called replicas.

  • Slices are distributed throughout the cluster to facilitate evenly distributed query processing.
  • The number of slices specified for the table itself applies to the table’s data as well as to its primary key.
  • A different number of slices may be specified for each representation.
  • The number of slices for a given representation should never be less than the number of nodes in the cluster. (Tables distributed to ALLNODES are an exception.)
  • When a slice becomes too large, the Rebalancer will split the slice into new slices and distribute the original slice's rows among them. The larger a slice becomes, the more expensive it is to move or copy it across the system. 
  • A slice must physically fit in its entirety on the storage device to which it is assigned. One slice may not span multiple devices. 

To modify the number of slices for an existing table or index, follow this syntax:

ALTER TABLE tbl_name   [SLICES = n]  [ , INDEX index_name  [SLICES = n]]

Variable Definitions                 

The following global variables impact ClustrixDB slicing.

NameDescriptionDefault ValueSession Variable
hash_dist_min_slicesControls how data is sliced. If set to 0, (the default), ClustrixDB will create new representations with the number of slices equal to the number of nodes currently in the cluster. At least one slice of the table or index is placed on each node. If set to a specific integer, that number of slices will be created for each new table and index instead.0

(tick)

rebalancer_split_threshold_kbControls the maximum slice size. By default, this is set to split slices greater than 1 GB.1048576 
task_rebalancer_reprotect_interval_msDefines how frequently the Rebalancer will assess if additional slices are needed. Specify 0 to disable slice splitting.15000 

Best Practices

Generally, table and index slices should be 1-2 GB. The default size of GB is optimal for most use cases. For clusters with very large tables (over 2TB in size), increasing the max slice size to GB may be recommended.

Tables and indexes should have a minimum number of slices equal to the number of nodes, with ALLNODES tables being an exception. When adding nodes to your cluster, re-slicing of tables should be considered. Representations are not automatically resliced to match the number of nodes in the expanded cluster.

Use the following query to identify tables that contain fewer slices than the current number of nodes:

Tables with fewer slices than the total number of nodes
sql> SELECT   fd.name  `Database`,
              f.name   `Table`,
              Count(*) Slices
     FROM     system.slices
         JOIN system.representations fp USING (representation)
         JOIN system.relations f
                ON ( relation = `table` )
         JOIN system.DATABASES fd USING (db)
     GROUP BY `Database`,
              `Table`,
              fp.name
     HAVING   fd.name NOT IN ( 'system', 'clustrix_statd','clustrix_ui','_replication' )
        AND   slices < (SELECT Count(*)
                        FROM   system.membership
                        WHERE  status = 'quorum') 
        AND  (fp.name LIKE '%__PRIMARY%' OR fp.name LIKE '__base%')
     ORDER BY `Database`, `Table`, Slices;

Pre-slicing Tables 

During normal operation, relations are resliced on demand, however it can be advantageous to pre-slice tables for which large data growth is anticipated. Creating or altering a representation to have a slice count commensurate with the expected size will allow the cluster to add data to the representation at maximum speed as slice splitting will be unnecessary. For additional information, see Loading Data onto ClustrixDB.

Use the following equation to determine the optimal number of slices for a table: (expected table size + 10%) / rebalancer_split_threshold_kb)

 

Sv translation
languageko

ClustrixDB는 각 representation(기본 키 + 테이블 또는 다른 인덱스)을 "슬라이스(Slice)"라고 불리는 더 작고 관리하기 쉬운 세그먼트로 나눕니다. 각 세그먼트에는 representation의 행 일부가 할당됩니다. 각 슬라이스마다 복제본이라고 불리는 복사본이 여러 개 있습니다.

  • 슬라이스는 클러스터 전체에 분산되어 고르게 분포된 쿼리 처리를 용이하게 합니다.
  • 테이블 자체에 지정된 슬라이스 수는 테이블의 데이터와 기본 키에 적용됩니다.
  • 각 representation에 대해 다른 수의 슬라이스를 지정할 수 있습니다.
  • Representation의 슬라이스 수는 클러스터의 노드 수보다 절대 작아서는 안 됩니다. (ALLNODES로 배포된 테이블은 예외입니다)
  • 슬라이스가 너무 커지면 Rebalancer는 슬라이스를 새 슬라이스로 분할하고 원래 슬라이스의 행을 슬라이스들로 배포합니다. 슬라이스가 커질수록 시스템 전체에서 슬라이스를 이동하거나 복사하는 비용이 증가합니다. 
  • 슬라이스는 할당된 스토리지 디바이스에 전체가 물리적으로 들어갈 수 있어야 합니다. 하나의 슬라이스가 여러 디바이스로 확장되지 않을 수 있습니다.

기존 테이블이나 인덱스의 슬라이스 수를 수정하려면 다음 구문을 이용하십시오.

ALTER TABLE tbl_name   [SLICES = n]  [ , INDEX index_name  [SLICES = n]]

변수 정의                 

다음 전역 변수는 ClustrixDB 슬라이싱에 영향을 줍니다.

hash_dist_min_slices는 데이터가 슬라이스 되는 방식을 제어합니다. 0(기본값)으로 설정하면 ClustrixDB는 현재 클러스터에 있는 노드 수와 동일한 슬라이스 수의 새 representation을 만듭니다. 각 노드에는 테이블 또는 인덱스 슬라이스가 하나 이상 배치됩니다. 특정 정수로 설정하면 새 테이블과 인덱스마다 해당 개수의 슬라이스가 만들어집니다. (세션 변수로 사용할 수도 있습니다)

rebalancer_split_threshold_kb는 최대 슬라이스 크기를 제어합니다. 기본적으로 이 값은 1GB보다 큰 슬라이스를 분할하기 위해 설정됩니다.

rebalancer_split_target_slices는 슬라이스가 rebalancer_split_threshold_kb 값을 초과하고 분할이 시작될 때 생성되는 새 슬라이스의 수를 제어합니다. 기본적으로 이 값은 2로 설정됩니다.

task_rebalancer_split_interval_ms는 Rebalancer가 추가 슬라이스가 필요한지 평가하는 빈도를 정의합니다. 기본값은 30000 또는 30초입니다. 슬라이스 분할을 사용 불가능하게 하려면 0을 지정하십시오.

max_slices는 representation 당 최대 슬라이스 수를 정합니다 (기본값은 2000).

모범 사례

일반적으로 테이블 및 인덱스 슬라이스는 1~2GB여야 합니다. 대부분의 사용 사례에서는 기본 크기인 1GB가 최적입니다. 매우 큰 테이블 (크기가 2TB 이상)이 있는 클러스터의 경우 최대 슬라이스 크기를 2GB로 늘리는 것이 좋습니다.

테이블과 인덱스에는 노드 수와 동일한 최소 슬라이스 수가 있어야 하며 ALLNODES 테이블은 예외입니다. 클러스터에 노드를 추가할 때 테이블을 다시 슬라이싱하는 것을 고려해야 합니다. Representations는 확장된 클러스터의 노드 수와 일치하도록 자동으로 다시 슬라이싱 되지 않습니다.

다음 쿼리를 사용하여 현재 노드 수보다 적은 수의 슬라이스가 포함된 테이블을 확인합니다.

총 노드 수보다 적은 수의 슬라이스가 있는 테이블
sql> SELECT   fd.name  `Database`,
              f.name   `Table`,
              Count(*) Slices
     FROM     system.slices
         JOIN system.representations fp USING (representation)
         JOIN system.relations f
                ON ( relation = `table` )
         JOIN system.DATABASES fd USING (db)
     GROUP BY `Database`,
              `Table`,
              fp.name
     HAVING   fd.name NOT IN ( 'system', 'clustrix_statd','clustrix_ui','_replication' )
        AND   slices < (SELECT Count(*)
                        FROM   system.membership
                        WHERE  status = 'quorum') 
        AND  (fp.name LIKE '%__PRIMARY%' OR fp.name LIKE '__base%')
     ORDER BY `Database`, `Table`, Slices;

사전 테이블 슬라이싱 

일반 운영 중에는 필요시마다 relation을 다시 슬라이싱합니다. 그러나, 큰 데이터 증가가 예상되는 테이블은 사전에 슬라이싱하는 것이 유리할 수 있습니다. 예상되는 크기에 상응하는 슬라이스 수를 갖도록 representation을 생성하거나 변경하면 슬라이스 분할이 필요하지 않으므로 클러스터가 최대 속도로 representation에 데이터를 추가할 수 있습니다. 자세한 내용은 ClustrixDB에 데이터 로드를 참조하십시오.

다음 방정식을 사용하여 테이블의 최적 슬라이스 수를 결정하십시오: (예상 테이블 크기 + 10%) / rebalancer_split_threshold_kb