mysqlかpostgresqlかNoSQLか

postgresqlとmysqlとどっちを使えば良いかは、
いやっちゅーほど繰り返されてきた議論ですが、
両者とも明確なメリット＆デメリットがあり、
極論するなら、消去法で選択するしかありません。

postgresqlの場合

• insertが比較的早い
• updateを繰り返すと、性能が落ちてくる。vacuumが必要。
• vacuumするには、テーブルロックが必要。な場合がある。
• レプリケーションが未実装。
• connectは比較的遅い。

mysqlの場合

• readだけなら早い→そんな案件今時あるの？
• レプリケーションが比較的簡単＆安定→readonlyスレーブ増やして負荷分散、はよくある発想。面倒だが。
• innodb insert/updateが激遅い。
• sqlに方言がやたら多い。
• 複雑なsqlを投入すると、最適化に失敗する。と言うか最適化する気がないっぽい。
• connectは比較的早い。
• myisamは結構壊れる。(しかも普通に使っていて)
• innodbも稀に壊れる。(しかも普通に使っていて)

エンタープライズ業界なら、これの何れか、もしくはOracleでイイヤ、
って話になるでしょうけど、
ソーシャルゲームであると、データ量、時間あたりの処理量が
指数的に増大します。

テーブル分割に対する実装コストも馬鹿になりません。
であれば、NoSQLを使ってしまえ、というのは手です。

NoSQLは数有りますが、近頃実績が増えてるっぽいのが、mongodbでしょう。
http://www.infoq.com/jp/news/2010/10/4square_mongodb_outage
これらのトラブルも、過渡期であるが故です。

それにこのトラブルは、会員数300万人とかのレベルなんで、
仮にmysql/postgresqlで運用していたとしても、
別のトラブルが有ったであろう人数と言えましょう。知らないけど。

シャードの不均一化が原因だって話なんで、
最初から、細かいテーブル(コレクション)に分割してしまえば済む話かも知れません。
メモリ使用的にもその方が有利らしいし。
http://www.mongodb.org/pages/viewpage.action?pageId=18448682

こんな事が出来るのも、スキーマレス、create tableイラズだからです。

ソーシャルゲームの実装は、トモダチ1000人居るだけで大変

最近は、ソーシャルゲームが流行り？で、
作ってみようかって案件は少なくないと思いますが、
「一般的なポータルサイト」と同じように作ると、
かなり大変なことになります。

「一般的なポータルサイト」には無かった概念として、
「フレンド」が有るでしょう。
こいつのお陰で、内部の処理量が指数的に増大します。
よほど上手く作らないと、何処かがネックになります。

「ページビュー」だけで、負荷は計れない。ということです。

誰かさんがゲームを開始すると同時に、
彼のフレンドの個々の情報を取得する、
のはよくある話だと思いますが。

500人の人が、500人づつのフレンドを持っていたすると、
いきなり250000の検索をしなければならなくなります。

同時に来たら、と思うと、血の気の引く件数ですね。

どう考えても、想定してない人数です。
馬鹿正直に実装したらmysqlとかphpとか、
どっちかのメモリが足りなくなるでしょうね。

と言うわけで、ソーシャルゲームの実装の鍵は、
如何にフレンド処理をサボるか、
これに尽きるでしょう。

と言うか、「収益の出る集客」を目指すなら、
ン１０万人を最初から想定しなければならない訳で
必然、性能だけじゃなくて、テーブルのサイズの心配もしなければなりません。
テーブルパーティショニングとか、シャーディングとか、
自力で実装するには面倒臭すぎます。

バックエンドに、mysqlとかpostgresqlとかは、
ぼちぼち無理なんじゃないでしょうか。って言うか、筆者はもう勘弁してほしい。

であれば、初めから「それらの機能を内蔵したNoSQLに全部お願い」
それも手だなと。思う次第です。

携帯電話ポーチ(ケース)はなかなか良いモノがない

筆者は、携帯電話だけでも、主要3キャリア。
さらにそれに加えて、デジカメ。
最近さらに、Bモバイルwifiも導入しました。

都合、携帯電話サイズのモノが、5台。

