1

MySQL テーブルがあるとします。

CREATE TABLE tweets (
tweet_id INT NOT NULL AUTO_INCREMENT,
author_id INT NOT NULL,
text CHAR(140) NOT NULL,
PRIMARY KEY (tweet_id)
)
PARTITION BY HASH(tweet_id)
PARTITIONS 12;

すべてが良いです。テーブルは、単一のサーバー (Server1) 上にあります。しかし、最終的にはスケールアウトしたいと思うかもしれません。そこで、テーブルを分割して、12 個のパーティションのうち 6 個を新しいサーバー (Server2) に移動したいと考えています。

私が欲しい：

  • 奇数番号のツイートを含む Server1: パーティション 1、3、5、7、9、11
  • Server2 に偶数番号のツイートを含める: パーティション 2、4、6、8、10、0

1) これらのパーティションを Server1 から Server2 に移動する最善の方法は何ですか? 自動インクリメントの tweet_id の値が移行中に変更されないことを確認する必要があります。

2) 2 つのサーバーができたので、2 つのサーバーによって生成された自動インクリメントの tweet_id が同じ値でないことを確認するにはどうすればよいですか? また、各パーティションの tweet_id が一貫していることを確認する必要もあります。つまり、パーティション k では、すべての tweet_id の modulo 12 が k に等しくなります。

3) 理想的には、このスケールアウト プロセスを継続したいと考えています。そのため、後で 3 番目のサーバー (Server3) を追加したいと思います。各サーバーに 4 つのパーティションがあるように、パーティションのバランスを取り直したいと思います。繰り返しますが、3 つのサーバーによって生成された自動インクリメントの tweet_id が明確であり、12 を法とする tweet_id が各パーティション内で一貫していることを確認するにはどうすればよいですか?

4

2 に答える 2

2

これらの問題を処理するdbShardsを確認することをお勧めします。自動インクリメントは、すべてのシャードで一意の値でサポートされており、モジュラスを使用して、キーを物理シャードに直接結び付けるのではなく、仮想シャードにマップできます。これにより、新しいシャードを簡単に追加できます。詳細については、http：//www.dbshards.com/dbshards/をご覧ください。

よろしく、

アンディ。

于 2010-08-27T15:11:01.570 に答える
2

まず、AUTO_INCREMENTforを使用しないことをお勧めしtweet_idます。Twitter API は、一意であることがすでに保証されているツイートの ID を提供します。必要に応じて、後で API を介してツイートを参照するためにこれを使用することもできます。ただし、すでに多くのデータが収集されている場合は、それでは遅すぎるように思えます。

auto_increment_offsetとauto_increment_incrementシステム変数を見てください。これらを使用して、自動インクリメント ID が互いに競合しないようにすることができます。基本的に、auto_increment_offset既存のすべての ID よりも大きい番号に設定する必要がありますが、2 番目のサーバーでは 1 つ大きい番号に設定します。次に、auto_increment_increment2 に設定します。これにより、1 つのサーバーがすべての奇数 ID を生成し、もう 1 つのサーバーがすべて偶数の ID を生成するようになります。スケールアップを続けるには、これらの値を適宜調整してください。

一般的に言えば、MySQL のパーティション機能はスケールアウト用に設計されていません。パーティション全体を調べる必要がある場合、アプリケーションは複数のサーバーにクエリを実行するロジックを処理する必要があります。

データを分割する最善の方法は、各サーバーに配置するツイート ID の範囲を選択することです。あなたのケースでは、ツイート ID の前半程度を取得してサーバー 2 に配置することはおそらく理にかなっています。サーバー 1 は、サーバー 2 (および新しいアプリケーションロジック) の準備が整うまで稼働し続けることができます)。

于 2010-08-24T20:04:00.290 に答える