新しくWebサイトを作るだとかアプリを作るときだとか、
データベースをもちろん使うわけで、
その際にIDなどをint型で処理してauto_incrementを使ったりなどで連番にしたりする。
tinyintからbigintまであるけどサービスによってはどれを使ったらいいのか悩む。
というわけで今日はそんなときにどう割り当てたらよいのか的なお話でも。
■数値型の種類
tynyint:-128〜127
→unsigined:0〜255
smallint: -32768〜32767
→unsigned:0〜65535
mediumint:-8388608〜8388607(838万8607)
→unsigned:0〜16777215
int:-2147483648〜2147483647(21億4748万3647)
→unsigned:0〜4294967295
bigint:-9223372036854775808〜9223372036854775807(922京3372兆0368億5477万5807)
→unsigned:0〜18446744073709551615
→unsigined:0〜255
smallint: -32768〜32767
→unsigned:0〜65535
mediumint:-8388608〜8388607(838万8607)
→unsigned:0〜16777215
int:-2147483648〜2147483647(21億4748万3647)
→unsigned:0〜4294967295
bigint:-9223372036854775808〜9223372036854775807(922京3372兆0368億5477万5807)
→unsigned:0〜18446744073709551615
って感じだけど正直なところmediumint辺りからなんか数字に具体性がないというか、
どれくらいで枯渇するのかとかっていうのがわかりにくくなってくる。
普通にint使っていれば大体は大丈夫だけど、サービスによってはbigint使うべきかとか悩んでしまう。
■どれくらい使うと枯渇するか例えてみる
ということで一日に何個使う事で枯渇するのかを真面目に考えてみた。
で、ついでにこんなサービスに向いているんじゃないかとかも適当に考えてみた。
ちなみにunsigned(符号無し)にはせずで考えてみた。
tynyint:-128〜127
→1日に100個で、1日ちょいぐらいで枯渇
使い道:ユーザのグループなど数が少なくても大丈夫なもの
smallint: -32768〜32767
→1日に100個で1年いかないぐらいで枯渇
使い道:タグとかキーワードなど使い回しがきくようなもののシーケンス
mediumint:-8388608〜8388607(838万8607)
→1日に100個で230年くらいで枯渇
→1日に1,000個で23年ぐらいで枯渇
→1日に10,000個で2.3年ぐらいで枯渇
使い道:1日にそんなに数をアップしない感じのニュース配信系サイトやブログの記事、
そんなにいかないだろうなって感じの会員制サイトのユーザID
int:-2147483648〜2147483647(21億4748万3647)
→1日に100,000個で58年ぐらいで枯渇
→10,000人くらいが1日に10個ぐらい記事を書いたら58年くらいで枯渇
→1日に1,000,000個で5.8年ぐらいで枯渇
使い道:小規模SNSのユーザIDや、アクティブユーザーが10,000人くらいの会員制サイト、
1カ国だけで使われるようなサイトなど
bigint:-9223372036854775808〜9223372036854775807(922京3372兆0368億5477万5807)
→1日に1億個で2.5億年くらいで枯渇
→10億人くらいが1日に10個ぐらい記事を書いたら250万年で枯渇
→世界の人口(70億人くらい)が1日に10個ぐらい記事を書いたら36万年ぐらいで枯渇
→世界の人口(70億人くらい)が1日に40いいねしたら9万年ぐらいで枯渇
使い道:SNSでのいいねボタンのようなもののIDや、1000万人以上の会員数になりそうなサイト、
twitterやfacebookなどグローバルに使われるサイト
→1日に100個で、1日ちょいぐらいで枯渇
使い道:ユーザのグループなど数が少なくても大丈夫なもの
smallint: -32768〜32767
→1日に100個で1年いかないぐらいで枯渇
使い道:タグとかキーワードなど使い回しがきくようなもののシーケンス
mediumint:-8388608〜8388607(838万8607)
→1日に100個で230年くらいで枯渇
→1日に1,000個で23年ぐらいで枯渇
→1日に10,000個で2.3年ぐらいで枯渇
使い道:1日にそんなに数をアップしない感じのニュース配信系サイトやブログの記事、
そんなにいかないだろうなって感じの会員制サイトのユーザID
int:-2147483648〜2147483647(21億4748万3647)
→1日に100,000個で58年ぐらいで枯渇
→10,000人くらいが1日に10個ぐらい記事を書いたら58年くらいで枯渇
→1日に1,000,000個で5.8年ぐらいで枯渇
使い道:小規模SNSのユーザIDや、アクティブユーザーが10,000人くらいの会員制サイト、
1カ国だけで使われるようなサイトなど
bigint:-9223372036854775808〜9223372036854775807(922京3372兆0368億5477万5807)
→1日に1億個で2.5億年くらいで枯渇
→10億人くらいが1日に10個ぐらい記事を書いたら250万年で枯渇
→世界の人口(70億人くらい)が1日に10個ぐらい記事を書いたら36万年ぐらいで枯渇
→世界の人口(70億人くらい)が1日に40いいねしたら9万年ぐらいで枯渇
使い道:SNSでのいいねボタンのようなもののIDや、1000万人以上の会員数になりそうなサイト、
twitterやfacebookなどグローバルに使われるサイト
という感じになった。
多分焦点になるのはintでよいのか、bigintでよいのかというところだと思う。
例えばユーザIDとして使う場合については正直なところint型で事足りると思う。
テストユーザを開発者が発行出来るような形であるならばユーザIDはbigint型にするとか、
アクティブユーザが多いサイトでのいいねボタン的なものやツイート的なものはbigintなどなど。
単純にint型で枯渇しそうということならば後で変更すればよいことだけど、
事前に色々と考えて設計することって大事なんじゃないかと思う。
0 件のコメント:
コメントを投稿