2009年6月30日火曜日
2009年6月13日土曜日
2009年6月12日金曜日
Fusion Tables
詳細は分からないけど、非定形データベースなら、かなり画期的。
今後の動きを注意しておかなくては。
http://www.computerworld.jp/topics/google/150389.html
XMLデータベースとかあるけど速度的に使い物にならないものしかなかったからね。
今後の動きを注意しておかなくては。
http://www.computerworld.jp/topics/google/150389.html
XMLデータベースとかあるけど速度的に使い物にならないものしかなかったからね。
2009年6月7日日曜日
2009年6月5日金曜日
Google Waveは何がすごいか
※これはネタです念為
1)不定形データでのリアルタイム処理
XMLなどの非定型データ処理は一般にコストが高い。Waveの内部データはXMLもしくはXML的な構造をしているだろうが、そういうコストの高い処理をリアルタイムにやってしまう技術力とCPUパワーがGoogleすごい。
2)操作合成機
リアルタイムで並列して更新をかけると予期しない結果になるため、操作合成器を実装。というかそのうち、予測実行とか投機的実行とかも実装しちゃうんじゃね? CPUのマイクロコードじゃないんだから、というくらいすごい。その割には更新の排他制御とかあるみたいで、よくわからない。でも日本じゃIMEが握っているキー入力ストロークは確定するまでフェッチできないし、仮にフェッチしても確定するまで意味分からない。ひょっとして、サーバ側で予測入力か、変換機能実装か? Googleすげえ! というくらいすごい。
3)リアルタイム性を確保するためにHTTPのコネクションは接続したまま
つまり、1万人のユーザーがいたら1万コネクション。ミリオンのユーザーがいたらミリオンのコネクションが張りっぱなし。で、一人が複数のチャンネルというかストリームというか最終的にはオブジェクトに接続していたら、コネクションはさらに増える。netstatとか実行したらコマンド死んじゃうかも? 既存のWebサーバーではもちろんさばけないので専用サーバーを開発して対応、OSも厳しいのでOSにも手を入れるんだよね? そこまでやってしまうGoogleすごい。負荷分散とかサーバ間のオブジェクトの同期とか問題は山ほど出てくると思うが、それもたぶん技術力で本当に乗り切ってしまうだろう。Googleすごい。
ところで、そういうスペシャルなサーバーって誰にでも用意できるの?
1)不定形データでのリアルタイム処理
XMLなどの非定型データ処理は一般にコストが高い。Waveの内部データはXMLもしくはXML的な構造をしているだろうが、そういうコストの高い処理をリアルタイムにやってしまう技術力とCPUパワーがGoogleすごい。
2)操作合成機
リアルタイムで並列して更新をかけると予期しない結果になるため、操作合成器を実装。というかそのうち、予測実行とか投機的実行とかも実装しちゃうんじゃね? CPUのマイクロコードじゃないんだから、というくらいすごい。その割には更新の排他制御とかあるみたいで、よくわからない。でも日本じゃIMEが握っているキー入力ストロークは確定するまでフェッチできないし、仮にフェッチしても確定するまで意味分からない。ひょっとして、サーバ側で予測入力か、変換機能実装か? Googleすげえ! というくらいすごい。
3)リアルタイム性を確保するためにHTTPのコネクションは接続したまま
つまり、1万人のユーザーがいたら1万コネクション。ミリオンのユーザーがいたらミリオンのコネクションが張りっぱなし。で、一人が複数のチャンネルというかストリームというか最終的にはオブジェクトに接続していたら、コネクションはさらに増える。netstatとか実行したらコマンド死んじゃうかも? 既存のWebサーバーではもちろんさばけないので専用サーバーを開発して対応、OSも厳しいのでOSにも手を入れるんだよね? そこまでやってしまうGoogleすごい。負荷分散とかサーバ間のオブジェクトの同期とか問題は山ほど出てくると思うが、それもたぶん技術力で本当に乗り切ってしまうだろう。Googleすごい。
ところで、そういうスペシャルなサーバーって誰にでも用意できるの?
2009年6月4日木曜日
WILLCOM CORE 3G
http://trendy.nikkeibp.co.jp/article/news/20090604/1026727/
かなり最強っぽい。イーモバとかUQとか苦しいんじゃないのかな。
かなり最強っぽい。イーモバとかUQとか苦しいんじゃないのかな。
登録:
投稿 (Atom)