Child pages
  • Loading Data Onto ClustrixDB

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Imported Korean Translation
Sv translation

Table of Contents

The most common methods of loading data onto ClustrixDB are

  1. Take a mysqldump from an existing MySQL instance, then import the dump with clustrix_import. This is the fastest way to get data onto ClustrixDB.
  2. Use LOAD DATA INFILE to import CSV files. ClustrixDB performs best when data is pre-sliced and the import can be done in parallel.

This is often followed by setting up replication with ClustrixDB as a slave from the MySQL instance. Once the ClustrixDB Replication Slave is caught up, then the application can be cut over to ClustrixDB and the MySQL instance retired.  

mysqldump and clustrix_import

Using mysqldump 

Ensure a consistent transactional backup suitable for setting up replication

When performing the mysqldump from your MySQL server, ensure you provide the proper arguments, particularly for single-transaction and master-data. Note that since MyISAM tables are not transactional, data for those tables can continue to change while a mysqldump runs. To get a consistent dump of MyISAM tables, it’s necessary to disable writes entirely or lock all tables during the dump. Since this is generally not feasible on a production cluster, it may be necessary to dump from an existing slave instead, where replication to that slave can be stopped for the duration of the dump. 

Ensure the dump completes successfully

To avoid having mysqldump interrupted by a network connection reset or similar issue, Clustrix Support recommends using the screen utility to run the mysqldump. If you do any amount of serious work at the command line, screen is indispensable. Regardless of whether you use screen or some other method to invoke and monitor, always check the tail of the dump file to make sure the dump completed successfully. You should see some session variable sets. If you see the middle of a multi-row insert instead, your dump was interrupted, or the file was otherwise truncated. Either way, you’re unlikely to be pleased with the results of restoring such a file. 

Don't bother with the `mysql` database (users and permissions should be copied with clustrix_clone_users)

Avoid dumping internal MySQL databases such as `mysql`, which are of no use to ClustrixDB. ClustrixDB will dutifully create a `mysql` database and restore the contents, but they will have no effect on the functioning of the system, as would be expected if the dump were restored to a MySQL server. In particular, users and permissions cannot be propagated this way. See Migrating User Permissions for information on how to use clustrix_clone_users.


Standard MySQL practice is to import mysqldump by redirecting to the mysql client on the shell command line, or using the source command within the mysql client. Note that this method can result in very long import times as it fails to take advantage of ClustrixDB parallel processing.  

clustrix_import is a Python script that reads mysqldump output and loads the data into a ClustrixDB cluster in a multi-threaded fashion. It can be run directly on the cluster (in which case the dump should be staged in the /clustrix directory, which has plenty of scratch space), or from any Linux client with Python 2.4 and MySQLdb (MySQL driver for Python) 1.2.1. 

The tool should already be available on your cluster in /opt/clustrix/bin. If it not available there, please contact Clustrix Support to get the appropriate version.  Note that it may be necessary to add execute permissions, i.e. "chmod a+x clustrix_import).

clustrix_import first connects to the cluster at the given address and determines the number and IP address of all nodes. It then spins up 8 (default) threads per node and distributes the inserts across these threads. To obtain optimal slicing, it creates tables with a large slice count (3x number of nodes in the cluster), and then reslices smaller tables back to a smaller slice count. It also checks for poor distribution, where an index is dominated by a single value, and fixes this. See Distribution Key Imbalances in Data Distribution.  

In addition to parallelism and optimal data distribution, clustrix_import has a few “handrails”, such as checking whether a binlog exists, since in most cases you would not want all the statements associated with an import going into a replication stream, particularly the DROPs. Also, clustrix_import has a locking mechanism which prevents multiple instances of clustrix_import from running, since a single instance will already fully utilize cluster resources. (Additional instances, if allowed, could reduce overall throughput or be destabilizing.) 

For additional information, please see clustrix_import.

Loading Data Without clustrix_import