筆者は、人間としてはかなりダラシナイ部類であり、
自分の手のひらより小さいモノは失くしやすいのです。
買ったばかりの通勤定期(当時は磁気カード)を、
尻ポケットに入れたつもりで、スカッて紛失。
というのを2ヶ月続けてヤったことがあります。
#SUICA以前の、プリペイドも何度か。
#総額、n万円は。

と言うわけで、とりあえずショルダーバッグを常に携帯して、
かならず持ち物はそこに押し込む、という運用を続けてました。
それは概ね上手く行ってました。

しかし、より大きいトートバッグに入れて通勤する場合、
これまた今度は、「優れたショルダーバッグがなかなか見つからない」
という議論に派生します。
それは別エントリにしましょう。長くなるので。

マメな人なら、バッグinバッグ等の整理手段を駆使しているでしょうが、
ダラしない筆者が真似をしてみても、ロクな事になりません。

インナーバッグを取り出そうとして、そのフラップに引っかかってた
ケータイがそのまま吹っ飛んで、変な隙間に入り込んでしばらく見つからないとか。
いや、実話です。

定期は最近では無記名SUICAで済ませているので、
残る問題は、小型モバイル機の取り回しです。

もちろん世の中、「携帯電話ポーチ」はメジャーなニーズであり、
100円ショップですら扱っていたりするのですが、
いずれも大体、フラップもしくはストラップ付き。


正直、こういうのって、開け閉めが面倒だと思うのだがどうか？

かと言って、トートバッグ系だと、逆さまにすると落ちます。
肩にトートバッグを背負ったまま、モノを拾おうと前屈、
バッグの中身がザラザラ出てくるとか。いや実話です。

内側がウレタンになっていて、ある程度密着していれば、
摩擦で落ちてこない。しかも手で取り出せる。
というのがあれば、それで解決だと思うのですが、なかなか無いですね。

一回自作してみようかと、100円ショップのケータイポーチの内側に、
サッシ隙間テープを貼ってみたのですが、あっと言う間に剥がれました。

と思って探したら、ウレタンとかでは無いのですが、
クロックスのo-dialsというホルダーが良さげ。
注文してみようか。

金を稼ぐだけが一流か

tumblr経由で、気になる記事を見つけました。

http://d.hatena.ne.jp/yaneurao/20101029

全体的に、収入ベースでの物言いが引っかかります。端的に言えば卑屈。
収入について、何かコンプレックスを持っているのだろうか？

35歳の現場の技術者が「一流の技術者になるには英語と数学を勉強しておきなさい」とか言っても私ならそんな意見にはこれっぽっちも耳を貸さない。35歳なら、もうとっくにセミリタイアしていておかしくない年齢だ。その技術者はもしかしたら本当に一流の技術者かも知れないが、ビジネスマンとしては三流だ。みんなもそういう人が居たら、「英語と数学を勉強してもあんたのようにしかなれないじゃないか！」と言ってやるといい。(そのあとどうなっても知らんけど)

この箇所で自身が述べているとおり「ビジネスマンとして一流」を「技術者として一流」を混同している。
そして、この反論を聞いた相手は、

だからオレのようにならないために忠告してるんだ。

という反論が帰ってくるに違いない。

あと、自分を天才だと思っている若者に向けて一言言っておく。君は本当に天才かも知れん。だけど、もし本当に天才なら30年後なんか見据える必要ねーじゃん。10年ほどで結果を出せるだろ。なにせ、天才なんだからさ。だから見据えるのは10年ぐらいでいいじゃん。君が社会に出てから10年も働いたら2億円ぐらい手元にあるんじゃね？もし、君が本当に天才ならな。

これも穿った見方。

世間は、「天才の扱い方を知らない」。出る杭は打たれる。
ただ社会に出ただけでは金を稼げない。
自明ですよね「金を稼ぐ天才」ではないから。
仮にそうだとすれば、それは詐欺もしくは、それに近い何かでしょう。

技術の「天才」は、世間で活躍しにくいカテゴリだと思われます。
芸能や芸術は、一目見りゃ判る。
しかし、技術系は、判らない人に見せても「魔法」にしか見えません。
#ここで論じてる「天才」ならそのくらい行かなきゃ嘘でしょう。

要するに、「社会に出る」というか「雇用される」線で、
天才が活躍するのは困難だろう。というのが筆者の解釈です。

