スポンサーサイト

--年--月--日 --:--

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

ペンローズのインタビュー

2010年05月28日 02:07

ペンローズネタの復習

いまの子供はアインシュタインロマンが始まるまでテレビの前で待つのではなく、Youtubeを検索すればこんなのみられるわけだ。その代わり英語は必要か。子供に英語は教えないと・・・どうやって?。


・ペンローズのインタビュー


・ホーキング放射


・あとはあんまり関係ないけど、LHCをラップで紹介している動画。
スポンサーサイト

皇帝の新しい心

2010年05月26日 21:55

皇帝の新しい心―コンピュータ・心・物理法則

※20年前の本ではあるが、私的GW課題図書として読んだのでメモしておく。

誰もが直感的には違和感を感じることをひたすら突き詰めた結果を
ひとつのテーマに沿って数学、物理、哲学を駆使してまとめたすごい本。
ひとつのテーマとは「人間の心」とは何か、ということ。

違和感を感じる例として以下のようなものが挙げられていた。

 ・人の脳が計算機でシミュレート可能なら、
  計算機は心を持つのか?
  (yesと答えるのは「強いAI」という立場といわれる)

 ・物理法則が時間に対して逆転できるならどうして宇宙は
  ブラックホールと同じようにホワイトホールがたくさんないのか?
  (どうして宇宙のエントロピーは初期に低かったか?)

 ・量子力学にはU(ユニタリ発展)とR(測定による波動関数の収縮)
  があるが、測定を行うのは誰か?

 ・Rによる測定は時間反転すると不自然になる。
  「光源から光子が放出される確率が1/2」
   →「光子を測定したが、光子が放出される確率は1/2だった
     (1と分かりきっているにも関わらず)」

 ・どうして、量子力学と一般相対性理論は両立しないのか?

そして、量子力学と一般相対性理論が両立しないのは、よく言われているように
相対論の方を修正するのではなく、(それがどんなものかは分からないが、)
量子力学を正しいものに修正するべきなのではないか、と述べている。
例えばそれによって

 ・ブラックホールが情報を消滅させる代わりに、Rが情報を
  生成させ、位相空間上の流線が埋め合される。

ようなことが可能なのではないかと(かなり型破りな考え方であることを
強調した上で)提案されている。

この本の初版から20年たってこのあたりの話題はどう扱われているんだろうか…。
この本の中には、そういった問題を科学者は物理法則でなく与えられた
「初期値」の問題として興味の対象外してしまうことが多いと書いてあったが
最近はどうなのだろうか。

厚さといい扱っているテーマと言い10年前に読みたかった。今読んでも十分面白いけど。
10年前は7000円もする本は買えなかったなー。


iPhone 3GS でよくあるトラブル

2010年05月26日 20:35

iPhoneでよくあるトラブルと対処法をメモ。MMSをよく使う人ほど起りやすい?

・文字入力中にMMSのアプリが落ちる。

 →「設定」→「一般」→「リセット」
     →「キーボードの変換学習をリセット」
  (なんか学習結果が邪悪な状態にあるらしい)

・最初から入っていたアプリケーション以外(App Storeから
 ダウンロードした)の
 アプリケーションを起動すると起動後すぐに落ちる。

 →適当なアプリケーションを削除して、その後App Storeから
  適当なアプリケーションをダウンロード/インストール
  (その際にApp Storeに認証を行うおかげ?)

以上。

Introducing FlockDB(2)

2010年05月12日 03:09

Introducing FlockDBの続きを訳しながらメモ。
 前半→Introducing FlockDB (1)

「教訓」で述べられていることは参考になる。特に正常系とエラー系で同じパスを通るようにする、というのは応用出来そうなアイデア。


(続き)

書き込み処理はシステムに入力された時刻に対して冪等で可換である。
我々は操作の実行の順序によらず同じ結果を得ることができる。
故に我々は一時的なネットワークやハードウェアの故障を隠すことができ、
時間がったったあとに再実行することができる。特にこれは初期の展開に
効果的である。

