6

非シャード DB では、自動インクリメントを使用して一意の ID を生成し、特定の行を参照できます。

DB を 12 個のシャードに分割したいと考えています。特定のシャードに挿入すると、自動インクリメント ID が一意ではなくなりました。

この問題に対処する際に誰かの経験を聞きたいです。

4

5 に答える 5

11

いくつかのアプローチ

1) 各シャードに独自の ID を与え、複合キーを使用する

2) 各シャードに独自の ID を与え、各シャードに ID 範囲を設定します

3) グローバルに一意の ID - GUID を使用する

于 2009-04-25T12:41:14.250 に答える
3

この種の問題に対して私が使用した2つのアプローチ:

  • GUID: 実装は簡単ですが、より大きなテーブルとインデックスを作成します。
  • ID ドメイン: 私が作った用語ですが、基本的には整数型の 32 (または 64) ビットを 2 つの部分に分割することを意味し、上の部分がドメインを表します。ドメインに使用するビット数は、サポートするドメインの数と、単一のドメインで導入されると予想されるレコードの数によって異なります。このアプローチでは、各シャードにドメインを割り当てます。欠点は、DB (私が知っている) がこのアプローチを直接サポートしていないことです。ID 割り当てを自分でコーディングする必要があります。
于 2009-04-25T12:48:01.720 に答える
1

1) 2 行 (1 行は ID を示し、2 行目はデータベース ID を示します)

2) ガイドを使用する

于 2009-04-25T12:43:21.107 に答える
0

私も同じジレンマを抱えています。私はredisソリューションを使用すると思います。redis-cloud.comのようなサービスを使用して一意の ID を生成します。そのため、シャード テーブルに挿入されたすべてのデータに対して引き続き bigint を使用できます。IT はシーケンシャルであるため、ページ分割は発生しません。さらに、ページングが非常に簡単になりました。URL で GUID を使用したくなかったので、IT はフレンドリ URL の問題を解決してくれました。さらに、Redis クラウドはスケーラブルなソリューションであり、非常に信頼性が高く、自動フェイルオーバーを備えています。

データを分割する範囲を決める必要はありません。主キーに MD5 ハッシュを使用して、シャード間でデータを均等に分割します。HA については、簡単なポイント イン タイム バックアップ/復元とレプリケーションのために Amazon RDS を使用することにしました。

Flickr も同じ手法を使用していると思いますが、奇数用と偶数用の 2 つのジェネレーターがあります。

于 2012-10-28T06:31:05.673 に答える