If clustrix_import cannot be used to import your data, you can take some proactive measures to ensure efficient data population. While the Rebalancer can ultimately rectify just about any problem created during initial data load, poor slicing and distribution can result in much longer import time, and it may take quite some time for the Rebalancer to achieve optimal data distribution.

Pre-slicing tables
Pre-slicing tables
Pre-slicing Tables

number of slices = number of nodes

When populating large tables (say 10GB or larger) it is advantageous to set the table slice count when the table is created and before loading data. This avoids the problem of "racing the Rebalancer", wherein the Rebalancer recognizes that the table needs more slices and begins the splitting process while still actively loading data. This results in longer data load time. If you can estimate the size of the data you are importing (potentially by importing some number of rows and checking the size in system.table_sizes), a good rule of thumb is a little more than 1 slice per 1GB. Generally, you want at least one slice per node for optimal load distribution. Setting the global variable hash_dist_min_slices to the number of nodes will achieve the same result. 

To set slice count at table creation time, simply append SLICES=N to the end of your CREATE statement. You can also reslice the table with ALTER TABLE foo SLICES=N. Note that in both cases, the slicing for the base representation and all indexes are set to N.

Pre-slicing for tables > 100GB

For very large tables (larger than 100GB), you may wish to independently set the slice count for the base/primary representation (which contains all columns of each row) and the indexes (which will contain the columns included in the index, as well as the column(s) of the primary key).  Generally, indexes will require fewer slices than the base representation, since the tuples are much narrower; how many fewer slices are required depends on how wide the full table is (particularly how many varchar or blob columns), and whether an index includes such a wide column.  Instead of estimating based on column count/size for indexes, you may also load a small but representative portion of your data into ClustrixDB, and then use the system.index_sizes table to ascertain the relative sizes of the base representation and indices. 
You can set slicing for individual indexes by including SLICES=N within the index definition itself. Place the SLICES = keyword before the comma that separates multiple indexes or before the closing parenthesis of the last index.

 PRIMARY KEY (`id`),
  KEY `index_bids_on_user_id` (`user_id`) SLICES=12,
  KEY `index_bids_on_timestamp` (`timestamp`) SLICES=24,
  KEY `index_bids_on_auction_id` (`auction_id`) SLICES=12
) SLICES=36;


Note that slicing specified after the closing parenthesis applies to the base representation of the table as well as to any and all indices for which explicit slicing was not specified.

See the information on slices for further information.

Anticipating table growth

In addition to the guidelines above, consider also how much your table is expected to grow over time. You may wish to slice your tables into 0.5GB slices if you anticipate rapid table growth.

Parallelize Data Load

Aside from specifying slicing and distribution, the main factor in import speed is the degree of parallelism. A single-threaded import process fails to take proper advantage of the ClustrixDB parallel architecture, and may run even more slowly than on a MySQL instance. Consider how the data load process up could potentially be divided to increase parallelism. For example:

  • For LOAD DATA INFILEs, you can split files into smaller chunks and run them in parallel.
  • If your application loads data into the database directly, consider whether this data load can be performed in a multi-threaded fashion, with each thread connecting a different session (via a load balancer in order to distribute these front-end connections across the cluster nodes).  

Use Multi-Row Inserts

Where possible, aggregate single insert statements into larger multi-row statements. ClustrixDB handles these multi-row statements more efficiently, particularly since it reduces the per-row transactional overhead. Combining parallelism with multi-row inserts should provide optimal data load performance. (This is the same thing clustrix_import does).


Sv translation

Table of Contents

ClustrixDB에 데이터를 로드하는 가장 일반적인 방법은 다음과 같습니다.

  1. 기존 MySQL 인스턴스에서 mysqldump를 받아서 clustrix_import를 사용해서 덤프를 가져옵니다. ClustrixDB에 데이터를 로드하는 가장 빠른 방법입니다.
  2. LOAD DATA INFILE을 사용하여 CSV 파일을 가져옵니다. ClustrixDB는 데이터가 미리 슬라이스되고 가져오기가 병렬로 수행될 때 가장 빠르게 수행됩니다.

