ようこそ!浜村拓夫の世界へ

    ブログ内検索

    最近の記事

    ブックマーク数の多い記事

    Blog Translation

    Powered By FC2ブログ

    Powered By FC2ブログ
    ブログやるならFC2ブログ


    FC2ブログ LOGIN

    with Ajax Amazon

    時代はBIGINT

    このエントリーを含むはてなブックマーク はてなブックマーク - 時代はBIGINT あとで読む
    MySQLのプライマリーキーで、オートインクリメントの数値を使っているテーブルがある。
    頻繁に追加・更新するマスターテーブルで、ものすごい大量の追加が発生したら、INT型では数が足りなくなるんじゃないか?という不安が出てきた。

    INT型にすべきか、BIGINT型にすべきか、それが問題だ。

    他の人たちはどうしているのかな~?と思い、さっそく検索してみた。

    ●INT型の限界
    [MySQL]INT型の最大値(IntegerのMAX値2147483647)を覚える方法 - DQNEO起業日記

    MySQLのINT型の最小値と最大値は、-2147483648~2147483647です。
    http://dev.mysql.com/doc/refman//5.1/ja/numeric-types.html

    この数字を覚えるコツをお教えしましょう。

    「2147483647」は、「21億」と覚えます。
    「21億」を分割して、「10億+10億+ちょっと」と覚えます。
    10億という数字、身近で聞いたことありませんか?
    10億人。そう、中国の人口とインドの人口です。
    2009年時点で、中国の人口は13.4億、インドの人口は11.9億です。
    中国+インドは25億人です。
    中国+インドは、INT型の最大値を超えるのです。
    例えば、あなたがTwitterのような大人気サービスを開発したとします。
    その際、会員テーブルのIDをINT型で定義したとします。
    するとどうなるでしょうか。

    インド人と中国人の全員が会員登録しようとすると、INT型では足りないということです。



    ・INT型は32ビットの数値=2の32乗=42億9496万7296を表現できる。
    ・正負の整数に割り当てると、正の整数は半分の21億4748万3648-1(ゼロを除く)=21億4748万3647。
    ・INT型のオートインクリメントの主キーに持つユーザーテーブルを作ったら、21億件のレコードを登録できる。

    これを多いと見るか、少ないと見るか?
    人類70億人が登録するWebサービスを作ってしまったら、全然足りないYO★
    …まあ、Facebookですら、まだユーザー数6億人程度というから、20億人っつったら、どんだけデカイサービスなのかと(笑)。

    でも、億じゃ足りないデータって、結構身近にあるもんだよね。
    ・IPアドレス…IPv4が枯渇して、IPv6へ移行。
    ・Google…インデックスしたURLの数は、1兆個以上とのこと。
    Google の歴史

    2008年7月
    リンクを処理する Google インデックス作成システムではユニーク URL の数が 1 兆を突破(個別のウェブページの数は 1 日何十億というスピードで増加)。



    億で十分なんて思っていたら、見積りが甘くて実は足りなくなった、なんて事態も起こりえることを考えれば、思い切って最初からBIGINTにしとけばいい。
    2000年問題みたいに、データの桁数はケチる必要はない。

    ●ストレージの問題
    MySQL の (big)int 型とストレージの微妙な関係 - にぽたん研究所

    int(10) unsigned で、auto_increment だと、1 ~ 4,294,967,295 までしかインクリメントしないから、仮にもし「1 日 100 万レコード」ずつ INSERT されたら 11 年と 9 ヶ月ちょっと経つと duplicate key が発生してしまう!!

    だからと言って、int 型だと恐いよー!ってヒヨって bigint(20) unsigned で auto_increment なんかしたとしても、1 ~ 18,446,744,073,709,551,615 までしかインクリメントしないから、仮にもし「1 日 100 億レコード」ずつ INSERT された日にゃ 5,050,546 年 11 ヶ月と 3 週間ちょいぐらいで duplicate key が発生してしまう!!!

    という現実味のない話をしましたが、このエントリを書くきっかけとなったエントリを書かれた方が、今日、某案件について「それだと int 型じゃダメなんじゃないの?」とか、またもや現実味のない事を言ってきたので、int だ bigint だなんだって、そんなアフォな話をしておりました。
    そんな中でふと気になったのが、int 型で auto_increment なカラムだけを全部ファイルにリダイレクトしたとして、どのぐらいの記憶領域が必要なのかという疑問を持ちました。

    1 ~ int 型の限界値 (4,294,967,295) まで auto_increment したテーブルでやったら…
    ファイルだけで、46,133,529,147 バイト (約 42.965 GB) の記憶領域が必要だという事です。
    数字のカラムだけなのに、すごい量ですね。。。

    1 ~ bigint 型の限界値 (18,446,744,073,709,551,615) まで auto_increment させると
    376,270,514,436,789,472,827 バイト (約 326.363 EB)
    「キロ、メガ、ギガ、テラ、ペタ、エクサ…」の「エクサ」って奴です。

    これほどまでに殺傷能力の高い bigint 型のご利用を生暖かく推奨致します。
    以上、お得意の現実味のない話ですた。



    オートインクリメントのカラムだけのテーブルで、限界までデータを詰め込むと、
    ・INT型 → 約43ギガバイト
    ・BIGINT型 → 約326エクサバイト(=33万ペタバイト=3億4221万6039テラバイト=3504億2922万4257ギガバイト)
    こんなにデカイデータを入れておくストレージがあるのかと。
    BIGINTを必要とするような多量のデータは、MySQLでキー値が足りなくなる前に、現実的にはストレージが不足するはずじゃないかと。

    まあ、でもさ、43億件を超えるレコードは現実的にありえるだろうから、テラバイトのHDDを使う機会はあるんじゃないかな?
    だとしたら、1兆個程度のレコード数に対応できるように、BIGINT型を使う価値はある。

    ●MySQLのパフォーマンス
    近年、多量のデータを扱うサービスが登場しだした。
    そして、MySQLのようなRDBではニーズを満たすことができなくて、NoSQL(いわゆるKey-Value型)のデータストアが脚光を浴びだした。
    億や兆といった単位のレコード数なら、MySQLじゃなくて、Hadoopとかを使うことになるんじゃなかろうか?
    =INT型で収まらないような件数を扱うなら、もはやMySQLじゃなくてNoSQLの出番?
    =さくらのVPSから、Amazonクラウドへ引越。

    MySQLのBIGINT(unsigned) - code:x

    18446744073709551615

    1846京
    6744兆
    0737億
    0955万
    1615

    いつも、シーケンシャルどうしようか考えます・・・・昔は「オートインクリメントは使うな」とよく言われたもんです。

    桁数があふれるから、が大きな理由みたいですが、次の桁で「垓」になるほど扱えるならオートインクリメントでいいようなきがする。

    じゃないと、クエリー二回投げるやつや・・・・カーソル操作なんてのが必要になってくるからね。

    CHAR(32)とかで、日付や時間+シリアルなんてのは、もういいのかな・・・・。

    最近は、このBIGINT(unsigned)でID指定することが多くなってきた。MySQLの場合だけど。



    BIGINT派の方、結構いるんでしょうか?
    とりあえず今作っているWebサービスは、INT(11)の代わりにBIGINT(20)を試してみよう。

    現実的には、ほとんどの場合INT型で十分なんだろうけど、BIGINTが必要になるぐらいビッグなサービスにするぞ!っていう意気込みで設計(笑)。
    BIGINTにデッカイ夢を詰め込んで、史上最大のサービスを目指せ!(・∀・)

    数値タイプの概要 - MySQL 5.1 リファレンスマニュアル

    BIGINT カラムに関して注意するべき事

    全ての演算は符号付の BIGINT か DOUBLE 値を利用しているので、ビット関数を使わない限り 9223372036854775807 (63ビット) 以上の大きい符号無し整数は利用してはいけません!もしそれをしてしまうと、 BIGINT 値から DOUBLE に変換する時、丸め誤差の為に、結果の最後のいくつかの桁に誤差が出るかもしれません。

    文字列を利用する事で、正確な整数を BIGINT カラムに格納できます。この場合MySQLは、中間倍精度表現を含まない、文字列から数値への変換を行います。



    演算に用いない=主キーにするだけならOKだな。

    MySQLによるタフなサイトの作り方MySQLによるタフなサイトの作り方
    佐藤 真人 桑野 章弘 岡田 達典 大黒 圭祐

    ソフトバンククリエイティブ 2009-09-17
    売り上げランキング : 110958

    Amazonで詳しく見る
    by G-Tools


    ビッグデータを征す クラウドの技術 Hadoop&NoSQLビッグデータを征す クラウドの技術 Hadoop&NoSQL
    ASCII.technologies集部

    アスキー・メディアワークス 2011-04-22
    売り上げランキング : 4952

    Amazonで詳しく見る
    by G-Tools

    関連記事

    コメント

    コメントの投稿


    管理者にだけ表示を許可する

    トラックバック

    トラックバックURL:
    http://hamamuratakuo.blog61.fc2.com/tb.php/648-9d328237

    FC2Ad