UUIDなどを使用する必要がありますか？

Question

非常に頻繁に私はオブジェクトを収集する必要があり、DB（PostgreSQL）に保存する前にそのIDを知る必要があるというタスクがあります。

私はUUIDでこれを行うことができますが、それは欠点がたくさんあります。
- レスもパフォーマンス選択または
を含む - 参加すると少なくもパフォーマンスを
- 必要性より多くのスペースが

そこで質問です：方法あらかじめオブジェクトのIDを生成してUUIDの負の影響を最小限に抑えることはできますか？

Answer 1

私たちはプロジェクトでこの問題に直面しました。私はいくつかのテスト（約4M行、私が正しいと思います）を実行しました。これは、uuidsが実際にPGのパフォーマンスをintに比べて悪くしていないことを示しました。今ではuuidsを主キーとして使っているので、もう一度やり直すことをためらっています。しかし、私は、これが生産において大規模にどのように実行されているかをまだ見ていないという警告を加えなければなりません。このうち

チェック：http://www.codeproject.com/Articles/388157/GUIDs-as-fast-primary-keys-under-multiple-database

はUUIDを使用してのいいところは、あなたが衝突を心配する必要はありませんです。素晴らしいことではありません。テスト用のクエリを手動で入力する場合は、少し面倒です。

あなたはこのトリックを使用したUUIDの大規模なリストに基づいて選択してしまう場合：https://www.datadoghq.com/blog/100x-faster-postgres-performance-by-changing-1-line/

希望これは、

アダムを助けます。

Answer 2

任意のプログラミング言語で任意のUID発生器を使用できます。私はPostgreSQLのuuid型を使用して、スペースや結合に関してあまりにも多くのオーバーヘッドを必要としないようにすることをお勧めします。 PostgreSQLには、これらを生成する方法も含まれていないので、まずそれらを生成する必要があります。

あなたが遭遇する可能性のある大きな問題は、数値IDでは、uuidsの大きな問題となる多くのことが比較的苦になることです。これらを含める：同様の時間（数値IDが連続しているため）に挿入された一連のレコードを選択する識別子

で

1. 型付け。

ただし、PostgreSQLでUUID型を使用する場合は、選択と結合のパフォーマンスがそれほど悪くはありません。そしてUUIDの生成方法はプログラマとしてあなた次第です

Answer 3

もちろん、UUIDは整数よりも低いパフォーマンスで動作するはずですが、問題はデータの量です。正直言って、4Mのデータはパフォーマンス上の問題であるかどうかを言うには小さすぎ、もちろん、データボリュームが依然として4M未満の要件イメージであればOKです。文書https://rclayton.silvrback.com/do-you-really-need-a-uuid-guidで

、それがいつ、どのようにデータベースが `serial` IDを割り当てることができないのはなぜUUID