わかりました、私はついに自分でデザインと生産のこのポイントに到達しました.
上位 32 ビットがミリ秒単位の Unix 時間のビット 33 から 1 に基づいている COMB_GUID を生成します。したがって、2 ミリ秒ごとに 93 ビットのランダム性があり、上位ビットのロールオーバーは 106 年ごとに発生します。COMB_GUID (またはタイプ 4 UUID) の実際の物理表現は、22 文字の文字列である 128 ビットの base64 エンコード バージョンです。
postgres に挿入する場合、完全にランダムな UUID と COMB _GUID の間の速度の比率は、COMB_GUID にとって有益なものとして保持されます。COMB_GUID は、100 万レコードのテストで、複数のテストで私のハードウェアで2 倍速くなりました。レコードには、id (22 文字)、文字列フィールド (110 文字)、倍精度、および INT が含まれます。
ElasticSearch では、インデックス作成に関して 2 つの間に識別可能な違いはありません。コンテンツが時間に関連してフィードされるため、コンテンツがチェーン内のどこかの BTREE インデックスに移動する場合、または id フィールドで事前に並べ替えて、時間に関連し、部分的にシーケンシャルになるようにする場合に備えて、COMB_GUIDS を引き続き使用します。速度が向上します。
とても興味深い。COMB_GUID を作成する Java コードは次のとおりです。
import java.util.Arrays;
import java.util.UUID;
import java.util.Base64; //Only avail in Java 8+
import java.util.Date;
import java.nio.ByteBuffer;
private ByteBuffer babuffer = ByteBuffer.allocate( (Long.SIZE/8)*2 );
private Base64.Encoder encoder = Base64.getUrlEncoder();
public String createId() {
UUID uuid = java.util.UUID.randomUUID();
return uuid2base64( uuid );
}
public String uuid2base64(UUID uuid){
Date date= new Date();
int intFor32bits;
synchronized(this){
babuffer.putLong(0,uuid.getLeastSignificantBits() );
babuffer.putLong(8,uuid.getMostSignificantBits() );
long time=date.getTime();
time=time >> 1; // makes it every 2 milliseconds
intFor32bits = (int) time; // rolls over every 106 yers + 1 month from epoch
babuffer.putInt( 0, intFor32bits);
}
//does this cause a memory leak?
return encoder.encodeToString( babuffer.array() );
}
}