[フレーム]
はてなブックマークアプリ

サクサク読めて、
アプリ限定の機能も多数!

アプリで開く

気に入った記事をブックマーク

  • 気に入った記事を保存できます
    保存した記事の一覧は、はてなブックマークで確認・編集ができます
  • 記事を読んだ感想やメモを書き残せます
  • 非公開でブックマークすることもできます
適切な情報に変更

エントリーの編集

loading...

エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。

タイトルガイドライン

このページのオーナーなので以下のアクションを実行できます

タイトル、本文などの情報を
再取得することができます
コメントを非表示にできます コメント表示の設定

ブックマークしました

ここにツイート内容が記載されます https://b.hatena.ne.jp/URLはspanで囲んでください

Twitterで共有

ONにすると、次回以降このダイアログを飛ばしてTwitterに遷移します

271users がブックマーク コメント 31

ガイドラインをご確認の上、良識あるコメントにご協力ください

0 / 0
入力したタグを追加

現在プライベートモードです 設定を変更する

おすすめタグタグについて

よく使うタグ

連番IDを使うと会社が潰れる。(訳: 連番とUUIDのベンチマークを取ってみた❤️)

271 users zenn.dev/uncode_jp

ガイドラインをご確認の上、良識あるコメントにご協力ください

0 / 0
入力したタグを追加

現在プライベートモードです 設定を変更する

おすすめタグタグについて

よく使うタグ

はてなブックマーク

はてなブックマークで
関心をシェアしよう

みんなの興味と感想が集まることで
新しい発見や、深堀りがもっと楽しく

ユーザー登録

アカウントをお持ちの方はログインページ

記事へのコメント31

  • 注目コメント
  • 新着コメント
mak_in
連番IDでなくUUID等ランダムIDを使う主な目的に、書き込み用DBを複数台クラスタリングした際ランダムIDだと重複しない、というメリットがある。性能気にする割にそこを言及する記事が少ない印象。非並列なら連番IDで十分

その他
hylom
参考:UUIDv7がMySQLで速いという話 https://zenn.dev/gorogoroumaru/articles/6dff69b1a592a2

その他
damedom
クラウド時代のアーキテクチャだとだいたい水平スケールが基本で、連番にすると採番そのものがボトルネックになることが多い。ERPとか特にそう。それに備えて連番のプリアロケーションとかあるけど。

その他
ryokdy
PostgreSQLでパフォーマンス上問題がないことはさておき、タイムスタンプが埋め込まれているUUIDv7やULIDをURLとして晒していいかは要件によると思う。例えば予約投稿みたいなものがいつ作られたか知られてしまう

その他
circled
今は誰でも富豪プログラミング可能な環境なので気にしてないけど、カラムが扱う情報量が少ない程に速いのは当然なので、smallint > integer > bigintみたいにUUIDに限らず、データ型によって速度に差がつくのよな

その他
nemoba
書き込み速度じゃなくて、読み込み時のキャッシュの局所性の話だってば。この問題理解できない時点で影響ないから気にしないほうがいい。/ https://htn.to/32L8Kaktf7

その他
nmcli
連番がいちばんディスク効率いいしベンチマーク優先なら本当は使いたいんだけどね、その他の要件によって UUID が選択されるんよね / PostgreSQL 17 で UUIDv7 導入予定あるみたいで嬉しい https://commitfest.postgresql.org/50/4388/

その他
kekera
連番IDは新規登録時のID発番の機能がボトルネックになってスケールできないのよ。UUIDなら並列で発番して登録してもぶつからない(とされる)でしょ

その他
Kil
連番がセキュリテイ上良くないって言うけど、それって結局適切なアクセス権があるかのチェック処理の手抜き(未知のIDへはアクセスされないことを期待している)なだけなんだよね。ちゃんと作れば問題にならない。

その他
strawberryhunter
UUIDはかなり大規模なシステムにならないとメリットが活きてこないと思う。どうでもいい話、4バイトのint (テキストで最大10バイト)に慣れていると、常に16バイトのPKは見た目とかそういう部分の心理的な抵抗が大きい。