이 작업 이후 ClustrixDB를 슬레이브로 사용하여 MySQL 인스턴스 복제를 설정합니다. ClustrixDB 복제 슬레이브(Replication Slave)가 동기화를 마치면, 응용 프로그램은 ClustrixDB로 넘기고 MySQL 인스턴스는 서비스 종료하게 됩니다.

mysqldump 및 clustrix_import

mysqldump 사용

복제 구성에 적합한 일관된 트랜잭션 백업을 보장합니다

MySQL 서버에서 mysqldump를 실행할 때 특히 단일 트랜잭션 및 마스터 데이터에 대해 적절한 인수를 지정하십시오. MyISAM 테이블은 트랜잭션을 지원하지 않으므로 mysqldump를 실행하는 동안 이 테이블의 데이터는 계속해서 변경될 수 있습니다. MyISAM 테이블을 일관성 있게 덤프하려면 덤프 중에 쓰기를 완전히 비활성화하거나 모든 테이블에 잠금을 걸어야 합니다. 일반적으로 프로덕션 클러스터에서 이렇게 하는 것이 불가능하기 때문에 대신 기존 슬레이브에서 덤프를 할 필요가 있습니다. 해당 슬레이브로의 복제는 덤프하는 동안 잠시 중단할 수 있습니다.

덤프가 성공적으로 완료되었는지 확인합니다

Clustrix 지원팀은 네트워크 연결 재설정 또는 유사한 문제로 mysqldump가 중단되지 않도록 screen 유틸리티를 사용하여 mysqldump를 실행하는 것을 권장합니다. 커맨드 라인에서 중요한 작업을 수행하는 경우 screen이 반드시 필요합니다. 작업을 호출하고 모니터링하기 위해 screen 또는 다른 방법을 사용하는지 여부에 관계없이 항상 덤프 파일 끝을 확인해서 덤프가 성공적으로 완료되었는지 확인하십시오. 세션 변수 집합이 표시되어야 합니다. 대신 다중 행 삽입이 표시된 경우에는 덤프가 중단되었거나 파일이 잘린 것입니다. 어떤 경우든 해당 파일을 복원하면 원하는 결과를 얻을 수 없습니다.

`mysql` 데이터베이스는 신경쓸 필요가 없습니다 (하지만, 사용자 및 권한은 clustrix_clone_users로 복사해야 합니다)

‘mysql’과 같은 내부 MySQL 데이터베이스를 덤프하지 마십시오. 이것은 ClustrixDB에서 사용되지 않습니다. ClustrixDB는 `mysql` 데이터베이스를 생성하고 내용을 복원하지만, 시스템의 기능에는 아무런 영향을 주지 않습니다. 특히, 사용자 및 권한은 이 방법으로 가져올 수 없습니다. clustrix_clone_users 사용 방법은 "사용자 권한 마이그레이션"을 참조하십시오.


표준 MySQL에서는 shell 명령줄에서 mysql 클라이언트로 리디렉션하거나 mysql 클라이언에서 source 명령을 사용하여 mysqldump를 가져옵니다. 이 방법은 ClustrixDB의 병렬 처리를 활용할 수 없기 때문에 가져오기 시간이 매우 길어질 수 있습니다.

clustrix_import은 mysqldump 출력을 읽어서 멀티 스레드 방식으로 ClustrixDB 클러스터에 데이터를 로드하는 Python 스크립트입니다. 이 스크립트는 클러스터에서(이 경우 덤프는 여유 공간이 많은 /clustrix 디렉토리에 있어야 합니다) 직접 실행하거나 Python 2.4 및 MySQLdb (MySQL driver for Python) 1.2.1이 설치된 Linux 클라이언트에서 실행할 수 있습니다.

