複数のクライアントデータベース間でグローバルに一意である必要があるため、一部のデータをいくつかの時点でマージする必要があるため、一部のテーブルの主キーにUUIDを使用する必要があります。JavaシーケンシャルUUID
VARCHAR（36）列とjavaのバージョン4のUUIDランダムジェネレータを使用すると問題が解決しますが、UUIDが連続していないため、インデックスや挿入に関する別の問題が発生することがあります（1,000万行以上）
私は、UUIDからの最も重要なビットを現在のタイムスタンプ（これらのビットはすでにタイムスタンプを表しています）で置き換えることによって、順次でランダムなUUIDを生成しようとしています。私はこれを行うWeb上のソリューション、つまりCOMB UUIDがあることは知っていますが、不思議なことに、Java実装を見つけることができませんでした。私はこれが共通の問題だと思った。
私はここでのC＃上で、興味深い実装が見つかりました：似たようなアプローチは、何が必要だろう http://www.codeproject.com/Articles/388157/GUIDs-as-fast-primary-keys-under-multiple-database
が、私は、Javaにこれを変換する苦労を抱えているので、誰も私を助けることができれば、私は」それを感謝します。私はJavaがビッグエンディアンを常に使用し、ネイティブOSからのものではないと考えるように、ビッグエンディアン/リトルエンディアンに関する問題の大部分はと思いますか？これに対処する方法については本当にわかりません。
私の考えは基本的に同じですが、UUID.randomUUID（）を使用してUUIDを生成し、その結果のIDからSystem.currentTimeMillis（）を置き換えます。
time_low = 4*<hexOctet>
time_mid = 2*<hexOctet>
time_high_and_version = 2*<hexOctet> (1 byte for UUI algorithm version)
：私たちは6バイトと現在のタイムスタンプを表現することができると思うと、まだUUIDのタイムスタンプ部分は7.5バイトを使用していますので、私はよく分からないことの一つは、私はこのために必要があると思いバイトの量についてです編集：これまでの回答に感謝しますが、私の質問は、Java上で上記のアルゴリズムを実装し、このための別の代替手段を見つけることではないことを理解してください。私はいくつかの可能性があることを理解しています。クライアント識別子を含めて言及されているものは、これまで私が使ってきたものですが、その解決策はあまり好きではなく、このプロジェクトには当てはまりません主に2つの理由があります： - これは、クライアントの量が分かっている場合にはうまくいく可能性があります。つまり、クライアントごとにランダムなIDを生成してできるだけユニークにする必要があります。クライアントIDのプレフィックスの文字列と、順次部分のかなりの数は、50 +文字のプライマリキーを意味するものではありません。 - これは私が解決しようとしている問題を解決しません。これは、シーケンシャルプライマリキーを持つことです。異なるクライアントから同じテーブルにレコードを挿入すると、インサートはもはや連続しなくなり、パフォーマンスが低下します。
は、ご使用のアプリケーションサーバーを1つのプロセスまたは分散していますか？ –
UUIDは、索引構成表を使用する場合（つまり、クラスタ化索引がある場合）のみ、「問題」を発生させます。それを避けたい場合は、代わりにヒープ構成テーブルを使用してください。 –
それは配布されています。データベースモデルを制御できず、プライマリキーインデックスがクラスタ化されています。 – mfc