グーグルとか、外資系なら判らんでもないけど、
それは正しく、英語と数学が必須でしょう。
「一流の技術者」が言っているとおりにね。

真逆のアプローチとしては、
現代はインターネットが普及してるので、

アピール自体は困難ではないどころか簡単です。
一番現実的なのが、iPhoneアプリでも作ってしまうことでしょう。
ものすごい奴をね。それは何かは筆者には判りませんが。

これも英語版は必須でしょう。市場が比べ物にならない。
最近は物理演算の無駄遣いが流行ってるからひょっとしたら数学も要るかもね。

と言っている筆者は、「天才に似てるらしい、天才でない何か」なので、
間違ってるかも知れません。まあ間違ってるでしょう。今貧乏なんで。

app engine 新機能色々

筆者はGoogle app engineを非仕事で常用していますが、
オフィシャルブログ追っかけはやってないので、
結構出遅れます。

一つは remote_shell_api
もう一つは datastore_admin

remote_shell_api

データストアの中身を、直接CSV形式でダウンロードできたりとか、
app.yamlに書いて損無しのremote_apiですが、

- url: /remote_api  script: $PYTHON_LIB/google/appengine/ext/remote_api/handler.p
  login: admin

恐らくその全機能をコマンドラインで試行錯誤しながら叩けるという
刺激的なツールです。

+ python2.5 ../google_appengine/remote_api_shell.py アプリケーション名
No handlers could be found for logger "google.appengine.tools.appengine_rpc"
Email: ########Password: App Engine remote_api shellPython 2.5.4 (r254:67916, Jan 20 2010, 21:44:03)
[GCC 4.4.1]The db, users, urlfetch, and memcache modules are imported.
アプリケーション名>

メッセージがチラっと出てる限り、

• memcache
• データストア
• グーグル認証

等々は使えるようです。
まあデータストアだけでも、ご飯3杯。

直ぐに思いつくのは、データストアに対する、ややこしい操作。
datastore viewで1個づつ書き換えるにはどうよ？という操作。
これをスクリプトで一括処理しちまおう。というのは誰でも考えると思います。
しかしスクリプト書いてデプロイ、を繰り返すのはかなり面倒です。

アプリケーション名> class sitedata(db.Model):...
 pass...
アプリケーション名> sitedata.all().count()
16
アプリケーション名> 

こんな感じで、(感覚的には)直接クラウドの「あっち側」をイジれます。
実際には、remote_apiが、20レコード単位っぽい感じで送受信してるので、
スピードは早くはありません。

筆者はこれで、念願の、データストア一括削除ができました。

しかし、流石のグーグル。もっと良い方法があったという。

Datastore Admin

builtins:
- datastore_admin: on

これを書いておくと、datastore adminのメニューから、
「一括削除機能」が使えます。
しかも内部で、Map/Reduceを使って削除するらしい。

データストアに、

• _AE_MR_MapreduceState
• _AE_MR_ShardState

が増えたり
MainのLogsに

• /_ah/mapreduce/worker_callbak
• /_ah/mapreduce/controller_callbak

がドンドコ増えたりとか
Map/Reduceの一端が垣間見える体験です。

大規模WEBサービスは、クラウドに倣うべき

日本国内の、主にケータイサイトの裏側は、「apacheとmysqlで構築してます」
なんて話は良く聞きますが、いずれも物理サーバを自前で置いている場合です。

最近ではamazon ec2の利用が増えているであろうと思いますが、
これを、ただ「安価なレンタルサーバ」として使うのは全面的に間違っています。

データが消えても良いことを最初から考慮して、
むしろ2分で新しいインスタンスが立ち上がることを積極的に利用するべき。

「スケーラブル」にしなければならないのに、「インスタンス1台づつ手動で立ち上げて」どうこうするのは無駄。

つまり、物理サーバとは別の運用パラダイムが必要です。
なんて話は、海外のクラウド畑ではあたりまえの話でしょう。
判ってないのは日本国内のお客さんだけ。

筆者が常用している海外のサービスは、最近ではtumblrぐらいですが、
どうも最近不安定。ポスト失敗したり。ダッシュボードが出なかったり。
リブログ主体ですから、画像の取扱いの主体が大変だろうと推測。