이 툴은 클러스터 노드의 /opt/clustrix/bin에 이미 있어야 합니다. 해당 디렉토리에 없는 경우에는 Clustrix Support에 문의하여 적절한 버전을 받으십시오. 실행 권한(예: "chmod a+x clustrix_import")을 추가해야 하는 경우 있습니다.

clustrix_import는 먼저 지정된 주소의 클러스터에 연결하여 모든 노드의 수와 IP 주소를 결정합니다. 그런 다음 노드 당 8개의(기본값) 스레드를 활성화하고 각 스레드에 삽입(insert) 작업을 분배합니다. 최적의 슬라이싱을 위해 큰 슬라이스 수(3x 클러스터의 노드 수)를 가진 테이블을 먼저 생성한 다음 작은 테이블은 다시 더 작은 슬라이스 수로 재슬라이싱(reslicing)합니다. 또한 clustrix_import는 데이터 분산이 고르게 되었는지 확인(인덱스에 단일값이 지배적인 경우 고르게 분산되지 않을 수 있습니다)하고 이를 수정합니다. 데이터 분산에서 배포 키 불균형을 참조하십시오.

병렬 처리 및 최적의 데이터 분산 외에 clustrix_import에는 binlog가 존재하는지 여부를 확인하는 것과 같은 몇 가지 안전장치가 있습니다. 대부분의 경우 데이터 가져오기와 관련된 모든 문(statements)에서 특히 DROP과 같은 명령이 복제 스트림으로 들어가는 것을 원하지 않을 것입니다. 또한 clustrix_import에는 단일 인스턴스가 클러스터 자원을 이미 충분히 활용하기 때문에 clustrix_import의 여러 인스턴스가 동시에 실행되는 것을 방지하는 잠금 메커니즘이 있습니다. 만약에 추가 인스턴스가 허용되는 경우 전체 처리량이 감소하거나 불안정해질 수 있습니다.

자세한 내용은 clustrix_import를 참조하십시오.

clustrix_import을 사용하지 않고 데이터 로드

clustrix_import를 사용하여 데이터를 가져올 수 없는 경우 효과적인 데이터 로딩을 보장하기 위해 사전 대책을 강구할 수 있습니다. Rebalancer는 초기 데이터 로드 중에 발생하는 문제를 궁극적으로 바로 잡을 수 있지만 슬라이스 및 분산이 제대로 되지 않은 경우 데이터 가져오기 시간이 훨씬 길어지고 Rebalancer가 최적의 데이터 분산을 수행하는데 상당한 시간이 걸릴 수 있습니다.

Pre-slicing tables
Pre-slicing tables
사전 테이블 슬라이싱(pre-slicing table)

슬라이스 수 = 노드 수

10GB 이상의 큰 테이블에 데이터를 채우는 경우 테이블 생성시와 데이터 로딩 테이블 슬라이스 수를 설정하는 것이 좋습니다. 이렇게 하면 "Rebalancer 경합" 문제를 피할 수 있으며 그 시점에 Rebalancer는 테이블에 슬라이스가 더 필요하다는 것을 인지하고 데이터를 활발히 로딩하면서 분할(split) 프로세스를 시작합니다. 이로 인해 데이터 로딩 시간이 길어집니다. 가져올 데이터의 크기를 예측할 수 있는 경우 (몇 개의 행을 가져온 뒤 system.table_sizes에서 크기를 확인함으로써) 1GB 당 1개의 슬라이를 설정하면 좋습니다. 일반적으로 최적의 부하 분산을 위해 각 노드에 적어도 하나의 슬라이스가 필요합니다. 전역 변수 hash_dist_min_slices에 노드 수를 설정하면 동일한 결과를 얻을 수 있습니다.

