分散KVS上でのトランザクションについて@stakezakiさんとお話

トランザクションをサポートした単体KVSをConsistentHashingで散らしてる物で、そもそもノードを跨ぐ分散トランザクションなんて必要なかったんだよ!という設計方針という理解。違ってたら訂正してください。
11
くまぎ @kumagi

@stakezaki こんにちはよろしくお願いしますジュルリ

2012-07-14 00:37:22
くまぎ @kumagi

@stakezaki トランザクション可能でスケーラビリティのある物というと、http://t.co/pBY65urr とか http://t.co/H7u75mWU とか https://t.co/3JmJl1z5 とか知ってます。

2012-07-14 02:28:49
takezaki @stakezaki

@kumagi http://t.co/mnjw9Y00では http://t.co/EA0ULbDK を見るとMySQLのMemoryやCPU、Connectionsを調整できスケールアップできるのですが、何も考えずにやると(シャーディングしないと)いつかは破綻します。

2012-07-14 09:05:58
takezaki @stakezaki

@kumagi DBMSがボトルネックなのでシャーディング/クラスタリングするはずです。であればRDBにする必要はなくKVSだとORM省略でゼロコピーできます。トランザクションが使えて単にデータを格納することができればそれでいいはずです。http://t.co/p7N6BTSm

2012-07-14 09:13:52
くまぎ @kumagi

@stakezaki ありがとうございます。なぜDBMSがボトルネックなのか分からないです。

2012-07-14 10:40:58
takezaki @stakezaki

@kumagi DBMSでは並列度を高めるために基本コネクションを使い、それが事実上無限に取れないのでボトルネックになると理解しています。メモリやCPUの高速化、アルゴリズムの改善などで高速化は可能でも、所詮高速化できた分しかスケールしない。結局、シャーディングするしかないのでは

2012-07-14 14:47:01
takezaki @stakezaki

@kumagi http://t.co/yzhiZGJz に書いたように本当はドメインロジックがAP側に入るはずですが、総じてDBaaSはこのことがあまり考慮されていない。datomicについては、読み込みのキャッシュは効くようですが書き込みがボトルネックになるようです。

2012-07-14 09:22:24
takezaki @stakezaki

@kumagi DBを複数に分けられるかがスケールアウトのポイントになると思いますが、datomicではDBが1つなのでやはり限界がでてきます。

2012-07-14 09:25:57
くまぎ @kumagi

@stakezaki すいませんこの点を詳しくお願いします。なぜDBが1つなのか、というのが分からないです。

2012-07-14 12:53:00
takezaki @stakezaki

@kumagi DBが一つといいましたが正しくは「Transactorは単一ノードなのでライトが一定量を超えるとボトルネックになり得ます。Richのコメントによれば、この制限は他の様々な利点とのトレードオフ」とのことです。http://t.co/5YGFKKEh

2012-07-14 14:39:45
くまぎ @kumagi

@stakezaki あー、transactorがボトルネックですか…それは良くないですね。分散トランザクションしないと。

2012-07-14 20:24:40
takezaki @stakezaki

@kumagi datomicは読み出しが完全Local だから凄いとありましたが、それはそう思います。reflexworks はread/writeともにLocalです。NWは介しません。

2012-07-14 21:39:25
takezaki @stakezaki

@kumagi Google Cloud SQLは、http://t.co/joz0SevQ にも書きましたが、Datastore(KVS)と比較して際のパフォーマンス、あとはRDBの必要性ですね。私はオンライントランザクションだけ考えればRDBである必要はないという立場です。

2012-07-14 09:32:49
くまぎ @kumagi

トランザクションだからスケールしない、という考えには全力で異を唱える。shardingなんかしなくてもスケールアウトは可能だ。問題は性能が出るかどうか。

2012-07-14 12:28:46
くまぎ @kumagi

@stakezaki スケールアウト可能なデータベースで言うと http://t.co/WO5CIjAr も有ります。 念の為ですが、僕はRDBに思い入れがあるわけでもORマッパを支持するわけでもないですが、トランザクションがスケールしないとは思わないという立場です。

2012-07-14 14:00:33
takezaki @stakezaki

@kumagi 了解です。IRSは、http://t.co/Fu41qX9F によると、トランザクションサーバ内でマイクロシャーディングをするとあります。結局、シャーディングを使っていてhttp://t.co/M5Qp9y15とそっくりです。SQLではありますが。。

2012-07-14 14:42:37
くまぎ @kumagi

@stakezaki シャーディングが動的か静的かでかなり状況が変わると思うのですがNECのは静的って書いてありました?

2012-07-14 20:25:17
takezaki @stakezaki

@kumagi よくわかりませんでした。クラスタを跨ぐJOINやトランザクションで、なぜ遅くならないかも不明です。ですが、シャーディングによるクラスタ分割は基本同類とみなしています。

2012-07-14 21:20:31
takezaki @stakezaki

@kumagi 実はKVSでは無限のトランザクションに対して処理可能なものもあります。GAEのEntityGroupがそうです。atomicな行レベルを応用して実現しています。シャーディングはありません。http://t.co/GUFLowND

2012-07-14 15:07:11
takezaki @stakezaki

@kumagi 私はGAEのEntityGroupのような仕組みを実装しているRDBを知りません。他の技術もあるのかもしれませんが、それらを含めても、恐らくできていないのだろうと思っています。reflexworksはKVSでありながらシャーディングで残念なのですが将来実現したい。

2012-07-14 15:13:00
takezaki @stakezaki

@kumagi シャーディングなしで無限のトランザクションを処理する技術あったら教えてください。高速じゃなく無限。

2012-07-14 15:16:13
くまぎ @kumagi

@stakezaki http://t.co/CNHd57vn 無限の意味する所がわかりませんが、僕の修論はPaxosを使わずに分散トランザクションを実行できています。

2012-07-14 20:23:04
takezaki @stakezaki

@kumagi それはすごいですね。無限の意味はトランザクション量とデータ量のことです。無限な量は現実には存在しませんが、どんなに増えてもノード追加などでリニアにスケールできるかどうかがポイントだと思います。

2012-07-14 21:16:53
takezaki @stakezaki

@kumagi RDBではEGトランザクション考えるもなく、データ量に比例して遅くなる問題を解決しなければなりません。EGの実装はそれができないと意味がありませんね。

2012-07-14 15:37:44