データベースの適切な主キーの選択

ULID 対 UUID 対自動インクリメント??

主キーはデータベース管理システムにおいて重要な役割を果たし、テーブル内の各レコードの一意の識別子として機能します。これらにより、データの効率的な取得、更新、削除が可能になり、重複レコードが存在しないようにすることでデータの整合性を維持できます。データベース スキーマを設計する際、最も重要な決定事項の 1 つは、適切な主キーの種類を選択することです。これは、パフォーマンス、スケーラビリティ、使いやすさに大きな影響を与える可能性があります。

この記事では、3 つの一般的な主キー タイプの長所と短所を検討します。- Universally Unique Identifier (UUID)、Universally Unique Lexicographically Sortable Identifier (ULID)、および自動インクリメント整数。データベースに適切な主キーを選択する際に情報に基づいた決定を下すのに役立つ例とともに、それぞれのプロパティと特徴について説明します。

---

汎用一意識別子 (UUID)

UUID は、グローバルに一意になるように設計された 128 ビットの数値です。これは、同じ UUID が 2 回生成される確率が天文学的に低いことを意味します。これらはダッシュを含む 36 文字の文字列として表され、中央機関を必要とせずに独立して生成できます。 UUID にはさまざまなバージョンがありますが、乱数に依存するバージョン 4 が最も一般的に使用されます。 UUID の形式は次のとおりです:

XXXXXXXX-XXXX-MXXX-NXXX-XXXXXXXXXXXX

ここで、x は 16 進数 (0 ～ 9、a ～ f) で、M と N は事前に定義された意味を持つ特定のビットを表します。たとえば、UUID は次のようになります:

123e4567-e89b-12d3-a456–426614174000

データベースでは、UUID 主キーは次のようなテーブルに表示される場合があります。

UUID の利点

グローバルな一意性: UUID は衝突のリスクが極めて低いため、複数のクライアントが同時に ID を生成する分散システムやデータベースに適しています。
中央機関は必要ありません: UUID は調整を必要とせずに各クライアントで個別に生成できるため、分散システムに適しています。
データのマージが簡単: 異なるデータベースのデータを結合する場合、UUID を使用すると主キー値の競合を心配する必要がなくなります。

UUID の欠点

サイズ: UUID は自動インクリメントされる整数よりも大きく、一般的な整数の 4 バイトとは対照的に、16 バイトのストレージを占有します。これにより、ストレージとインデックス作成のコストが増加し、テーブルのクエリや結合時のパフォーマンスの低下につながる可能性があります。
人間が判読できない: UUID は、読み取ったり、覚えたり、口頭で伝達したりすることが難しく、開発者やサポート チームにとって使いにくくなっています。
順序なし: UUID は順次に生成されないため、クラスター化インデックスを含むテーブルにデータを挿入するときに断片化が発生し、パフォーマンスが低下する可能性があります。

ユニバーサルにユニークな辞書順ソート可能な識別子 (ULID)

ULID は、UUID の利点と並べ替え可能であるという追加の利点を組み合わせた、別のタイプの一意の識別子です。これらは 128 ビットの数値であり、大文字と数字で構成される 26 文字の文字列として表されます。 ULID の前半はタイムスタンプを表し、後半はランダムに生成された値です。 ULID の形式は次のとおりです:

01ARZ3NDEKTSV4RRFFQ69G5FAV

データベースでは、ULID 主キーは次のようなテーブルに表示される場合があります。

Benefit of ULIDs

• Global uniqueness: Like UUIDs, ULIDs provide a very low risk of collision, making them suitable for distributed systems.
• Lexicographically sortable: ULIDs are generated in a way that ensures they are sortable by their creation time, making them more efficient for querying and inserting into tables with clustered indexes.
• No central authority needed: ULIDs can be generated independently on each client without the need for coordination, making them suitable for decentralized systems.
• Human-readable: While not as easy to read as auto-incrementing integers, ULIDs are more human-readable than UUIDs due to their shorter length and character set.

Drawback of ULIDs

• Size: ULIDs occupy 16 bytes of storage, similar to UUIDs, which can lead to increased storage and indexing costs, as well as decreased performance when querying or joining tables.
• Not as human-readable as integers: Although more readable than UUIDs, ULIDs are still not as user-friendly as auto-incrementing integers, which can pose challenges for developers and support teams.

Auto-Incrementing Integers

Auto-incrementing integers are the most common type of primary key used in databases. As the name suggests, auto-incrementing integers are sequential numbers that automatically increase by a specified increment (usually 1) for each new record added to the table. An example of an auto-incrementing primary key sequence might be:

1, 2, 3, 4, 5, ...

In a database, an auto-incrementing integer primary key might appear in a table like this:

自動増分の利点:

• 理解しやすい: 自動インクリメントされる整数は人間が判読可能で、口頭での伝達が容易なため、開発者やサポート チームにとって使いやすいものになっています。
• サイズが小さい: 自動インクリメント整数は通常 4 バイトのストレージを占有するため、ストレージとインデックス作成のコストが削減され、テーブルのクエリまたは結合時のパフォーマンスが向上します。
• 順序付き: 自動インクリメント整数が順番に生成されるため、クラスター化インデックスを持つテーブルにデータを挿入する際のパフォーマンスが向上します。

