編集可能
2011年11月26日

omidとMegastoreのトランザクション戦略の違いなど

すごすぎて理解しきれなかったので未来の自分のためにまとめ。後半は僕が無知を披露しまくって教えて君してるターン。
6
分散処理に詳しいオタク @kumagi

HBaseの上でトランザクションが可能って事は僕の研究とかなり衝突する可能性がある…なんでこの効率の悪い地平に来るのか分からないけれど他に観測したのはインテック社のびびでばびでぶーとGAEでのSlim3

2011-11-25 09:38:30
oza @oza_x86

@kumagi パッと見た感じ、megastore と同じなのかなぁ.

2011-11-25 23:15:27
分散処理に詳しいオタク @kumagi

@oza_x86 megastoreを知らないので今度技術交流しましょう!!

2011-11-25 23:26:10
Hideyuki Kawashima @h_kaw

@oza_x86 @kumagi Megastoreは完全にシリアライザブルなACID特性を細粒度に分割されたパーティション中のデータに対して提供します.また,Megastoreではentity groupなるグループを作成します.

2011-11-25 23:36:40
Hideyuki Kawashima @h_kaw

@h_kaw @oza_x86 @kumagi 同一entity group(EG)で同一データセンター内ならばACIDトランザクション,同一EGで異なるデータセンターならば,paxosを用いてlog recordsを転送します.異なるEGの場合には 2PCを用います.

2011-11-25 23:38:12
分散処理に詳しいオタク @kumagi

@h_kaw @oza_x86 ありがとうございます。僕の研究ではシリアライザブル分離レベルでデータ全域に渡るトランザクションをSPoF無しで行います。クライアントがいつ死んでも良い仕様なのですがコミットの分類は分からないです…。

2011-11-25 23:56:23
kuenishi @kuenishi

@kumagi 何その夢のようなシステム

2011-11-25 23:59:46
分散処理に詳しいオタク @kumagi

@kuenishi ただレイテンシが高いんですよ…memcachedプロトコルの上に実装しちゃってるので一体何往復するつもりなのかという…。今日やっとマルチリーダをどうやればいいのか分かったんです…。

2011-11-26 00:07:12
Hideyuki Kawashima @h_kaw

@h_kaw @oza_x86 @kumagi HBaseの方式が似ているようでしたら御教授頂けましたら当方大変嬉しく思います.横から申し訳ありません.

2011-11-25 23:39:19
Hideyuki Kawashima @h_kaw

@oza_x86 megastoreは今年のCIDRで発表されました.当方CIDRには参加していたのですが,諸般の事情からmegastore発表日の前日に帰国せざるを得ませんでした.詳細情報をお持ちでしたら是非ご教授下さい.

2011-11-25 23:43:42
oza @oza_x86

@h_kaw @kumagi Oracle (会社名ではない)という一意なタイムスタンプを生成するサーバを用意しておいて,それをベースに楽観的なトランザクションを行うというアプローチだったと記憶しています. http://t.co/gilgjxTQ

2011-11-25 23:51:30
oza @oza_x86

@h_kaw @kumagi ぱっと見て omid と megastore が方法が同じだと思った理由は,omid のドキュメント上にまさしく Oracle サーバがあったためです.http://t.co/gilgjxTQ

2011-11-25 23:53:30
oza @oza_x86

@h_kaw @kumagi おおおっと,申し訳ないです.timestamps はどこで使っていたんでしたっけ...と思ったんですが, Oracle 使っているのは Percolator の方でした.そうですね,Megastore は 2PC と WAN対応 Paxos でした.

2011-11-26 00:01:22
oza @oza_x86

@h_kaw @kumagi Hbase にマージはされていないですが,HBase をベースに Megastore を構成しようという megalon というプロジェクトはが立ち上がっていたりします. http://t.co/6FSGsPEg

2011-11-26 00:03:20
oza @oza_x86

50,000 write transactions per second ってのは,たぶん Oracle の性能限界なんだろうなぁ. http://t.co/Gsk4RYqR

2011-11-26 00:08:51
分散処理に詳しいオタク @kumagi

@oza_x86 手元で3万トランザクションでクライアントがサチってるのでGbE以上のNICとクライアントもっといっぱいあれば勝つる!!(無茶)

2011-11-26 00:19:00
oza @oza_x86

@kumagi あいつらディスクに書くんだぜ...!

2011-11-26 00:21:30
分散処理に詳しいオタク @kumagi

@oza_x86 サーバ台数増やしていいのならまだまだスケールしてみせましょうぞ…!

2011-11-26 00:24:25
Hideyuki Kawashima @h_kaw

@oza_x86 @kumagi そうですね.percolator(P)はweb indexの差分更新を実現するために開発されましたね. P は dirty を管理するフィールドを Bigtable内部に持たせており,このフィールドがtrueになるとアプリへ通知しますね.

2011-11-26 00:06:35
Hideyuki Kawashima @h_kaw

@h_kaw @oza_x86 @kumagi Percolatorはlibraryとして実装されているため多少のオーバヘッドがかかります.たとえばロックです.Two-phase commitなどのロックに関するオーバヘッドは軽くはないと考えられています.

2011-11-26 00:07:19
Hideyuki Kawashima @h_kaw

@h_kaw @oza_x86 @kumagi Pは全体の性能を高めるためにロック解放に関して lazy なアプローチを採用してます.このアプローチはOLTPでは許されない数十秒の遅延を発生させるが,web indexでは問題ない,と論文には書かれています.まぁ古い技術ですね.

2011-11-26 00:08:19
Hideyuki Kawashima @h_kaw

@h_kaw @oza_x86 @kumagi それにしてもtwitterで記述可能文字数が少なく過ぎてホントにストレスフルですね.10000文字くらい書かせて欲しいですね.

2011-11-26 00:08:58
oza @oza_x86

@h_kaw @kumagi おっしゃるとおりで,最適ではないけれど,大規模だと割と古典的な方法がスケーラブルなんですよね.2PCなんかは良い例だと思います.

2011-11-26 00:11:44
Hideyuki Kawashima @h_kaw

@oza_x86 @kumagi ありがとうございます.しかしこのプロジェクトは立ち消えになっていますね.HBaseの上にのっけると少し難しいかもしれないですね.

2011-11-26 00:12:04
分散処理に詳しいオタク @kumagi

@h_kaw @oza_x86 あの、高度な話をしているところに割って申し訳ないのですが、2PCってクライアントが死んだらどうするのでしょうか。クライアントの離脱を設計に含むなら3PCと習ったのですが分散システムで使って平気なのですか?

2011-11-26 00:14:28
残りを読む(25)

コメント

コメントがまだありません。感想を最初に伝えてみませんか?