似て非なるtwitterは、質的にはリアルタイムチャット、
twitterのトラフィックの異常さは想像に難しくありません。

彼らの努力を見習って、同じ苦労は極力削減するべき。
この不景気、車輪の再生産をする余裕はありません。

運用面の工夫

TwitterがBitTorrentで高速にデプロイしている仕組みについて
http://www.publickey1.jp/blog/10/twitterbittorrent.html

そこでBitTorrentを使ってデプロイする「Murder」というツールを開発をした。Murderは、BitTorrentを包含して内部ネットワーク用にオプティマイズしたもの。これまで約900秒かかっていたデプロイの時間が約12秒になり、75倍も速くなった。

Twitterの大規模システム運用技術、あるいはクジラの腹の中（前編）～ログの科学的な分析と、Twitterの「ダークモード」
http://www.publickey1.jp/blog/10/twittertwitter.html

Twitterのクジラ解剖学、あるいは彼らがいかにサーバの処理能力を向上させたか
http://www.publickey1.jp/blog/10/twitter_4.html
ボトルネック調査

Twitterの大規模システム運用技術、あるいはクジラの腹の中（後編）～Twitterのサブシステム「Unicorn」「Kestrel」「Flock DB」
http://www.publickey1.jp/blog/10/twittertwitterunicornkestrelflock_db.html
ボトルネックの具体的な解消。ミドルウエアの積極的な交換。

kestrel
tiny queue system based on starling, in scala
http://github.com/robey/kestrel
タスクスケジューリングの解法(cronやatには限界があるのは周知)
memcachedの基盤を利用して、大規模分散キューを実現してる。らしい。

ストレージ面

基本的にshardingだけど、アプリケーションが個別に頑張るんじゃなくて、
RDBとの間にアダプタを挟むのが現実的。

Twitterが分散フレームワーク「Gizzard」公開！ Scalaで書かれたShardingを実現するミドルウェア
http://www.publickey1.jp/blog/10/twittergizzard_scalasharding.html

GizzardはScalaで書かれたJavaVM上で動作するミドルウェアで、PHPやRubyといったWebアプリケーションからの要求を自動的にデータベースに分散することで、大規模で可用性の高い分散データベースを容易に実現するためのものです。

なんか日本語が変。「ScalaでかかれたJavaVM」に読める。こういう書き方をする人は多いですが。

GizzardはJavaVM上で動作するミドルウェアで、Scalaで書かれてる。Webアプリケーションからの要求を、自動的にデータベースに分散することで、大規模で可用性の高い分散データベースを容易に実現するためのものです。

http://engineering.twitter.com/2010/04/introducing-gizzard-framework-for.html
http://github.com/twitter/gizzard

NoSQLは
思ったより運用実績はないみたいですね。

TwitterとDiggがNoSQLの「Cassandra」を選ぶ理由
http://www.publickey1.jp/blog/10/twitterdiggnosqlcassandra.html

Twitterが、Cassandraの本採用を断念。「いまは切り替えの時期ではない」
http://www.publickey1.jp/blog/10/twittercassandra.html

それにしても、このうちGizzardとKestrelが、Scalaで書いてるらしい。
JVMベースの、「JAVAでない言語」恐るべし。

「天才」は「便利屋」という意味かも知れない

結論から言っちゃうと
一般人が期待する「天才」は、一般人がほとんど出会うことはありません。
住んでいる世界が違いすぎるので。多分。

ソフトウエア業界で言うと、
グーグル社内には何人か居るかも知れません。
普通の大企業には中々居ません。
居たら上司は扱いにくい筈だから。

誰かが他人を「天才」と称したときは、
「彼が何をしているか私には判らない」＝「イミわかんない」

と最近は解釈しています。
穿った見方ですが、当たらずとも遠からずでしょう。

人間は、自分が理解できないものを見たときは、
理解するための努力を放棄することがままあります。

筆者の「天才」の定義は、

自分が思考していると自覚せずに、いきなり結論を導き出せる。

だと思います。
決して、

自分にはどうやってるか判らないが、何でもやってくれる人

ではありません。

誰かに「天才」呼ばわりされたら、喜ぶ前に、
何か大仕事を頼もうとしてないかを
警戒すべきでしょう。

「天才」は「便利屋」でも「魔法使い」でもない。