自動インクリメントの欠点:

• 衝突のリスク: 複数のクライアントが同時に ID を生成する可能性がある分散システムまたはデータベースでは、主キー値が衝突するリスクがあります。
• 中央機関が必要: 整数を自動インクリメントするには、一意の ID を確実に生成するためにクライアント間または中央機関間の調整が必要ですが、これは分散システムでは課題となる可能性があります。
• データのマージが難しい: 異なるデータベースのデータを結合する場合、整数の自動インクリメントにより主キー値の競合が発生し、マージ プロセスがより複雑になる可能性があります。

適切な主キーの選択

データベースに使用する主キーのタイプを決定するときは、システムの特定の要件と制約を考慮することが重要です。状況に基づいて最適な主キーを選択するのに役立つガイドラインをいくつか示します:

• 集中型システム: 単一の権限が ID 生成を管理する集中型システムがある場合、自動インクリメント整数は、そのシンプルさ、サイズの小ささ、および人間が判読可能な形式のため、優れた選択肢となります。また、クラスター化インデックスを使用する場合のパフォーマンスも向上します。
• 分散システム: 複数のクライアントが同時に ID を生成し、中央の権限がない分散システムの場合は、UUID または ULID の方が適切です。どちらもグローバルな一意性を提供し、各クライアントが独立して生成できます。 ULID には、辞書順に並べ替えることができるという追加の利点があり、クエリのパフォーマンスを向上させることができます。
• データのマージ: システムで異なるデータベースからのデータを頻繁にマージする必要がある場合は、競合する主キー値を解決する必要がないため、UUID または ULID を使用することをお勧めします。
• パフォーマンス: パフォーマンスが最優先の場合は、自動インクリメント整数または ULID の使用を検討してください。自動インクリメント整数はストレージとインデックス作成の効率を向上させますが、ULID はソート可能な性質により、クラスター化インデックスを操作する際のパフォーマンスが向上します。

データ分析における主キーの処理

データ分析で主キーを使用する場合、各主キーの種類の特性と、それらが分析にどのような影響を与えるかを理解することが重要です。データ分析でさまざまな主キーを処理するためのヒントをいくつか紹介します:

• 自動インクリメント整数: 自動インクリメント整数を主キーとして使用する場合は、分析でこれらのキーの順序付けされた性質が考慮されていることを確認してください。たとえば、時間の経過に伴う傾向やパターンを分析する場合、自動増加する整数に基づいてデータが正しく並べ替えられていることを確認します。
• UUID と ULID: データ分析では、UUID と ULID は複雑でサイズが大きいため、扱うのがより困難になることがあります。分析を容易にするために、追加のインデックスを作成するか、派生列を使用して、関連する属性に基づいてデータを並べ替えたりフィルターしたりすることを検討してください。
• データの集約: 異なる主キー タイプを持つ複数のソースからデータを集約する場合は、主キーを UUID や ULID などの共通のタイプに変換して標準化することを検討してください。これにより、データ結合プロセスが簡素化され、すべてのソースにわたって一貫した分析が保証されます。
• 人間が読みやすい: データ分析の結果を関係者に提示するときは、UUID や ULID などの複雑な主キーの代わりに、ユーザー名や電子メール アドレスなど、人間が読みやすい識別子を使用することを検討してください。これにより、技術者以外の人にとっても結果がよりアクセスしやすく、理解しやすくなります。

---

結論

結論として、データベースに適切な主キーを選択することは、システムのパフォーマンス、スケーラビリティ、および全体的な成功に永続的な影響を与える可能性がある重要な決定です。状況の特定の要件と制約を慎重に検討し、チームと思慮深い議論を行うことで、データベース設計の強力な基盤を築く情報に基づいた選択を行うことができます。選択した主キーの種類は、システムの技術的な側面だけでなく、開発者、サポート チーム、さらには意思決定のためにデータに依存する関係者の使いやすさにも影響することに注意してください。したがって、時間をかけてトレードオフを理解し、プロジェクト固有のニーズに最も適した主キーを選択してください。

優れたデータベース設計は、よく整理された図書館のようなものであり、主キーはすべてを整理整頓するデューイ 10 進法です。

---

記事の出典 https://medium.com/geekculture/choosing-the-right-primary-key-for-the-database-326136eff4f4

この記事が洞察力に富んでいて、テクノロジーのトレンドについて最新の情報を入手したい場合は、必ずフォローしてください:-

Twitter: https://twitter.com/hafiqdotcom
LinkedIn: https://www.linkedin.com/in/hafiq93
BuyMeCoffee: https://paypal.me/mhi9388 / https://buymeacoffee.com/mhitech
媒体: https://medium.com/@hafiqiqmal93

以上がデータベースの適切な主キーの選択の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。