테이블을 생성할 때 슬라이스 수를 설정하려면 CREATE 문 끝에 SLICES = N을 추가하십시오. 또한 ALTER TABLE foo SLICES = N을 사용하여 테이블을 다시 분할할 수도 있습니다. 두 경우 모두 기본 representation과 모든 인덱스의 슬라이스가 N으로 설정되어 있다는 점에 유의하십시오.

100GB 이상의 테이블 사전 슬라이싱

100GB 이상의 매우 큰 테이블의 경우 각 행의 모든 컬럼을 포함하는 base/primary representation과 기본 키의 컬럼뿐만 아니라 인덱스에 포함된 컬럼을 포함하는 인덱스에 대해 슬라이스 수를 개별적으로 설정할 수 있습니다. 일반적으로 인덱스는 튜플이 훨씬 좁기 때문에 base representation보다 슬라이스를 덜 필요로 합니다. 즉, 얼마나 적은 수의 슬라이스가 필요한지는 전체 테이블의 넓이(특히 varchar 또는 blob 열의 수)와 인덱스에 그러한 넒은 컬럼이 포함되는지에 따라 달라집니다. 인덱스의 열 개수 및 크기를 기반으로 예측하는 대신 데이터의 작지만 대표적인 부분을 ClustrixDB로 로드한 다음 system.index_sizes 테이블을 사용하여 base representation과 인덱스의 상대적 크기를 확인할 수 있습니다.
SLICE=N을 인덱스 정의 자체에 포함시켜 개별 인덱스에 대한 슬라이스를 설정할 수 있습니다. 여러 인덱스를 구분하는 콤마 앞에 또는 마지막 인덱스의 닫기 괄호 앞에 SLICE=키워드를 두십시오.

KEY `index_bids_on_user_id` (`user_id`) SLICES=12,
KEY `index_bids_on_timestamp` (`timestamp`) SLICES=24,
KEY `index_bids_on_auction_id` (`auction_id`) SLICES=12
) SLICES=36;

닫기 괄호 다음에 지정된 슬라이스는 명시적으로 슬라이스가 지정되지 않은 모든 인덱스뿐만 아니라 테이블의 base representation에도 적용됩니다.

자세한 내용은 슬라이스에 대한 정보를 참조하십시오.

테이블 증가 예측

위의 가이드라인 외에 시간이 경과함에 따라 테이블이 얼마나 커질 것인지도 고려해야 합니다. 빠른 테이블 증가가 예상되는 경우 테이블을 0.5GB 슬라이스로 분산해야 할 수 있습니다.

데이터 로드 병렬화

슬라이스와 분산을 지정하는 것 외에도 가져오기 속도에 영향을 주는 주요소는 병렬 처리 수준입니다. 단일 스레드 가져오기 프로세스는 ClustrixDB의 병렬 아키텍처를 제대로 활용하지 못하고, MySQL 인스턴스보다 더 느리게 실행될 수 있습니다. 패러렐리즘(parallelism)을 늘리기 위해 데이터 로드 프로세스를 어떻게 분할할지 방법을 고려하십시오. 예를 들면:

  • LOAD DATA INFILEs의 경우 파일을 더 작은 단위로 분할하여 병렬로 실행할 수 있습니다.
  • 응용 프로그램이 데이터베이스에 직접 데이터를 로드하는 경우 각 스레드가 다른 세션에 연결(프론트 엔드 커넥션을 클러스터 노드 전체에 분산하는 로드 밸런서를 통해)하여 멀티 스레드로 데이터 로드가 수행될 수 있는지 고려하십시오.

다중 행 삽입(insert) 사용

가능하면 단일 삽입문을 더 큰 다중 행 문으로 합치십시오. ClustrixDB는 이러한 다중 행 문을 보다 효율적으로 처리합니다. 행 단위의 트랜잭션 오버 헤드가 감소하기 때문입니다. 병렬 처리와 다중 행 삽입을 결합하여 최적의 데이터 로드 성능을 얻을 수 있습니다. 이것은 clustrix_import이 실행하는 방법과 동일합니다.