可換な書き込みは新しいパーティションを育成するプロセスを単純化する。
新しいパーティションは書き込みトラフィックを即座に受け入れることができ、
同時に古いパーティションからのデータのダンプをゆっくりと背後で
受け取ることができる。ダンプが一度終わると。パーティションはすぐに
"live"かつ読み取り可能になる。

アプリケーションサーバ("flapps"という愛称)はScalaで書かれていて
ステートレスで水平にスケーラブルである。クエリの負荷が増加してきたら
データベースとは独立してアプリケーションサーバを追加することができる。
それらは非常に小さいthrift APIをクライアントに向けて公開していて、
もっとリッチなインターフェースのためにクライアントはRubyで書いている。

我々はGizzard Libraryを使ってパーティショニングレイヤーを管理している。
フォワーディングレイヤーはsource IDの範囲から物理データベースへのマッピング
を定義し、レプリケーションを同じフォワーディングアドレスに対してそのような
テーブルをツリー状に構築する事によって管理される。書き込み操作はローカルに
ジャーナリングされたあとに認識される。データベースの可用性やパフォーマンスは
Webサイトのレスポンスタイムとは分離される。

それぞれのエッジは二回保存される。ひとつは前向き(ソースIDでインデックスが
つけられ、パーティショニングされる)で、もうひとつは後ろ向き(宛先IDでインデックス
がつけられ、パーティショニングされる)である。「だれが私をフォローしているか?」
のようなクエリが「私がフォローしているのはだれ?」と同じように効率的で、
どちらも必ず同じ単一パーティションで結果を得ることができる。

最終的な結果は必要に応じて拡張できるコモディティサーバのクラスタになった。
冬の間に、我々は誰にも気づかれずに50%ほどデータベースを拡張した。
我々は現在130憶の園児を保存していており、ピークのトラフィックは
秒間2万回の書き込みと10万回の読み込みを維持している。

教訓

もとのゴールとは違うにせよ、いくつかの有用なパターンが我々の経験のあとに残った。:

・ロングテールをカットオフするために積極的なタイムアウトせよ。
あなたはシステムの不公平さを完全にふるい落とすことはできないだろう、例えば
99.9パーセンタイルにあたる問い合わせが非合理に長く待たされるなど。もし複数の
ステートレスなアプリケーションサーバがあったら、あなたは合理的な時間が経った
クライアントを切断し、別のアプリケーションサーバを試す機会を与えることができる。
・すべてのケースをエラーケースとせよ。
または、別の言い方をするとエラーでも通常動作と同じコードのパスを使うようにせよ。
非常事態のみに使われるあまりテストされていないモジュールを作っては
いけない。少なくとも新しいことに挑戦するような感覚になる。我々は
すべての書き込み操作をローカルにキューに入れている(Kestrelをライブラリとして
使っている)、そしてそれらが失敗すれば分離されたエラーキューに投げられる。
このエラーキューは書き込みキューに周期的にフラッシュバックされ、つまり
リトライは最初の実行時と同じコードのパスを通る。
・はじめのうちは何も無意識に実行するな。
たくさんの計器やレバーを与え、一度現れたパターンはスクリプトによる自動化する。
FlockDBはそれぞれの異なったサービス(MySQLやKestrelやThrift)に対するクエリの
レイテンシの分散を測定しタイムアウトの時間を調整することができ、それぞれの
操作のカウントをレポートする、我々はクライアントライブラリがクエリのロードを
突然二倍にしたりするのを見ることがある(または、さらなるハードウェアの追加が)。
手動インスペクションのためになんどもエラーキューを循環している書き込み操作は
ログにダンプされる。バグが発覚することがあれば、それを直して、ジョブを再投入
し、クライアントのエラーであればそれはよいバグレポートとなる。

以上。

(だんだん後半の訳がひどくなってるが・・。)

Introducing FlockDB (1)

2010年05月09日 04:12

またTwitter engineering Blogで興味のある記事があったので、適当に訳しながらメモ。

Introducing FlockDB


