hacks/Domain Name Hacks
2010年08月20日
ドロップキャッチャー視点
ドロップキャッチャーは、失効ドメイン名の中に埋れている価値あるドメイン名を知りたい。
果たして、『価値』を知るにはどうしたらいいのか。
▼数値化3項目
- PageRank(Google)
- 被リンク数(Yahoo)
- サイトインデックス数(Yahoo)
これらを集計するように、クローラーを改良した。
PageRankが10
クローラーが一周した所で色々と見えて来た。
+--------------------+-----------+------------+------------+ | name | page_rank | yahoo_link | yahoo_site | +--------------------+-----------+------------+------------+ | www.google.com | 10 | 248000000 | 28900000 | | www.facebook.com | 10 | 54200000 | 17100000 | | www.cnn.com | 10 | 17800000 | 1460000 | | google.com | 10 | 7270000 | 62300000 | | www.usa.gov | 10 | 7220000 | 4180 | | facebook.com | 10 | 5570000 | 46000000 | | www.w3.org | 10 | 3450000 | 1100000 | | www.whitehouse.gov | 10 | 2220000 | 116000 | | cnn.com | 10 | 1080000 | 30400000 | | us.cnn.com | 10 | 621000 | 96200 | | www.zimbra.com | 10 | 169000 | 294000 | | w3.org | 10 | 149000 | 2220000 | | w3c.org | 10 | 18200 | 1170 | +--------------------+-----------+------------+------------+
流石PageRank10だ。ビッグネームが並んでいる。
これらが失効した時のインパクトはデカイ。
.JPはランクインしてないな。
今後、これらの数値と有効期限切れ間近ドメイン名と連動させる予定だ。
2010年05月28日
先駆者達の記録
負荷をかけている原因を研究、追求。
年明けの改善後、この一ヶ月、しばらく続いている。
自分には、この手の作業が本業でもある。
対応するccTLD数を増やすよりも、興味がある。
カラムとインデックスをじっくり観察。
約3年前、システム開発時は必要と思っていたカラムのいくつかは、今となっては不要だった。
同様に、無駄に張っていたインデックスも不要だ。
いつ、『ルビコンの決断』をするのか?
不必要なカラムとインデックスが存在すると、少なからずともシステムに影響がある。
不要データを放置しておくのも無駄だ。
いつ、どのタイミングで、設計変更を決断するのか、しないのか。
個人サービスであるがゆえ、自由気ままに判断・決断が可能だ。
何度かメンテナンスを、こっそり行って来た。
3000万パワーの破壊力
5/27未明、alter tableを決断。検証環境にてテストを行った。
プログラムレベルでは問題なし。
実行に踏み切る…行くぞ!
数時間、処理は終わらない…
仲間の存在
『FriendFeed では MySQL を使いどのようにスキーマレスのデータを保存しているのか』を発見。
大分似た状況が書き記されていた。
意図せず、その対応策が似ている。
この先のデータ増加に対する不安が、明るい光へ向いた瞬間。
誰かに対し、技術的安心感を与える存在になりたい。そう思った。
負荷対策の前後グラフを、後日後悔する予定。
空きリソースを有効活用
2010年に入ってからシステムの体質改善に注力していた。
前回のエントリ3000万レコードとの戦いに勝利の後、何をするべきかを考えていた。
実装したくても過負荷により実装を断念していたタスクを掘り起こしてみた。
『各種統計情報を出す』
こんなタスクがあった。
統計対象データは?
- ステータス情報(ok, pendingDeletion)
- 登録年月日の傾向
これらを出す為にクローラーに実装を追加したのが、今月中旬。
3000万エントリのクロールが終わると、何か面白いデータが出て来るはずだ。
夏が終わる頃、結果をまとめ、公開予定。
2010年04月23日
2010年02月11日
まずは結果から
▼MySQL queries

▼MySQL throughput

▼MySQL slow queries

▼IOstat

何に困っていたのか
- とにかくslow-queryが多い
- クローラーのクエリが刺さる
- 刺さってるとwebの閲覧が出来ない
レコードが多過ぎて、どうしようもないと思い込んでいた…
毎日観察
日々継続作業が苦ではないので、とにかく毎日観察を続けた1ヶ月間。
- slow-query元を調査
- クエリを改善出来ないか検討
- EXPLAINしてみる
解決策はアプリケーション側のSQLチューニング
- ワイルドカードを撲滅
- where句をスリム化
- 無駄なクエリを発行しないようにアプリケーションを修正
統計情報から見えるもの
- 刺さってたクエリが消え、
- クエリ数が増加し、
- IO負荷が減少
3000万レコードを支え続ける技術!
今回は良い勉強になった。
現在、システムは物凄く快適に動作中。
諦めかけていた機能追加、今後やる予定。
2010年01月23日
今更ながら
昨年末にsakuraの契約が切れるので、Amazon EC2へ論理移転を行った。
これで2度目の論理移転。
ドキュメントは未来の自分へのラブレター
開発環境構築手順。
それと、以前論理移転した時に追加した手順。
必要なものは、可能な限りDebianパッケージ化してある。
すると、3つだけで環境構築が終わる。
Debianだと楽でイイね。
$ sudo dpkg --set-selections < ./dpkg.list $ sudo apt-get install -f $ svn checkout [ repos uri ]
あとはDBのデータ同期、/etcの設定(apache,mysql)
Amazon EC2で更にオイシイ
Debianパッケージ化してあるおかげで環境構築は楽になる。
Amazon EC2だと、仮想マシンイメージを丸々バックアップが可能だ。
仮想マシンイメージをプライベートイメージとして登録しておけば、
レプリカを手軽にいくつでも起動出来る。
これ以降、ElasticfoxなどでプライベートAMI指定して起動するだけ。
apt-getを実行しなくて良い。
2009年09月20日
5文字(.com|.net)のクロールが終わった
whois.hansode.org(71/n) - whois情報1000万レコード超え から約3ヶ月。
ようやく5文字(.com|.net)のクロールが終わった。
▼2009/09/20 12:55現在
只今の蓄積WHOIS情報数:
28,655,964 WHOIS!!
さて、次は何をしようか。
2009年06月29日
気付いたら1000万超えしていた
whois.hansode.org(70/n) - whois情報1000万レコードを目指して で1000万超え宣言した。
そして、気付いたら1000万を超えていた…。
▼2009/06/29 14:45現在
只今の蓄積WHOIS情報数:
11,809,033 WHOIS!!
1文字目がa〜gまでのクロールが終わった所。
まだまだクロールし終わらないね。