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
やり方は3つか。1つは別のところに一貫性重視の共有データを置く方法。Chubbyの戦略。もう1つは、そういうケースは"気にしない"方法。アプリケーションでがんばる。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 (ちなみに、鍵括弧内は34文字なり。68文字の半分でもこのお題で、つぶやけば座布団3枚は頂けそう。)
id:13070886957 screen_name:SamFURUKAWA
ドコモの山田社長、毎日.JPのこんな記事も、自分でつぶやけば、評価上がるのに、もったいない http://bit.ly/bd08KH