0

要件:
マーチャントを一意に識別できるように、十分な長さのランダムな番号/文字列をマーチャントに割り当てる必要があります (誰かに識別子を推測させたくない)。これが必要なのは、この番号/文字列を QR コードとして印刷し、マーチャントに提供して、ユーザーが QR コードを読み取ってマーチャントに関する情報を取得できるようにするためです。

現在の実装:
ID はシーケンシャルであるため出力できません。そのため、JUG UUID ジェネレーターの TimeBasedGenerator によって生成された一意の ID を格納する新しいフィールド (externalId) を導入しました。さらに調査したところ、UUID にパフォーマンスの問題があることがわかりました。すべての記事で UUId を主キーとして説明していますが、私は UUID を主キーとしてではなく、二次識別子として使用しています。検索に比べて挿入や更新が少なくなるので、私は心配していません。ユーザーは、印刷された QR コードから読み取った UUID を送信し、この UUID フィールドを使用してマーチャントを検索する必要があるため、パフォーマンスに大きな影響があります。

私による解決策:
UUID の代わりに ID:UUID の組み合わせを提供するため、リクエストを取得したときに、ID を使用してマーチャントを分割およびフェッチし、DB に存在する externalId(UUID) が一致するかどうかを確認できます。それが一致する場合は、商人を返します。

このソリューションはパフォーマンスを大幅に向上させますか、それとも文字列操作にかかる時間が効果を無効にします。

これを行うためのより良いアプローチはありますか?

ありがとう

4

2 に答える 2

0

最適な実装は UUID の文字分布によって異なりますが、同様の状況に直面したときに私が行ったことは、エンド ユーザーに UUID のみを使用することです。データベースに、UUID の最初の 2 文字で満たされた列を追加し、その列にインデックスを付けました。

これか、あなたが提案したように、IDは同じ目的を果たします。部分的な UDID をインデックス化する利点は、次のとおりです。

  1. パフォーマンスを向上させるために使用する文字数を微調整できます
  2. ID は外部で使用されないため、問題が発生する可能性があります。

一方、整数インデックスはおそらくメモリの使用量が少なく、微調整の必要はありません。

パフォーマンスに関しては、私の実装では、100 万分の 1 の検索クエリに 7 ～ 8 秒かかっていました。このソリューションにより、数ミリ秒に短縮されました

于 2016-04-20T13:23:05.493 に答える