Xperia販売10万台突破。秋にはAndoroid2.1に対応予定とか

　Twitterで、気になったもの。
　idがその発言のID,screen_nameが発言した人で、下の行が発言内容

---

id:13159325677 　　 screen_name:frsyuki
@EugeneK ぜひお使いください^^; kumo-gatewayだけで対応しているシンプルな実装で、パフォーマンスへの影響はほとんどないです。

id:13150220529 　　 screen_name:frsyuki
kumofs-0.3.5リリース - expire対応。#kumofs http://bit.ly/cqp7qa

id:13140933364 　　 screen_name:frsyuki
ぉぉ。なるほど。RT @kibayos: @frsyuki ランキング問題を解くという前提なのだそうです。http://bit.ly/9DkQOY

id:13139951470 　　 screen_name:frsyuki
HBaseのようにデータのインデックスをツリー型で集中管理するのと、kumofsのようにノードの一覧表だけを集中管理するのは、それぞれどんな利害得失があるだろう。これもまた微妙。

id:13138390351 　　 screen_name:frsyuki
kumofsは"安定したネットワークの同一セグメント"を前提としてkumo-managerを冗長化しているけど…運用とハードと環境にどこまで依存できるのか。このあたり、いまいち整理できていないな…当然使い方に依るわけで、最善は選択可能なこと。

id:13137233386 　　 screen_name:frsyuki
@shot6 気にしないのはアリですよね。Cassandraは、W+R>Nでレプリカの一貫性を保証する点です。必ずデータは一発で（不可分に）最新の値に更新され、不整合が発生しない、という仮定を置いてアプリケーションを書けない。…それが必要なのかは微妙ですが。

id:13135741799 　　 screen_name:frsyuki
要求によっては、今後はクラウド事業者でも"気にしない"系が出てくる可能性も高し。自前で用意するくらいの規模なら、可用性を落とす方法が現実的か。そういう分散データストアはあるのかな。

id:13135539529 　　 screen_name:frsyuki
データセンタをまたぐ規模では、可用性が相当に重要なので、CAS操作を保証するのはかなり厳しい。クラウド事業者としては、"CAS操作は許可しない" のが、一番問題が発生しない選択肢だろう。

id:13134951972 　　 screen_name:frsyuki
Chubbyの戦略のデメリットは、スケールしにくい点。遅い。実装も大変。Cassandraの戦略は、アプリケーションが制約される。always-writableを犠牲にする方法は、可用性が落ちる。paritioning中にCAS操作を発行したときに、比較的大きな遅延が発生。

id:13134725314 　　 screen_name:frsyuki
やり方は３つか。１つは別のところに一貫性重視の共有データを置く方法。Chubbyの戦略。もう１つは、そういうケースは"気にしない"方法。アプリケーションでがんばる。CassandraやDynamoの戦略。あるいは、always-writableを犠牲にする方法。

id:13134395881 　　 screen_name:frsyuki
MVCCやSTMの発想は、おそらく分散でも非常に便利。と言うわけでCASは欲しいが、ノードが動的に増減する前提では、（厳密な）CASの実行は難しい。R+W>N ではダメ。厳密でなければOK。要求次第だけども、どんな要求があり得るんだろう。

id:13104983923 　　 screen_name:frsyuki
MessagePack vs Avro については、→こういう結果もありますょ。マイクロベンチマークなんて小手先次第…なんて言ってはいけないですハイ：http://bit.ly/71TAcY

id:13104876016 　　 screen_name:frsyuki
@repeatedly JavaのベンチマークではAvroが速いですね。Avroは文字列をUTF-8で保持するクラスを自前で持っていて、それを使ってベンチマークしているためです。Javaは普通UTF-16で持っているので、他のライブラリでは変換＋コピーが入って遅いのです。

id:13104246107 　　 screen_name:frsyuki
Distributed SEDA. kumofs (mpio+MessagePack) も Distributed SEDA だと主張する…とか。

id:13102807509 　　 screen_name:frsyuki
@railute ごめんなさいごめんなさい＞＜ それは知らないからです^^; KVSに関する私の主張は、SQLを廃してKVSを使おうというのではなく、KVSが得意とするデータにはKVSが適しているだろう、というものです。性能や運用コストetcを含めたチューニングの選択肢として。

id:13102622447 　　 screen_name:frsyuki
@kmizu 計算自体はDB側やることが多いかな、と思います（最近のNoSQLの話は別として）。その後で、DBの型から言語の型に変換するコストは発生する気がして、そのときに言語の差が出ると思いました。が、今思うと、どの言語でもほとんど同じになる気もしますね…

id:13102267461 　　 screen_name:frsyuki
@effy55 んーなるほど。それはありますね…。MessagePackの型はJSONと同じ型にしてあるので（配列・連想配列・整数・浮動小数・真偽値・nil）、APIは同じだけど実際に使うシリアライズ形式は切り替え可能、というラッパは作れるハズです。…動的な言語なら。

id:13101602538 　　 screen_name:frsyuki
なるほど。C++は学習コストがひどいw RT @masahif2: @frsyuki 後は、スクリプト言語のが敷居が低いので 1. アイデアを持ってる人が少しの勉強でスタート出来る、2.開発者を育成しやすい とかかな。習熟コストが低いのが一つのポイントな気がします。

id:13100750728 　　 screen_name:frsyuki
これは…何かハズしている気が。ブログの方が。 RT @kis: Webアプリケーションの処理とかDBでほとんど時間くわれるんだから、言語の速度とアプリケーションの速度があまり関係ないのは当然で、テンプレート処理の速度もきっとほとんど関係ない。 http://bit.ly/cEWB

id:13073541826 　　 screen_name:frsyuki
#msgpack-0.5.0 is available from the project website. Now there are retweet, facebook and other social site buttons:-) http://bit.ly/dAaUol

id:13072641905 　　 screen_name:frsyuki
MessagePack for C++ 0.5.0 リリース：http://bit.ly/csAvD9

id:13072106224 　　 screen_name:SamFURUKAWA
飯野さん、最近みつけた「ブラストビート」の活動、http://www.blastbeat.jp/ 飯野さんも彼らのメンターになって欲しいな！　@kenjieno live at http://ustre.am/3zdV

id:13071319055 　　 screen_name:SamFURUKAWA
ドコモの山田社長、決算発表会では、「Xperia販売10万台突破。秋にはAndoroid2.1に対応予定」とお話になったそうです。 http://bit.ly/8YO8yw （ちなみに、鍵括弧内は３４文字なり。６８文字の半分でもこのお題で、つぶやけば座布団３枚は頂けそう。）

id:13070886957 　　 screen_name:SamFURUKAWA
ドコモの山田社長、毎日.JPのこんな記事も、自分でつぶやけば、評価上がるのに、もったいない http://bit.ly/bd08KH

---