Twitterは人間関係のグラフをたくさん持っている。
例えば、あなたがFollowしている人全員とか、
あなたをfollowしている人全員とか。
あなたが誰からのphone notificationを受けているとか。

こういうグラフのいくつかの特徴は我々が成長する
ごとに、スケーラブルに保管するすることが難しい課題に
なってきた。たとえば、お互いのfriendship構築にリクエストと
確認を必要とするのではなく、あなたは他の誰かをfollowする
単に1方向の関係のみ構築する。またそこにはあなたを何人が
followする人数の制限がない、そのため(@apluskのような)
あるひとは100万人にfollowされたりするが、多くはほんの数人である。

Tweetを届けるために、我々はある人のfollowerが誰であるかを
素早くルックアップできなくてはならない。しかし、我々は同時に
我々は頻繁な書き込みのトラフィックをハンドリングできなくては
ならない、それはFollowerがが追加されたり除かれたり、または
スパマーが捕まって凍結されたりといった事も含む。さらに
他の操作例えば@mentionによる配達では、我々は「これらのユーザをの
両方をFollowしているのは誰?」といった集合演算を要する。
こういった特徴は伝統的なRDBでは実装するのが難しい。

奮闘

我々は初期の日々、RDBの酷使から非正規化したkey&vaklueストアを含む
ストレージレイヤーを調査した。それぞれ書き込み操作のハンドリングや
巨大な結果セットの表示のどちらかは得意だったが、両方が得意では
なかった。

数年後我々は新しいことを試す必要があることがわかってきた。
我々のゴールは以下のとおり。
・書き込みは可能な限り単純にする。
・すぐ手に入るMySQLをストレージエンジンに使う、なぜなら
 我々は通常使用や、酷使した場合や、通常起こらない事故の条件下
 におけるそれの振る舞いをよく理解していたから。
・水平分割を可能にする。つまり我々のcorpusが成長するにつれ
 データベースのハードウェアを追加できるように
・書き込みの順番が前後することを許す、または複数回繰り返して
 書き込みをすることを許す。(つまり作業が失われるよりは冗長な
 書きこみが行われる失敗の法を許す)

FlockDBがその結果だ。我々はだいたい9ヶ月前にマイグレーションを
完了し、その後前進を続けてきた。

さらなる奮闘

FlockDBはグラフデータを保管するデータベースであるが、グラフの
巡回操作には最適化されていない。その代わり巨大な隣接リスト
に最適化され読み取り書き込みが高速で、集合演算問い合わせが
取り扱える。

FlockDBはグラフを64bit整数でIDを振られたノード間の辺として保存する。
ソーシャルグラフではノードのIDはユーザIDであるが、"お気に入り"
を保管するグラフでは宛先ノードはTweetIDになる。それぞれの辺も
ソートのために64bitのpositionでマークされる。(Twitterは
"following"グラフでもタイムスタンプを用いているので、
あなたのfollowerリストは最新順に表示される。)

辺が削除された場合、実際にMySQLのレコードが削除されるわけではない。
単にstateが削除済みにマークされ、これはプライマリキーを変化させる効果が
ある(複合キーはソースID、state、position)。同様に削除されたアカウントが
あった場合はアーカイブ状態になり、後でリストアするが可能である。
(だがこれは限られた期間である、我々のterms of serviceによれば)
我々は複合主キーと各行へのインデックスを両方持っているので
すべてのクエリにひとつのインデックスで応答できる。この種の
スキーマ最適化はMySQLを輝かしくそして予測可能なパフォーマンスを
我々に与える。

「オバマ大統領をFollowしている人と、私のFollowしている人との積集合は?」
などの複雑なクエりも、単一ユーザ(「オバマ大統領をFollowしている人はだれ?」
)のクエリに分解し高速に応答することができる。データはノードにより
パーティションニングされ、クエリはインデックス化された範囲クエリを使って
それぞれ単一パーティションで応答可能である。同様に巨大な結果セットを
Limit/Offsetを使ってページングするときにもクエリはインデックスを使って
高速に応答できる。

。。。今日はここまで。



上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。