#しばらく過疎っていたのでこっちにも書いてみよう。
#おお
#Datomic, アーキテクチャに関心が集まっているようだけれど、勝負所は(1)あれでいかにスケールさせるか(2)あるいは、あれがぴったりハマるアプリケーションをいかに見つけるか、のどっちかだと思う。
#ここ半年くらい、仕事も含めてけっこう書いて慣れてきました。言語そのものより、leinの書き方とか、maven3でビルドするように出来上がってるプロジェクトにどうやってClojureなプロジェクトを組み込むかの方がけっこう手間取りましたねぇ。
#Datomic、後者については、ライフログ的なものにぴったりかなぁ、と思ったのですが、書き込みは1ノードなので隘路になる、と読んでちょっと萎えました。
#個人的には(2)の方にかかってるかなと思う。(1)については、スケーラビリティが問題になるような用途の多くはトラディショナルなアーキテクチャでかつかつまで使ってるんで、同じような使い方を期待されるとDatomicの方が常にハンディがある状態になるんじゃないかなと。
#なるほど
#サービスとして公開したのは、ビジネス上の要求もあるんでしょうが、ソフトウェアとして配布した場合に(1)をある程度以上担保するのが難しいからかもしれないな、と思いました。
#追記があまりなくて、クエリの種類が多いようなやつだとDatomicが有利かなと思うんだけど、なめるデータ量がでかくなってクライアント側で持ちきれなくなるとがくんと性能落ちるだろうから、そういう使い方をしない、って割り切るのかなあ。なんかすごい実装してて事実上上限を感じさせないようなトリックがあったりしたら楽しいけど。
#一度書いたら変更しないよ、ってするとアーキテクチャはすごく綺麗になるんだけど、それでスケールさせようとしてくと結局壁にぶつかって、そこここに汚いハックを入れざるを得ない、って経験をよくしてるんで、そんなジレンマを軽々と飛び越えて驚かせてくれたら嬉しいなという期待はある。
#なんか観測範囲ではアーキテクチャが面白いって感想が多いんだけど、DB界隈だったらあれはみんな考えてはみたけどスケールしないなと諦めた話だと思うんだよね。だからそれが実はスケールするんだってなったとしたらその実装こそが面白い。でも「こういう使い方なら良かったのか！」って使い方が見つかる、って方が現実的にはありそう。
#そうなんですか。DB詳しくないからこんなこと考える人なんていないんじゃないかって思ってました。
#MVCCと本質は同じなんじゃないかなぁ、と。普通MVCCは履歴を持ち続けることはしないで、適当なところでsyncするわけだけど。
#あるいは、rrdのローテートしない版とか。いずれも深く考えないで印象だけですが。
#MVCCはよく分かってないですが、ClojureのSTMとは微妙に違うと思います。ClojureのSTMは各コアが変更を試みますが、DatomicではトランザクションをTransactorのみが担当するので、賢くハンドリングできれば無駄なリトライとかがなさそうな気がしています。
#私はどっちかというと裏で走ってるインデクシングの方が心配。クライアントが、特定の世代のデータだけでいろんなクエリを走らせるってだけなら、手持ちのデータでローカルにがんがんできるんだけど、「常に最新の世代のデータを見たい」ってなるとどんどん新しいインデックスをもらわないとならないでしょう。
#それは多分大丈夫で、TransactorがPeerのindexを更新してあげる仕組みがあるみたいです（live indexと言ってました）。
#そう、そこがボトルネックになるんじゃないかと。まあデータの性質によりますが。
#そうですね。
#データセットが変化しなけりゃ、インデックスって最適化の余地がたくさんあるんですが、変化すると出来ることがうんと限られるんで。某DBでも、一つのトランザクションの世代の中でいろんなクエリ走らせる時はかなり最適化かけられるんだけど、お客さんは「常に最新の世代を見せてよ」と言う。
#まーでも、クライアント側に全部載りきるインデックスの量で、かつクライアント毎に必要なインデックスが違うなら、インデクシング最適化を並列処理することになるから、そういう条件のもとでは有利だな。とかいろいろ保留がつくので、やっぱり「良い条件」を満たすキラーアプリがあるかどうかという話に戻ってきちゃうなあ。
Clojure > Archives > 2012/03/08