UUIDとULIDを理解していない方は見た方がいい記事
Auto increment（自動採番）型を採用したくない場合 Auto Incrementは、データベースにおいて自動的に一意の識別子を生成するメカニズムです。通常、数値型の列が対象となり、新しいレコードが挿入されるたびにその列の値が自動的にインクリメントされます。典型的なIDですかね。 ここでは一意性の確保の話や、データ移行やバックアップのデメリットには言及せず、セキュリティとプライバシーの懸念にフォーカスして考えます。 予測可能性 Auto Increment型のIDは連番であるため、次に生成されるIDが容易に予測可能です。これにより、攻撃者がシステムの内部構造を推測し、不正アクセスを試みるリスクが高まります。 情報漏洩のリスク 連番のIDはデータベースの挿入順序を反映しているため、公開されることで企業の活動パターンやデータ生成の頻度が漏洩する可能性があります。 例） 競合他社は、公
PostgreSQLのプライマリーキーはSERIALとUUIDのどっちが速いのか実験してみた - Qiita
注意 この記事の実験は実際の運用を正確に反映していない恐れがあります（コメント欄の @hmatsu47 さんの投稿を参照）。 実務のアプリケーションでは異なる結果になる可能性もあるので、本記事の内容はあまり鵜呑みにせず参考程度に留めておいてください。 ※「実務に近い環境で実験してみた」という投稿もお待ちしています！ はじめに データベース（この記事ではPostgreSQLを対象とします）の主キーは1,2,3のような連番の整数値を主キーにするSERIALと、"00009236-b73c-4338-8ebd-e1f6c4f4fdd8"のようなランダムな文字列を主キーにするUUIDがあります。 それぞれメリットとデメリットがありますが、パフォーマンスについてはどうでしょうか？なんとなくSERIALの方がシンプルなぶん、速そうなイメージがありますが、実際はどうなのか調べてみました。 実行環境 Ma
UUIDなのにデータベースのプライマリキーに設定してもパフォーマンスの問題を起こさない「UUIDv7」の標準化作業が進行中
UUIDは「Universally Unique Identifier」の略称で、世界中のどこにも重複が存在しない唯一のIDという特徴があります。UUIDには歴史的な経緯によっていくつかのバージョンが存在していますが、2023年10月時点で標準化の作業が進行中のv7についてCI/CDサービスを提供する企業のBuildkiteが解説しています。 Goodbye to sequential integers, hello UUIDv7! https://buildkite.com/blog/goodbye-integers-hello-uuids UUIDは128ビットの数字で、大部分をランダムに作成することで重複する確率を限りなくゼロに近づけており、実質的に世界中のどこにも存在しない唯一のIDとみなせるようになっています。しかし、完全に数値がランダムのためプライマリキーとして使用するとデータ
UUID v6, v7, v8 : タイムスタンプでソートできる新しい UUID のドラフト仕様 - kakakakakku blog
ID を採番するときによく使われる UUID Version 4 の課題として「順序性がなくソートしにくい」という側面があり，ULID (Universally Unique Lexicographically Sortable Identifier) を使えばソートできるようになるという記事を前に書いた． kakakakakku.hatenablog.com 関連して調査をしていたら，標準化団体 IETF (Internet Engineering Task Force) によって，UUID Version 6, 7, 8 という新しい仕様が提案（ドラフト段階）されていることを発見した❗️UUID Version 6, 7, 8 の目的を簡単にまとめると「タイムスタンプ情報を使ってソートできる ID を採番できるようにする」となり，もしこの仕様が取り込まれると，UUID を活用する幅がさ
誕生日の問題とユニークな識別子
誕生日は $N = 365$ 通りあります。$n$ 人（$n < N$）がパーティを開きました。誕生日が同じ人がいる確率は \[ 1 - \frac{365}{365} \times \frac{364}{365} \times \frac{363}{365} \times \cdots \times \frac{365 - n + 1}{365} \] です。次の近似式でも計算できます（証明は例えばWikipediaの Birthday problem 参照）： \[ 1 - e^{-n^2/(2N)} \] Pythonで試してみましょう： import matplotlib.pyplot as plt import numpy as np a = [] p = 1 for i in range(366): a.append(1 - p) p *= (365 - i) / 365 x
世界でたったひとつの識別子として活用される「UUID」はどのように生成されているのか
オンライン対戦システムやランキングシステムの都合などで「世界中で唯一の値である識別子」をサーバーに接続せずに作成する必要がある場合があり、そうした場合に活用されるのが「UUID」です。そのUUIDの性質について、エンジニアのアリアマン・シャーダさんが解説しています。 Understanding How UUIDs Are Generated - Digital Bunker https://digitalbunker.dev/2020/09/30/understanding-how-uuids-are-generated/ UUIDは世界中で重複がないユニークな値となるよう設計されており、さらにその一意性が中央サーバーなどの要素に依存しないようになっています。こうした特徴をもつUUIDをデータベースの主キーに利用すると他人のデータベースと結合したり、データを別のデータベースに移動したりする
UUIDを重複させるにはどれだけ時間がかかるのか試してみた
絶対に重複しないといわれるUUID UUIDとはUniversally Unique Identifier の略で、「Universally」つまり将来にわたって重複や偶然の一致が起こらないという前提で使われるIDのことです。 128ビットで表現されるUUIDは2^128通り（Version 4では固定値があるため2^122通り）あり、その膨大なパターンから将来に渡って重複しないとされています。その特性から、ファイルのハッシュ値に使われたり、DBのキーに使われたりしています。重複しないことが約束されているので、大変使い勝手が良いのです。 とはいえ、有限桁数である以上は重複が発生する可能性がごく僅かながら存在します。 では実際に重複させるには、どれだけUUIDを作らないといけないのか試してみます。 まずは計算で目算をつける x通りのパターンがあるとき、衝突回数がpになるときの試行回数nは以下
時間順にソート可能なUUIDv6, UUIDv7, UUIDv8の提案仕様 - ASnoKaze blog
IETFに「New UUID Formats」という提案仕様が提出されています。 これは、時系列順にソート可能なUUID version 6, UUID version 7, UUID version 8を新しく定義するものです。 詳しい背景は提案仕様にゆずりますが、ULIDを始めとして、時系列順にソート可能な一意な識別子を利用したいというユースケースがあります。例えば、データベースのキーとして使えば、ソートせずとも順番に並びますし、書き込む際も順々に書き込めるのでデータアクセスが局所的になります。 今回は簡単に、それぞれのUUIDのフォーマットを眺めていきます。なお、フォーマットは異なりますが、バージョンを示す値は同じ位置にあります。 UUIDv6 UUIDv6は128bit長で、UUIDv1と似てるフォーマットを取ります。 1582年10月15日(グレゴリオ暦)からの100ナノ秒単位で
UUID version 6の提案仕様 - ASnoKaze blog
[2021/04/28追記] 新しく提案仕様が出たので、新しく記事を書きました asnokaze.hatenablog.com 先日IETFに提出された「UUID Format Update」という提案仕様の中でUUID version 6のフォーマットが言及されている。このDraftはUUIDを定義しているRFC4122を更新するものです。 ただ、まだIndividual Draftのdraft 00であり、この提案自体どうなるかは全くわからない点に注意が必要。 なお、UUIDv6自体はこの提案を行っているBrad G. Peabody氏が以前から取り組んでいた模様で、4年以上まえから案は存在していたようだ(URL)。またそのタイミングでサンプル実装も公開している。 UUIDv6 この提案仕様の中で、UUIDをデータベースのプライマリキーとして使用する際の課題をあげている。時系列順に並び
GitHub - alexdredmon/cuteuid: Generate cute UIDs
from cuteuid import generate_cuteuid generate_cuteuid() # 1337 UID # 3xampl3a-boy1-goa1-5ucc33dd3p7h # d1v151on-5ho3-1w31-d1571ngu15ha # 7ak351h3-k33p-175a-5ympa7h371c1 generate_cuteuid(hex_only=True) # 1337 UID (hex only) # 10adca9a-4057-5a13-901171ca1136 # 0ff1c1a1-50f7-f33d-43517a73b3d1 # ad01053a-9057-7311-c411d400da50 generate_cuteuid(emoji=True) # EmojiUID # ⛹♂️🧜♂️⬜️3️⃣📏🧹🤴🗾➖🇵🇰📔💹🌳
メルセンヌツイスタはそんなに衝突しない - Qiita
κeenです。こちらのスライドが話題になっているようです。 10秒で衝突するUUIDの作り方 - Speaker Deck 笑い話としても乱数の難しさの側面としても面白いのですが、これを見た人たちの反応がちょっと勘違いしてそうだったので補足します。 別に私は暗号とか乱数とかの専門家ではないです。 発表者の方のコードは読みましたか？ 少し速度が必要になるのでRustに移植します。 [package] name = "genuuidv4" version = "0.1.0" edition = "2018" # See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html [dependencies] rand = "0.7.2" sfmt = "0.6.0" use
[Python] UUIDを生成するuuid.uuid4()はどうやってUUIDを生成しているのか？ | DevelopersIO
※2019/2/17:OS固有の乱数の発生方法について追記しました。 どうも！大阪オフィスの西村祐二です。 何かにIDを設定するときにUUIDをよく使うかと思います。 Pythonではuuidモジュールというのが提供されており下記のように簡単に生成することができます。 import uuid hoge_id = str(uuid.uuid4()) どうやってuuidを生成しているの気になったのでドキュメントをみたところ、uuid1,3,5はわかったのですが、uuid4はどうやっているのかわからなかったので調べてみました。 https://docs.python.org/ja/3/library/uuid.html 環境 OS: macOS 10.14.3 python3.7.2 ソースコードをみて確認する やはり、ここが一番の近道です。ソースを覗いてみるとos.urandom(16)を使っ
![[Python] UUIDを生成するuuid.uuid4()はどうやってUUIDを生成しているのか？ | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/676cbdfcd4517b4c0ed0566a3a2e2c32ed0f4db2/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2019%2F02%2Fpython_icatch.png)
UUID(v4) がぶつかる可能性を考えなくていい理由 - Qiita
お手軽にランダムなIDを取得したい時にUUIDはとても重宝します。 でもたまに、 「このID(UUID)ってぶつかることない？対策しなくて大丈夫？」 と聞かれることがあります。 それに対して、 「ウィキペディア先生がぶつからねえって言ってたから大丈夫だよ！（＃ﾟДﾟ）」 で切り抜けるのもそろそろ限界のような気がするのでちゃんと調べました。 (もちろんウィキペディア先生を頼りました！) 2つの理論 UUIDの衝突確率について考える上で次の2つの理論が重要になります。 鳩の巣原理 誕生日のパラドクス 鳩の巣原理 鳩の巣原理とは、 m個の入れ物にn個のものを入れるとき、n > m ならば少なくとも1個の箱には2個以上のものが入る 9個の巣箱に10羽の鳩が入る場合、必ずどれかの巣箱には2羽以上入ることになるということです！(ウィキペディア先生) 考えれば当たり前のことですが同様にして考えれば、 「
十分大きな乱数をユニークな識別子として使うのがなぜ安全なのか｜Rui Ueyama
いろいろなソフトウェアで、大きいランダムな値をユニークな値とみなすということが行われている。例えばユニークな識別子としてよく使われるUUIDはただの122ビットの乱数だ。gitもSHA-1ハッシュ値が160ビットの乱数のように扱えることを期待して、それをユニークな識別子として使っていた。実際にはランダムな2つの値が同じになる確率はゼロではないのに、なぜこれが安全なやり方だと言えるのだろうか？ それについてちょっと説明してみよう。 あるシステムが、乱数で生成された識別子の衝突のなさに依存しているとして、仮に衝突が発生した場合、相当悪い結果、例えば復旧不可能な形でデータベースが壊れてしまうとしよう。これはどれくらい危険なのだろうか？ 数学の問題で、学校のクラスの中で同じ誕生日の人が1組以上いる可能性は思ったより高いという話を聞いたことがあると思う。あるランダムに生成された値が衝突する確率という
UUID の重複する可能性 - satosystemsの日記
UUID Wikipedia 日本語版によると UUIDは、分散システム上でどこかが統制を取らずとも、一意に特定可能な識別子の作成を目的としており、UUIDは重複や偶然の一致が起こりえないと確信して用いることができる。 UUID - Wikipedia という。しかしながら、高々 122 ビットで表される数値*1である以上、生成し続ければ確実に重複する。 では、それがどれぐらいの確率なのか。 その説明は UUID Wikipedia 英語版に記載されている。英語だったり数式があったりしてわかりづらいが、説明の一部を訳してみたので、重複しない感が多少は分かるかと思う。 例 1 1 兆個 UUID を生成 生成した UUID が重複する確率より、隕石が頭に降ってくる確率のほうが高い 例 2 100 年間、毎秒 10 億の UUID を生成し続ける その後、UUID をひとつ生成 生成した UU
UUIDはなぜ、分散環境で好き勝手に生成しても衝突しないのか。RFC4122規格とUUIDの性質。
UUID の Version の見分け方 さきほどのPHPのプログラムは、パラメータにUUID_TYPE_RANDOMを渡しているので、バージョン4と思われます。 uuid_createのソースコードを覗いてみる ちょっと遊びの領域に突入しますが、uuid_createのソースコードを覗いてみます。一部を抜粋します。 /* {{{ proto string uuid_create([int uuid_type]) Generate a new UUID */ PHP_FUNCTION(uuid_create) { // ...(略)... do { uuid_t uuid; char uuid_str[37]; switch(uuid_type) { // ...(略)... case UUID_TYPE_DCE_RANDOM: uuid_generate_random(uuid); br
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://twitter.com/LiosK/status/1588116287422877697
10秒で衝突するUUIDの作り方