Skip to end of metadata
Go to start of metadata
Icon

This section describes some of the sophisticated controls that are available for managing data distribution. The default behavior for replicas and distribution is sufficient for many workloads.

参照 

By default, ClustrixDB uses a hash-based algorithm to distribute data. In addition, ClustrixDB enables you to control data placement in the cluster. 以下の章では、デフォルトのやりかたを説明し、データ分散を設定する方法を教えます。

Icon

The following advice is general: Always consider your application's specific workload when choosing optimization strategies.

このトピックの例は、以下のテーブルに基づいています。

デフォルトのデータ分散

By default, ClustrixDB uses all the columns of an index to distribute data. ハッシュ値は (user_id, posted_on) について計算されます。両方の列上の正確な制約を指定するクエリについて、データベースはクラスタ内のどのノードを使用するかを決定します。

しかし、以下のクエリを考えてみましょう:

There is no exact (equality) constraint on the posted_on column. クラスタはそのような列に対して全てのありえる場所を検索しなければなりません。その結果、クエリのパフォーマンスとスケーラビリティは低くなります。クラスタはまだインデックスの順番を利用しそれぞれのノードで制限を適用することができますが、クエリは特定のユーザについて何もデータを持たないノードに行くかも知れません。

しかしながら、もしクエリが複数のユーザ間で共通のプロパティをもつ投稿を見つける必要がある場合には、複数のノードでクエリを評価することは都合がいいかも知れません。そのようなクエリは複数のノードを並行して使用し、とても計算を高速化します。Even if a query needs to go to multiple nodes, the DBMS continues to optimize, pushing the limit down to each node to reduce the cost of the overall query evaluation.

データ分散の設定

データ分散を制御するために、複数の行キーのどのキーをデータ配置のために使われるかを定義することができ、インデックス単位分散に使われるキーの数を指定することができます。データ分散を設定するには、DISTRIBUTE節を指定します。For example, to limit the index hash to the first column, issue the following command:

 

インデックスの両方の行を使う代わりに、クラスタは最初の行だけを使います。This layout places all posts by a specific user on one node, so the cluster needs to consult only the node that holds the data of interest.
データ分散のためにハッシュ化された列は隣接しているに違いありません; つまり、列をスキップすることはできません。

例えば、三つの列のインデックス(a,b,c)について、bをスキップして(a,c)を分散することはできません。The following are valid: ( a ), ( a,b ), or ( a,b,c ).
 

インデックスが極度に偏っていれば、インデックスの分散も同じように偏っているでしょう。To even out the distribution, using a DISTRIBUTE value that is larger than the number of columns in the index will append additional columns from the primary key. 例えば:


This approach causes the distribution for this key to be based on the key + the first column of the primary key. If the primary key is a compound key, you can expand the distribution to include more columns. In this example, the hash value computed for distribution will be based on (user_id, posted_on, post_id). 

Icon

Instead of using the DISTRIBUTE clause as noted in the previous example to include the primary key in the distribution, you can use the global variable distribute_include_primary_key. That global is used as the default when DISTRIBUTE is not specified. Set the variable to true (default is false) to consistently include the primary key in the distribution.

プライマリキーとインデックスの分配の修正

To modify the distribution or slices of the primary key after a table has been created, issue the ALTER TABLE command as follows:

For a compound (multi-column) primary key, the distribution count cannot exceed the number of columns that compose the primary key.


テーブルが作成された後でインデックスの分配を変更するには、以下のようにALTER TABLEコマンドを発行します:

ユーザがインデックスの分配を変更する時に、デフォルトでシステムは多数の小さなスライスを作成するかも知れません。SLICES 引数はシステムのデフォルトの挙動を上書きします。

スライスの最適な数を決定するには、以下のようにsystem.table_sizeとsystem.index_sizeを調べてください:

Size カラムはインデックスのバイト数です。When calculating optimum slice counts for tables and indexes, strive for slices of approximately 1GB or less if you expect the table to grow significantly. Ensure that tables and indexes have a minimum of three slices.

Modifying the Number of Replicas for a Table

When creating a table, you can explicitly specify the number of replicas:

If no value is specified for the number of replicas, Clustrix creates tables with a default number of replicas = 2. The default number of replicas can be configured via the global variable default_replicas. Once a table has been created, you can use an ALTER statement to modify the number of replicas:

This will automatically copy your data across slices and nodes so that the desired number of replicas are created as part of the DDL operation. You can view the number of replicas that a table has via SHOW CREATE TABLE.

Lazy Protect

You can also create replicas in an asynchronous fashion by using the ALTER TABLE command with the LAZY PROTECT option. 

Example of LAZY PROTECT

Lazy protect allows the SQL command to return instantly, and the reprotection to be performed in the background by the Rebalancer. For larger tables, this could result in a longer reprotection time, but less immediate impact to the database. If no value for the number replicas is supplied, the default value will be applied. 

Icon

While the protection process is in progress, there may be warnings in the logs about ALERT PROTECTION_LOST WARNING. These will no longer appear once the reprotect process is complete.

Icon

To optimize performance of bulk data load:

  1. Create tables with REPLICAS = 1 (and no secondary indexes)
  2. Perform the data import
  3. Create secondary indexes
  4. ALTER TABLE <table_name> LAZY PROTECT REPLICAS = <number of desired replicas>

To track progress of a lazy protect operation, see Managing the Rebalancer.

Replicas = Allnodes

This feature was introduced in v6.0 and offers the option to specify that every node should maintain a full copy of a table.

Recommended Use of Replicas = Allnodes

Replicas = Allnodes is best used for tables that are:

  • Relatively small
  • Written to infrequently (e.g. metadata lookup tables)
  • Used frequently in joins to other, larger tables 

Since a copy of an Allnodes table is maintained on every node, writes are expensive. The result of Replicas = Allnodes is that Clustrix is able to utilize local copies of an allnodes table to minimize the cost of joining to larger tables. 

Caveats of Replicas = Allnodes

Replicas = Allnodes should not be used for:

  • Tables that take frequent writes
  • Partitioned tables
  • Operations that also specify LAZY PROTECT

Sample Usage of Replicas = Allnodes

例:

 

 

  • No labels
TOP
inserted by FC2 system