ショートURLの実装についての考察
ちょっとフレームワークや、言語の勉強がてら巷に広がっているショートURLのサービスを作ってみようかと思っています。
まずは、その考察です。
ショートURLというと、
「googleの検索結果URLのように長いURL」を短くしてやろうぜ！
っていうサービスです。
有名どころでは、
- googleさんが作っている「Google Url Shortener」
- twitterの「t.co」
- 老舗で一番有名だと思う「bit.ly」
などがあります。
方法としては、URLと、短くしたURLをDBに紐付けて保存しておけばいいというのは分かります。
じゃあ、この短いURLを実現するにはどうしたらいいのでしょうか？
１．URLに対してmd5などのハッシュ関数で求められた値を使用する。
これでもいいのですが、
- ハッシュ関数のハッシュ値も以外と長い
- シノニムが発生する可能性があるのでどうする？
という問題があります。
なので簡単ではありますがちょっと避けたいと思います。
２．英数字の中からランダムで、指定桁数の文字列を生成してURLを作成
これも簡単でいいですが、
- 重複チェックが必要
- 登録件数が多くなると重複が発生する可能性が増えるのでどうにかしたい。
サービスの最初はいいかもと思うのですが、登録件数が増えるにつれて6桁などにすると重複が増える
じゃあ7桁に増やすかということなのですが、このタイミングの判断が難しいのでどうしよう。
問題ですね。
じゃあこの解決方法はないのか？
３．ショートURLの候補となるURLを先にDBに登録しておいてリクエスト毎に１つずつ振り出していく
この方法が一番ベストではないかと思います。
リクエストがきたタイミングでの、
- 重複チェックも必要なし
- 桁数を変更するタイミングも6桁を使いっきったら7桁のように処理すればいい
おお中々便利じゃないですかと思います。
じゃあ、問題点はないのか？
最初に登録するデータ量はどうなんだろうか？
英語小文字(26) + 英語大文字(26) + 数字(10) ^ 6桁 = 95428956661682176000000
となりました。？？？何バイトだ？・・・とてつもない量ではないか・・・非現実的ｗ
結論
方法としては、3番目の方式を取りたいと思っています。
データ量の解決策は、最初から全てのデータを登録する必要ないだろうと言う事で必要になったら振り出す元のデータを増やしていく方式でいいのではないかなと考えています。
でも単純な文字列でもデータ量が貯まると、意外とデータ量っておおいんですね。。。
と言う事で考察終わり。
関連する記事:
- Android3.0以降でMacを接続してUSBでファイルをやり取りする方法
- Androidでの身近なNFCの利用方法 No.0（NFCタグを手に入れよう）
- DocomoのXiパケ・ホーダイ ライトに変更してきた（月額 約1,000円の節約）
- DooPHPのDemoとソースを動かしてみた感想
- PHPでのmbstringの設定
コメント 0