3

次のように machineId を操作して ObjectId をハックしたいと思います。

         <timestamp> <machineId> <processId> <inc>
UserId   XXXXXXXX    XXXX01      XXXX        XXXXXX
OrderId  XXXXXXXX    XXXX02      XXXX        XXXXXX
CardId   XXXXXXXX    XXXX03      XXXX        XXXXXX
...

基本的な考え方は、1 バイトの machineId を使用してオブジェクト タイプを区別することです。私の質問は、そうするときに問題はありますか (一意性とシャーディングを考慮して)?

--- 12月9日更新 ---

仕様と実装の違いにより、bson Java 実装が 4 バイトの inc フィールドを使用するのはなぜですか? 、ソリューションを次のスタイルに少し変更します。

         <timestamp> <machineId> <processId> <inc>
UserId   XXXXXXXX    XXXX        XXXX        01XXXXXX
OrderId  XXXXXXXX    XXXX        XXXX        02XXXXXX
CardId   XXXXXXXX    XXXX        XXXX        03XXXXXX
...
4

2 に答える 2

2

マシン ID の 2 バイトが展開に対して十分に一意であると仮定すると、それで問題ありません。ナイスアイデア！

于 2012-12-07T19:29:30.560 に答える
1

仕様に違反しておらず、ObjectID が正しい形式である限り、これを実行できない理由はなく、もちろんスペースを節約できます。

ただし、いくつかの注意事項：

まず、ドライバーのコードをオーバーロードし、ObjectID の生成方法を変更するなどしてこれを行う場合、変更された ObjectID をそのまま挿入し、古い「通常の」オブジェクトは挿入されません (ほとんどのドライバーは実際に ObjectID を生成するドライバーであり、サーバーではありませんが、サーバーの場合もあります)。

すでに変更されて挿入されているシナリオが優先されます。理由？

代わりに生成された ObjectID を更新して変更する場合、または後でタイプを変更して ObjectID を変更する必要がある場合、そのフィールドを後でシャード キー (またはその一部) として使用しようとすると、問題が発生する可能性があります (シャード キーは不変です)。シャード キーを更新する必要がある場合、シャード環境でこれを回避する方法は、問題のドキュメントを削除し、更新するのではなく、再度追加することです。

さらに、 update メソッドは不要な操作であり、避けることができます (気にする場合としない場合があります)。

最後に、一意性があります - とにかくマシン ID はあまり変更されないため、ここで問題が発生することはないと思います。inc フィールドは 1 秒以内に衝突を処理する必要がありますが、注意してください。 ObjectID を変更するために使用する方法により、奇妙なことが発生した場合に備えて。

于 2012-12-07T19:32:15.387 に答える