その他
tmatsuu
連番は発番時に理論上ロックが必要となるはずで、複数コネクションから同時INSERTを行う場合はもっと遅れる可能性があるかもと思った。ベンチのソースを見る限り1コネクションのbulk insertっぽいので再試験の機運

その他
mohri
会社が潰れるには3つの理由があるといいます(といって話しはじめるとだいたい4つある

その他
Derabon
良い記事

その他
tettekete37564
insertコストは制約やトランザクションのコスト。単純fetchについてはインデックスのB木が不均衡になると遅くなる(から再構築を行う)。UUIDのメリットは分散DBで発揮する。この記事は何をベンチしてるのかよく分からない。

その他
fivestech
B2CならUUIDv7が最適、社内システム系なら連番でも良いと思う。ユーザーにUUID見せたくないならpg_hashidsとか使えばいいし

その他
cocelo
UUIDv7、クラウドで使う分には良い(時刻同期が正しく行われている分には良い)んだけど、オンプレでやろうとする人はNTPの冗長化を忘れないでね...酷い目にあうよ...

その他
ryokdy
ryokdy PostgreSQLでパフォーマンス上問題がないことはさておき、タイムスタンプが埋め込まれているUUIDv7やULIDをURLとして晒していいかは要件によると思う。例えば予約投稿みたいなものがいつ作られたか知られてしまう

2024年10月07日 リンク

その他
Kil
Kil 連番がセキュリテイ上良くないって言うけど、それって結局適切なアクセス権があるかのチェック処理の手抜き(未知のIDへはアクセスされないことを期待している)なだけなんだよね。ちゃんと作れば問題にならない。

2024年10月07日 リンク

その他
daichirata
10年くらい前の話題が再燃してるのは世代が一巡した感がある

その他
sigwyg
連番が早いのってHDDの特性もなかったっけ?(うろ覚え)

その他
nemoba
nemoba 書き込み速度じゃなくて、読み込み時のキャッシュの局所性の話だってば。この問題理解できない時点で影響ないから気にしないほうがいい。/ https://htn.to/32L8Kaktf7

2024年10月07日 リンク

その他
aquarickn
UUIDv7標準化はまだかと願っていたが、まだ普及は遅い

その他
tkrd
弊社は、昨年ぐらいから UUID v7 を採用することにしました。

その他
kekera
kekera 連番IDは新規登録時のID発番の機能がボトルネックになってスケールできないのよ。UUIDなら並列で発番して登録してもぶつからない(とされる)でしょ

2024年10月07日 リンク

その他
saikyo_tongaricorn
またこいつか

その他
Helfard
うっう〜♪

その他
progrhyme
まあ、DBMSによるのでは

その他
strawberryhunter
strawberryhunter UUIDはかなり大規模なシステムにならないとメリットが活きてこないと思う。どうでもいい話、4バイトのint (テキストで最大10バイト)に慣れていると、常に16バイトのPKは見た目とかそういう部分の心理的な抵抗が大きい。

2024年10月07日 リンク

その他
enemyoffreedom
Snowflake ID知らなかった

その他
chiroruxx
で、どう会社が潰れるん?

その他
estragon
現状、serial、UUIDv7、snowflakeが大差なく、レコード数増えてもそんなに悪くならないと。UUIDv7はちょっと不安な振舞ね

その他
damedom
damedom クラウド時代のアーキテクチャだとだいたい水平スケールが基本で、連番にすると採番そのものがボトルネックになることが多い。ERPとか特にそう。それに備えて連番のプリアロケーションとかあるけど。

2024年10月07日 リンク

その他
BlueSkyDetector
ブコメの知見も含めると、ソートとクラスタリングの両面でメリットあるので、特にこだわりが無いときはとりあえずUUIDv7を選べばいいということか。

その他
napsucks
snowflakeがだんだん遅くなっていくのはなんでなんだろう

その他
hylom
hylom 参考:UUIDv7がMySQLで速いという話 https://zenn.dev/gorogoroumaru/articles/6dff69b1a592a2

2024年10月06日 リンク

その他
TakamoriTarou
えらいひとがやベストプラクティスを出してくれるから、我々は計らずにすんでありがたいんや、と思っていたら最後計れになってた。はい。

その他
tofu-kun
どうもムーザルちゃんねるのzaruです、こんにちは

その他
rutei
uuidv7が早いのは意外。selectの結果も気になる。

その他
nmcli
nmcli 連番がいちばんディスク効率いいしベンチマーク優先なら本当は使いたいんだけどね、その他の要件によって UUID が選択されるんよね / PostgreSQL 17 で UUIDv7 導入予定あるみたいで嬉しい https://commitfest.postgresql.org/50/4388/

2024年10月06日 リンク

その他
mak_in
mak_in 連番IDでなくUUID等ランダムIDを使う主な目的に、書き込み用DBを複数台クラスタリングした際ランダムIDだと重複しない、というメリットがある。性能気にする割にそこを言及する記事が少ない印象。非並列なら連番IDで十分

2024年10月06日 リンク

その他

注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています

リンクを埋め込む

以下のコードをコピーしてサイトに埋め込むことができます

プレビュー
アプリのスクリーンショット
いまの話題をアプリでチェック!
  • バナー広告なし
  • ミュート機能あり
  • ダークモード搭載
アプリをダウンロード

関連記事

usersに達しました!

さんが1番目にブックマークした記事「連番IDを使うと会...」が注目されています。

気持ちをシェアしよう

ツイートする

連番IDを使うと会社が潰れる。(訳: 連番とUUIDのベンチマークを取ってみた❤️)

大いなる流れには逆らえない あるAI研究者が言っていた、私の仕事もいつか AI に奪われるという言葉が非... 大いなる流れには逆らえない あるAI研究者が言っていた、私の仕事もいつか AI に奪われるという言葉が非常に印象的だった。 私は一時期自分のキャリアに危機感を覚えAIに関する情報を集めていた。そのとき見つけたYoutube動画でこのようなことが語られていたのである。 ではなぜ彼らは研究を続けるのかと思うかもしれないが、個人や一団体がそれを放棄したところで世の中のイノベーションの流れを止めることは不可能だろう。 平和を望む国々も兵器開発をやめられないのと似たようなものだ。 私がこの記事のタイトルを思いついたとき、つい溜息が出た。あまり楽しくない思い出があるからだ。 ただ、思いついてしまった以上これを世に出さないわけにもいかず、血の涙を流しながらこの記事を書いている。 私というちっぽけな存在では、この大宇宙の大いなる流れには逆らえないのだ。 申し遅れました。私、YadaYadaKonnanYa

ブックマークしたユーザー

  • kamm2025年06月09日 kamm
  • funghi_seven2025年06月03日 funghi_seven
  • techtech05212024年12月28日 techtech0521
  • ndxbn2024年11月10日 ndxbn
  • mutsuki_sc2024年10月31日 mutsuki_sc
  • knj29182024年10月30日 knj2918
  • rAdio2024年10月13日 rAdio
  • non_1172024年10月13日 non_117
  • tmatsuu2024年10月12日 tmatsuu
  • yug12242024年10月09日 yug1224
  • ysirman2024年10月08日 ysirman
  • mohri2024年10月08日 mohri
  • koma22024年10月07日 koma2
  • dhrname2024年10月07日 dhrname
  • Akineko2024年10月07日 Akineko
  • Derabon2024年10月07日 Derabon
  • kanno_s2024年10月07日 kanno_s
  • kazufsaf2024年10月07日 kazufsaf
すべてのユーザーの
詳細を表示します

ブックマークしたすべてのユーザー

同じサイトの新着

同じサイトの新着をもっと読む

いま人気の記事

いま人気の記事をもっと読む

いま人気の記事 - テクノロジー

いま人気の記事 - テクノロジーをもっと読む

新着記事 - テクノロジー

新着記事 - テクノロジーをもっと読む

同時期にブックマークされた記事

いま人気の記事 - 企業メディア

企業メディアをもっと読む

はてなブックマーク

公式Twitter

はてなのサービス

Copyright © 2005-2025 Hatena. All Rights Reserved.
設定を変更しましたx

AltStyle によって変換されたページ (->オリジナル) /