BPStudy#25「パフォーマンスとスケーラビリティのためのデータベースアーキテクチャ」 Twitter・ハッシュタグbpstudyのまとめ
私は旅行に行っていたため参加出来なかったのですが、
gihyoの方がust配信をしてくださったため、
旅先でも話を聞くことができました。
ありがとうございました&お疲れ様でした。
id:kazuhooku の話がとても素晴らしかったので聞けて良かったです。
資料と動画はじきに公開されるでしょうし、
まとめもいくつかあるようです。
(BPStudy #25 雑メモ - すぎゃーんメモ,http://mitsukuni.org/bpstudy_25.txt)
Twitterでのこのセッション絡みの発言もなかなか熱かったので、
今回はハッシュタグbpstudyの検索結果をまとめるとします。
まとめにはgist:194212 · GitHubのscriptを使用しました。
| k_taka | Hey #bpstudy test ;) (bp-study live > http://ustre.am/6r8D) |
| key3 | 明日は #bpstudy か。お初な人ばかりのはずなので楽しそう。 |
| conceal_rs | 今日の #bpstudy は結構ぎりぎりになりそうな感じ．迷わなければいいのだが |
| monjudoh | BPStudyはここでUstしますよっと #bpstudy -> bp-study on USTREAM: . All http://www.ustream.tv/channel/bp-study |
| yuroyoro | BPStudyなう #bpstudy |
| yuroyoro | おー今回からustありか! RT @monjudoh: BPStudyはここでUstしますよっと #bpstudy -> bp-study on USTREAM: . All http://bit.ly/34sQU |
| gihyojp | 本日の19時からの #bpstudy (http://bit.ly/5LPWC http://www.ustream.tv/channel/bp-study ^KT |
| PinkSweets | RT @monjudoh: BPStudyはここでUstしますよっと #bpstudy -> bp-study on USTREAM: . All http://www.ustream.tv/channel/bp-study |
| key3 | 電源の近所に陣取りました。一つ空いてます。 #bpstudy |
| katzchang | うstはまだ真っ暗？ #bpstudy |
| hirokinko | 今日は寝坊して退勤時間が遅れたので、その影響で遅刻します #bpstudy |
| tenja | また時間につかん #bpstudy |
| key3 | Hey #bpstudy Mac率高いな (bp-study live > http://ustre.am/6r8D) |
| monjudoh | まだ始まってないのか？ #bpstudy |
| key3 | #bpstudy 開始。お題「パフォーマンスとスケーラビリティのためのデータベースアーキテクチャ」 (bp-study live > http://ustre.am/6r8D) |
| monjudoh | お、はじまた？ #bpstudy |
| yuroyoro | チューニングコストの回収が問題 #bpstudy |
| Surgo | ユーストあざーす！ RT: @key3: #bpstudy 開始。お題「パフォーマンスとスケーラビリティのためのデータベースアーキテクチャ」 (bp-study live > http://ustre.am/6r8D) |
| yuroyoro | 理論上の最速値の70%が理想 #bpstudy |
| yuroyoro | 一般的にはIPCのコストがボトルネックソケット通信だと 100k tx/sec.くらい→これ以上はサーバ内の処理を詰めてもメリットは少ない→あまりサーバを単純化してもメリット小さい #bpstudy |
| katzchang | 音声が途切れるなぁ #bpstudy |
| PinkSweets | ハードを含めた最適化かー。理論値を出した上での目標値って見方でやった事無かったな #bpstudy |
| katzchang | スライド＆音声のうstはむしろありがたいです。 #bpstudy |
| Surgo | ユーストがきれちゃった #bpstudy (bp-study live > http://ustre.am/6r8D) |
| monjudoh | 確かに RT @katzchang: スライド＆音声のうstはむしろありがたいです。 #bpstudy |
| key3 | バンド幅が足りない→圧縮して転送、アクセスタイムが遅い→グループコミット（トランザクション毎のレイテンシの隠蔽） #bpstudy (bp-study live > http://ustre.am/6r8D) |
| key3 | happy optimizationの話おわり #bpstudy (bp-study live > http://ustre.am/6r8D) |
| Surgo | ゆーすと復活したー #bpstudy (bp-study live > http://ustre.am/6r8D) |
| katzchang | 大抵、解像度とコントラストにやられちゃうんですよね。 RT @monjudoh: 確かに RT @katzchang: スライド＆音声のうstはむしろありがたいです。 #bpstudy |
| yuroyoro | でもC10Kではアルゴリズム重要 SIMD(SSE) /データ圧縮/HDDへの書き込みをまとめる(Q4M)/Lock-free algorithm #bpstudy #bpstudy |
| key3 | Scalingの話開始。 #bpstudy (bp-study live > http://ustre.am/6r8D) |
| katzchang | 画質、ぎりぎり読める感じ #bpstudy |
| key3 | ムーアの法則。18ヶ月で半導体集積度が倍になる。89年、80286で2MIPS, 09年、Core2Quardで60000MIPS? #bpstudy (bp-study live > http://ustre.am/6r8D) |
| Surgo | スケーリングのお話 20年間で30000倍 by ムーアの法則 #bpstudy (bp-study live > http://ustre.am/6r8D) |
| higayasuo | スライドあんましみえなーい #bpstudy (bp-study live > http://ustre.am/6r8D) |
| key3 | ファンの法則。フラッシュメモリ、12ヶ月で倍になる。98年、4~8MB。09年、1~32GB #bpstudy (bp-study live > http://ustre.am/6r8D) |
| shohu33 | UST素敵。 #bpstudy *Tw* |
| yuroyoro | 高校生の頃40MのHDDを10万くらいでかってたなー #bpstudy |
| nekoya | 1989年にはHDD持ってなかったから、何倍しても0だお… #bpstudy |
| key3 | @higayasuo 会場の照明落とした方が良さそうな気がしますね。 #bpstudy (bp-study live > http://ustre.am/6r8D) |
| Surgo | なつかしーなー hdd の容量的に #bpstudy (bp-study live > http://ustre.am/6r8D) |
| yuroyoro | スケールしないものもある。HDDのレイテンシ(回転数) 、internetのレイテンシ。 #bpstudy |
| monjudoh | レイテンシはスケールしない #bpstudy |
| yuroyoro | USサーバへのpingが200msec。これ以上は厳しげ #bpstudy |
| tenja | ssdとかもこれから考慮か #bpstudy |
| yuroyoro | あー4Gbpsまだ読んでない＞＜ #bpstudy |
| key3 | SSDはランダムアクセスめっちゃ強いので、ストレージハードウェアとしては別のパラダイムになってしまった感がある。 #bpstudy (bp-study live > http://ustre.am/6r8D) |
| higayasuo | scaleさせるのはワープが必要 #bpstudy (bp-study live > http://ustre.am/6r8D) |
| monjudoh | 来てないでしょうねww>livedoor関係者 #bpstudy |
| gihyojp | 今回， 開始間際に安定していなかったため，この画質でお送りします。 #bpstudy ^KT (bp-study live > http://ustre.am/6r8D) |
| katzchang | 1450円でライブドアは作れない #bpstudy |
| conceal_rs | #bpstudy なう。右の一番後ろ |
| monjudoh | 今日電車の中で1/3くらい読んだ RT @yuroyoro: あー4Gbpsまだ読んでない＞＜ #bpstudy |
| yuroyoro | Plack::Impl::Standalone::PreforkHTTPパーサはCで実装。2MBの画像GET転送で10Gbps。 #bpstudy |
| key3 | アメリカで借りてるサーバ、120msecくらいで返ってくるな。200msecってもっと遠いかも? あるいは迂回しているか、ルータが遅い #bpstudy (bp-study live > http://ustre.am/6r8D) |
| Surgo | 悪いのは hdd なんじゃないの？！ #bpstudy (bp-study live > http://ustre.am/6r8D) |
| tenja | 仮想マシン間の通信はもっと高速な場合があるな #bpstudy |
| katzchang | "CPU intensive"ってなんだろ？ #bpstudy |
| yuroyoro | HDDがボトルネック。RDBMS/ファイルストレージ。SSDは部分解決策→よい策だが価格が問題。 #bpstudy |
| monjudoh | HDDランダムリードで4Gbpsを実現するには2000台必要→HDDがボトルネック #bpstudy |
| higayasuo | HDDがscaleには癌。SSDは部分解決策 #bpstudy (bp-study live > http://ustre.am/6r8D) |
| yuroyoro | HDDとCPU負荷がかかる処理(XMLのパースetc)をどうするかがscalingの課題。 #bpstudy |
| key3 | ソフトウェア製品はスケールアップ、サービスはスケールアウト。ソフトウェア製品を動作させるサーバ台数が増えると管理するのが大変。 #bpstudy (bp-study live > http://ustre.am/6r8D) |
| hirose31 | #bpstudy なう |
| higayasuo | scale outがはやってる #bpstudy (bp-study live > http://ustre.am/6r8D) |
| Surgo | スケールアウトのお話 #bpstudy (bp-study live > http://ustre.am/6r8D) |
| key3 | データ分布(?)が疎になったことでスケールアウトしやすくなった #bpstudy (bp-study live > http://ustre.am/6r8D) |
| frsyuki | kumofs^^ #bpstudy |
| monjudoh | ユーザ数：多／ユーザ間の関係：疎→スケールアウトしやすい #bpstudy |
| key3 | ウェブアプリケーションは3層構成。HTTPサーバ、APサーバ、ストレージ。 #bpstudy (bp-study live > http://ustre.am/6r8D) |
| monjudoh | Pythonスルー!! #bpstudy |
| key3 | 規模の拡大 vs ムーアの法則 #bpstudy (bp-study live > http://ustre.am/6r8D) |
| monjudoh | 全人類が60億人なのでユーザ数増加には限度がある→データ増加量には限度がある→いずれまたスケールアップの時代になる #bpstudy |
| yuroyoro | 今日の内容はものすごく濃くてついてくのが大変だ＞＜ #bpstudy |
| higayasuo | DBのscale outの基本はパーティショニング #bpstudy (bp-study live > http://ustre.am/6r8D) |
| yuroyoro | DBのスケールアウト→パーティショニング(データ単位のパーティショニングからユーザ単位のパーティショニング)→KVS(ラディカルなアプローチ) #bpstudy |
| Surgo | rdbms のパーティショニング アプリ -> ユーザ #bpstudy (bp-study live > http://ustre.am/6r8D) |
| key3 | RDBMS捨てたいですねえ #bpstudy (bp-study live > http://ustre.am/6r8D) |
| kazunori_279 | shardingは予算確保が難しい #bpstudy |
| higayasuo | DBのパーティショニングは事前設計が難しい #bpstudy (bp-study live > http://ustre.am/6r8D) |
| yuroyoro | 複数のRDBMSサーバを連携 →ロジックに基づいてRDBMSを割り当てる →問題点 → 事前の分割設計が難しい(予測が困難) → 運用開始後の再分散が困難 #bpstudy |
| cherenkov | BPStudy#25 株式会社ビープラウドが主催するWeb系技術討論の会 Hey #bpstudy (bp-study live > http://ustre.am/6r8D) |
| key3 | RDBMSというよりSQLに慣れすぎなのでしょうな。＞自分 #bpstudy (bp-study live > http://ustre.am/6r8D) |
| kagamihoge | DBA な人たちとうまいこと連携しながらアプリ開発できればいいんだけどなぁ… #bpstudy *Tw* |
| higayasuo | KVSの問題は機能は原始的な点:開発コストの増加につながる #bpstudy (bp-study live > http://ustre.am/6r8D) |
| key3 | レンジクエリサポートやリレーション部分をRDBMS、実データをKVSに持たせるアイデアってedge.ccで出てたんでしたっけ? #bpstudy (bp-study live > http://ustre.am/6r8D) |
| katzchang | KVSでORマッパって呼ぶの、違和感あるなぁ。 #bpstudy |
| monjudoh | Rがないもんね RT @katzchang: KVSでORマッパって呼ぶの、違和感あるなぁ。 #bpstudy |
| yuroyoro | →BASEモデルへの移行 →iDC内で運用する場合、Partion-toleranceは必要か? →ネットワーク冗長化、HAクラスタなどの手法で解決できる #bpstudy |
| higayasuo | O/R Mapperで生産性はあんましあがらない気がする(笑) #bpstudy (bp-study live > http://ustre.am/6r8D) |
| haru860 | きた！RDBMSと分散KVSのいいとこどり #bpstudy |
| katzchang | 慣例的なものだろうけどねぇ。Object-Valueマッパってか、ただの直列化か。 RT @monjudoh: Rがないもんね RT @katzchang: KVSでORマッパって呼ぶの、違和感あるなぁ。 #bpstudy |
| higayasuo | Incline & Pacificは動的にパーティショニング #bpstudy (bp-study live > http://ustre.am/6r8D) |
| Surgo | rdbms の動的, range-based なパーティショニング #bpstudy (bp-study live > http://ustre.am/6r8D) |
| sh2nd | ustream見始めた #bpstudy |
| yuroyoro | RDBMSとKVSのいいとこ取り→RDBMSからの動的パーティショニング→RAnge-based partionning(イテレーション、データ局所化への障害局所化)→SQLの柔軟なクエリ→局所的なトランザクション、2phase commiなど #bpstudy |
| higayasuo | RDBMSのshardってパーティショニングのこと? #bpstudy (bp-study live > http://ustre.am/6r8D) |
| kazunori_279 | shardingしたらjoinはどうやるのかなあ。。 #bpstudy |
| kentaro714 | ust見てみた。 #bpstudy |
| key3 | shardingするならJOINしない、とか。 #bpstudy (bp-study live > http://ustre.am/6r8D) |
| kazunori_279 | そうやって段々分散KVSに近づいてくきがす RT @key3: shardingするならJOINしない、とか。 #bpstudy (bp-study live > http://ustre.am/6r8D) |
| yuroyoro | eventual consitency→非同期で更新→よくスケールする→同期とかつくりこまんといけんのでメンテ面倒 #bpstudy |
| yuroyoro | 2Phase commit→2つのDBに対して同時にcommit→一貫性は確保できるがLockしなければならんのでスケール市内→2つからのレスポンスを同期するのでwaitかかる #bpstudy |
| key3 | triggerが出てくるとは… #bpstudy (bp-study live > http://ustre.am/6r8D) |
| kentaro714 | secondary indexesってなんだ？ #bpstudy |
| monjudoh | ノ >データベースのtrigger聞いたことある人 #bpstudy |
| kazunori_279 | ストアドとか最近書かないよ〜 #bpstudy |
| tooya | RT @monjudoh: 全人類が60億人なのでユーザ数増加には限度がある→データ増加量には限度がある→いずれまたスケールアップの時代になる #bpstudy |
| kentaro714 | うーん、何のセッションなんだろ？丸山センセーみたいな話が続いてるなぁ。 #bpstudy |
| monjudoh | ノ >データベースのtrigger書いたことある人 #bpstudy |
| yuroyoro | 奥さんのPCがnetbookっぽいのにmacosxが動いてるのが気になる。仮想マシン? #bpstudy |
| key3 | secondary index=primary以外のキーでのインデックスってことか？shardを跨ぐようなインデックスを生成するのが大変、と理解した。 #bpstudy (bp-study live > http://ustre.am/6r8D) |
| key3 | trigger使うとクエリ数が読みづらくなってメンテナンスがしんどくないか #bpstudy (bp-study live > http://ustre.am/6r8D) |
| katzchang | 仕事の片手間に聞ける内容じゃなくなってきたw #bpstudy |
| kentaro714 | トリガーとキューテーブルか… #bpstudy |
| kentaro714 | あぁ楽ちん、か…うーん。 #bpstudy |
| haru860 | あるDBにINSERT→トリガー(Incline)→キュー→他のDBに書き込み(eventual consistency) #BPStudy |
| monjudoh | 質疑応答：inclineはeventual consistencyの方です #bpstudy |
| monjudoh | つぶやきinsertとqueueに突っ込むのは同一transactionで、その後は非同期(queueに任せてるので) #bpstudy |
| kentaro714 | シンプルなサービスならうまくいきそうだけど、複雑なアプリで更新パスをコントロールしきれるんだろうか。 #bpstudy |
| sh2nd | MySQLのXAは事例みたことないなー #bpstudy |
| higayasuo | 分散KVSのほうが素直な気がする。SQLもshardingによって使えない機能が出てくるし #bpstudy (bp-study live > http://ustre.am/6r8D) |
| monjudoh | triggerは定義ファイルから生成している #bpstudy |
| Surgo | 見えない・・・。資料公開していただけるのを祈ろう；； #bpstudy (bp-study live > http://ustre.am/6r8D) |
| kentaro714 | 機能的な側面もそうだけど、性能面をコントロールしきれないと厳しいな。これはこれでメカニズムの1つとして持っていて良いとしても、結局はアプリケーション側での分離設計がうまくいってないとどうにもならなさそうだな。 #bpstudy |
| monjudoh | 確かに気になる RT @kentaro714: シンプルなサービスならうまくいきそうだけど、複雑なアプリで更新パスをコントロールしきれるんだろうか。 #bpstudy |
| key3 | MySQLレプリケーションはテーブル単位なのでその部分の解決方法か。＞incline #bpstudy (bp-study live > http://ustre.am/6r8D) |
| kazunori_279 | ところでIncline/PacificってOSS？有償？ #bpstudy |
| monjudoh | やっぷく亜細亜の時の死霊公開はめっちゃ早かった RT @Surgo: 見えない・・・。資料公開していただけるのを祈ろう；； #bpstudy (bp-study live > http://ustre.am/6r8D) |
| key3 | @Surgo http://bit.ly/5OAfM これかな #bpstudy (bp-study live > http://ustre.am/6r8D) |
| tenja | 複雑な更新はそもそもスケールアウト向きじゃ無いです RT @kentaro714: シンプルなサービスならうまくいきそうだけど、複雑なアプリで更新パスをコントロールしきれるんだろうか。 #bpstudy |
| yuroyoro | 定義ファイルからどのテーブルが同期されるか可視化できれば、シンプルに設計出来る気がする。というか、Inclineありきのスキーマ設計が大事ね。 #bpstudy |
| higayasuo | shardingをtriggerとqueueで自動的にやるわけね #bpstudy (bp-study live > http://ustre.am/6r8D) |
| key3 | 一理ある。 RT @yuroyoro: 定義ファイルからどのテーブルが同期されるか可視化できれば、シンプルに設計出来る気がする。というか、Inclineありきのスキーマ設計が大事ね。 #bpstudy |
| yuroyoro | 従来のリレーションからShardingの同期ってパラダイムの転換が必要だと感じた。 #bpstudy |
| key3 | Pacificの話。 #bpstudy (bp-study live > http://ustre.am/6r8D) |
| haru860 | Inclineを定義する人が苦労すれば良いんだ。たぶん良い手段はスキーマから自動生成だろうな。 #bpstudy |
| monjudoh | ナルホディウス RT @tenja: 複雑な更新はそもそもスケールアウト向きじゃ無いです RT @kentaro714: シンプルなサービスならうまくいきそうだけど、複雑なアプリで更新パスをコントロールしきれるんだろうか。 #bpstudy |
| tokibito | RT @monjudoh: ナルホディウス RT @tenja: 複雑な更新はそもそもスケールアウト向きじゃ無いです RT @kentaro714: シンプルなサービスならうまくいきそうだけど、複雑なアプリで更新パスをコントロールしきれるんだろうか。 #bpstudy |
| key3 | inclineのロック粒度は、指定のテーブル＋キューテーブルだからロックによる性能低下を最小限に抑えられるのか #bpstudy (bp-study live > http://ustre.am/6r8D) |
| kentaro714 | ん？あー…そうか、Shardingだから大丈夫なのか。勘違い。 #bpstudy |
| tenja | 結局同じ事やろうとすると、アプリで実装しなくてはならないので、inclineでまとめ、アプリがシンプルな方がいい。再統合する事もあるので #bpstudy |
| yuroyoro | RangeベースのShardingのほうがHashBaseよりベターHashベースは各ノードの負荷が均一なる→逆に、局所最適化が難しい #bpstudy |
| key3 | pacificの中身。mysqld_jumpstart, pacific_divide #bpstudy (bp-study live > http://ustre.am/6r8D) |
| buzztter | http://buzztter.com/ja ちゅいったー, mステ, チキンタツタ, [14文字] #chuitter, エアタグ, 14文字, chuitter, 帰る, #bpstudy, 無双 |
| higayasuo | dankogaiがいるとhashベースのshardingは難しい:負荷が分散できないリスクがある #bpstudy (bp-study live > http://ustre.am/6r8D) |
| key3 | うお、 #bpstudy がバズったｗ (bp-study live > http://ustre.am/6r8D) |
| tenja | 凄え #bpstudy |
| sh2nd | XtraBackupのエントリ起こしてたのこれですか。なるほろ #bpstudy |
| monjudoh | ばずった RT @buzztter: http://buzztter.com/ja ちゅいったー, mステ, チキンタツタ, [14文字] #chuitter, エアタグ, 14文字, chuitter, 帰る, #bpstudy, 無双 |
| haru860 | MySQLのホットバックアップ ExtraBackup for hot-backupを使用 →使える #bpstudy |
| yuroyoro | RT @higayasuo: dankogaiがいるとhashベースのshardingは難しい:負荷が分散できないリスクがある #bpstudy (bp-study live > http://ustre.am/6r8D) |
| bluerabbit777jp | ユーストで見始めた #bpstudy (bp-study live > http://ustre.am/6r8D) |
| yuroyoro | mysqld_jumpstartすごい便利そう #bpstudy |
| kazunori_279 | shardingの主流はhashとrangeのどちらだろう。Yahooはhashと聞いたことがある #bpstudy |
| bluerabbit777jp | 途中からでわからんなー。 #bpstudy (bp-study live > http://ustre.am/6r8D) |
| monjudoh | RT @higayasuo: dankogaiがいるとhashベースのshardingは難しい:負荷が分散できないリスクがある #bpstudy (bp-study live > http://ustre.am/6r8D) |
| Masahito | おーustだ http://www.ustream.tv/channel/bp-study #bpstudy |
| omasanori | RT @monjudoh: RT @higayasuo: dankogaiがいるとhashベースのshardingは難しい:負荷が分散できないリスクがある #bpstudy (bp-study live > http://ustre.am/6r8D) |
| higayasuo | Bigtableはrange shardingですよ #bpstudy (bp-study live > http://ustre.am/6r8D) |
| kentaro714 | なんかもっと簡単に定式化できないのだろうか。 #bpstudy |
| kazunori_279 | 稼働中に分割できるの超便利! #bpstudy |
| key3 | pacific_divideの実装強引だなｗ でも間違いがないしロバスト #bpstudy (bp-study live > http://ustre.am/6r8D) |
| sh2nd | 再配置オンラインでやるのか〜 #bpstudy |
| tenja | このソリューションはいいなぁ、アプリからDBのスケールアウトを追い出せる #bpstudy |
| monjudoh | RT @higayasuo: Bigtableはrange shardingですよ #bpstudy (bp-study live > http://ustre.am/6r8D) |
| yuroyoro | オンラインで分割ってすごいな #bpstudy |
| key3 | 似たアーキテクチャのツールを作ったが、設計が甘くて障害になって死ねた… #bpstudy (bp-study live > http://ustre.am/6r8D) |
| hirose31 | というわけで泣く泣く離脱 #bpstudy |
| Yappo | はげしく熱い #bpstudy lang:リナカフェ |
| key3 | クライアントアプリケーション側のアクセス先切り替えはどうしているんだろう？ #bpstudy (bp-study live > http://ustre.am/6r8D) |
| tokibito | 目からゆろこ RT @yuroyoro オンラインで分割ってすごいな #bpstudy |
| kentaro714 | うーむ。なんだかBKみたいに見えてしょうがないのはGoogleに毒されすぎなんだろうなぁ。 #bpstudy |
| key3 | 定義をRDBMS側とクライアントアプリケーションで共有して、コネクションオブジェクト(?)を取得するところで切り替えるのか。 #bpstudy (bp-study live > http://ustre.am/6r8D) |
| monjudoh | BKをアプリケーションコードから追い出しているのが肝ではないか? RT @kentaro714: うーむ。なんだかBKみたいに見えてしょうがないのはGoogleに毒されすぎなんだろうなぁ。 #bpstudy |
| sugyan | 会場暑いｗ #bpstudy |
| yuroyoro | 分割中の書き込みエラー処理がゆるふわでワラタw #bpstudy |
| kazunori_279 | しかしkazuhoさんみたいな人がいないと構築できなかったのがshardingの弱みだった #bpstudy |
| higayasuo | 例外が出たら犬つきの画面を出そう #bpstudy (bp-study live > http://ustre.am/6r8D) |
| monjudoh | 暑いからって全裸は駄目 RT @sugyan: 会場暑いｗ #bpstudy |
| matsunobu | M x N台のDBサーバがあって、N shards、M replicasのとき、Inclineの更新コストはM x Nになるんじゃないのかな。参照は1だけど。 #bpstudy |
| yuroyoro | 分割中のエラー画面にだすなんらかの動物が必要だということか?! #bpstudy |
| yuroyoro | RT @monjudoh: 暑いからって全裸は駄目 RT @sugyan: 会場暑いｗ #bpstudy |
| matsunobu | 大量の更新トラフィックに対してどうスケールできるかが気になる。 #bpstudy |
| haru860 | 右隅後ろの方の席の方、冷房付けてもらえませんか？ #bpstudyRT @sugyan 右隅後ろの方の席の方、冷房付けてもらえませんか？ #bpstudy |
| key3 | @IanMLewis 分割定義の解釈を共通化しておかないと盛大にバグりそうです。low layerなハンドラが返ってくれば、上側は好きに作れるのであまり気にならない #bpstudy |
| kazunori_279 | ANIMALトランザクションと名付けよう #bpstudy |
| sh2nd | システム全体のバックアップとかどうするんじゃろ #bpstudy |
| katzchang | RT @higayasuo: 例外が出たら犬つきの画面を出そう #bpstudy (bp-study live > http://ustre.am/6r8D) |
| key3 | システム全体で一貫性のあるバックアップは取得不能な気がする #bpstudy |
| haru860 | 右隅後ろの方の席の方、可能であれば、冷房調整してもらえませんか？ #bpstudy |
| kentaro714 | 前半もっと見れればよかったなー。 #bpstudy |
| key3 | Q. shardingしている場合のJOINは出来ますか? A. しないでほしい。 #bpstudy |
| haru860 | @key3 eventually consistencyですからね #bpstudy |
| Surgo | 複数ノードにまたがる join はしないでほしい #bpstudy (bp-study live > http://ustre.am/6r8D) |
| key3 | @haru860 前にバタラさんの講演をきいたとき、mixiも同様のアプローチを取っていました。 #bpstudy |
| higayasuo | システム全体のバックアップはなく、ここのノードのレプリケーションで対応ということだと思う #bpstudy (bp-study live > http://ustre.am/6r8D) |
| frsyuki | JOINするなら書き込むときに非同期で参照用のテーブルを更新すればいいかなーと思った。取得は速くなる。スケーラビリティは上がる。更新は遅くなる。データ量は増える。ACIDが欲しい場合はダメ #bpstudy |
| haru860 | 冷房を一気に２０度/強風設定にしてきた #bpstudy |
| sugyan | 冷房ついたので全裸にならずに済みました。 途中までの雑メモうp。 #bpstudy http://d.hatena.ne.jp/sugyan/20090925/1253877795 |
| key3 | 涼しくなった #bpstudy (bp-study live > http://ustre.am/6r8D) |
| sh2nd | ふむ RT @key3 システム全体で一貫性のあるバックアップは取得不能な気がする #bpstudy |
| yuroyoro | 全裸プラス RT @sugyan: 冷房ついたので全裸にならずに済みました。 途中までの雑メモうp。 #bpstudy http://bit.ly/2vjIE |
| sh2nd | ふむふむ RT @higayasuo システム全体のバックアップはなく、ここのノードのレプリケーションで対応ということだと思う #bpstudy (bp-study live > http://ustre.am/6r8D) |
| haru860 | 全裸集団になることを直前で回避した #bpstudy |
| monjudoh | 素晴らしい全裸メモ RT @sugyan: 冷房ついたので全裸にならずに済みました。 途中までの雑メモうp。 #bpstudy http://d.hatena.ne.jp/sugyan/20090925/1253877795 |
| fmfm_collector | RT sh2nd: ふむふむ RT higayasuo システム全体のバックアップはなく、ここのノードのレプリケーションで対応ということだと思う #bpstudy (bp-study live > http://ustre.am/6r8D) |
| monjudoh | 葉っぱ一枚あればいい RT @haru860: 全裸集団になることを直前で回避した #bpstudy |
| key3 | incline/pacificを利用することでどのくらいの台数までスケール出来るんだろう。 #bpstudy (bp-study live > http://ustre.am/6r8D) |
| key3 | バックアップの一貫性はshardの単位が限界かな。 #bpstudy (bp-study live > http://ustre.am/6r8D) |
| matsunobu | 全体で一貫性のあるバックアップを取るには、MySQL側でグローバルトランザクションIDの導入が必要かと。ただ、主要マスタ(1箇所で管理)の整合性が取れていれば多くの場合問題ないので、だいぶ楽になる。 #bpstudy |
| aohta | #bpstudy 死霊公開に期待 |
| matsunobu | バックアップ・リカバリ目的でスレーブを最低1個導入。shard数NならN x 2は最低限必要。 #bpstudy |
| haru860 | りょうかいっす RT: @aohta #bpstudy 死霊公開に期待 |
| kentaro714 | アプリケーションへの影響ってどんくらいあるんだろ？Perlは環境含めてよーわからん…どこからがInclineとかの話なのかも。 #bpstudy |
| sh2nd | Oracleのトリガは50回ネストするとエラーで止まるよ！ｗ #bpstudy |
| key3 | Q. incline/pacificのproduction releaseはいつですか？ A. 研究専門なので解りません! #bpstudy |
| tenja | apサーバもスケールアウトすると、自前アプリでスケールアウト実装するよりは、キューは遅くならないと思う #bpstudy |
| kentaro714 | 心から安心した。 RT @sh2nd: Oracleのトリガは50回ネストするとエラーで止まる #bpstudy |
| yuroyoro | EC2とかに乗せるとスケールのメリットと可能性確保でウマーな感じかも #bpstudy |
| buzztter | http://buzztter.com/ja 文字] via, ちゅいったー, mステ, [14文字], chuitter, perfume, チキンタツタ, 14文字, エアタグ, #bpstudy |
| key3 | 休憩入りマース。休憩後にデモ。 #bpstudy (bp-study live > http://ustre.am/6r8D) |
| matsunobu | 声がほとんど聞こえないなー #bpstudy |
| higayasuo | 2時間半一人でしゃべるのか #bpstudy (bp-study live > http://ustre.am/6r8D) |
| conceal_rs | 休憩になった #bpstudy |
| tio_finallife | みんなジャスト14字に挑戦してるのか。そうでなくちゃRT @buzztter: http://j.mp/dtLRO 文字] via, ちゅいったー, mステ, [14文字], chuitter, perfume, チキンタツタ, 14文字, エアタグ, #bpstudy |
| tenja | ただ、EC2は遠いのだよねぇ。処理が速くなった意義を食い潰す位に RT @yuroyoro: EC2とかに乗せるとスケールのメリットと可能性確保でウマーな感じかも #bpstudy |
| haru860 | Cloud Frontをうまく使えばいいですよ。RT @tenja ただ、EC2は遠いのだよねぇ。処理が速くなった意義を食い潰す位に RT @yuroyoro: EC2とかに乗せるとスケールのメリットと可能性確保でウマーな感じかも #bpstudy |
| higayasuo | .@yuroyoro EC2のようなVMを使う仕組みはDisk I/Oが遅いのでDB中心のソリューションには向かないと思う #bpstudy (bp-study live > http://ustre.am/6r8D) |
| yuroyoro | .@higayasuo .@tenja EC2だと今度はレイテンシが問題なるわけですか。難しいなー #bpstudy |
| tenja | 動的コンテンツをCloud Frontに乗っけるのはまた考えなきゃならない事が多くてw RT @haru860: Cloud Frontをうまく使えばいいですよ。 #bpstudy |
| kentaro714 | ustはじめて見たけど楽しかった。運営のみなさん本当にありがとうございます。 #bpstudy |
| haru860 | 休憩終了 #bpstudy |
| key3 | 休憩オワリ #bpstudy (bp-study live > http://ustre.am/6r8D) |
| key3 | ホスト名にmini9って入ってるから、DELL mini 9/OSXな夢を見ているのかな #bpstudy (bp-study live > http://ustre.am/6r8D) |
| tenja | 大規模VM環境は、スケールアップしてて、Diskが爆速になってる例もあるので一概には RT @higayasuo: .@yuroyoro EC2のようなVMを使う仕組みはDisk I/Oが遅いのでDB中心のソリューションには向かないと思う #bpstudy |
| key3 | inclineのデモ開始。mysqld_jumpstartしてcreate database bpstudy #bpstudy (bp-study live > http://ustre.am/6r8D) |
| monjudoh | 今日の分の #bpstudy タイムラインは旅行から帰ってきたくらいの頃にはてダに上げる所存。FirebugとFireQueryがあれば普通に抽出出来るだろうし。 |
| yuroyoro | リモートもんじゅとりんぐスゲェ RT @monjudoh: 今日の分の #bpstudy タイムラインは旅行から帰ってきたくらいの頃にはてダに上げる所存。FirebugとFireQueryがあれば普通に抽出出来るだろうし。 |
| key3 | バックアップを取得してコピー、mysqld_jumpstartによるslaveの立ち上げデモ。 #bpstudy (bp-study live > http://ustre.am/6r8D) |
| higayasuo | RT @tenja: 大規模VM環境は、スケールアップしてて、Diskが爆速になってる例もあるので一概には #bpstudy |
| haru860 | すげー #bpstudy |
| sugyan | SQLライブコーディングｗｗ #bpstudy |
| key3 | 生成されたslaveノードは立ち上がった時点でmasterからのレプリケーションを受け取る構成になる。 #bpstudy (bp-study live > http://ustre.am/6r8D) |
| tenja | RAMディスクにファイル置いて高速化して、ホットバックアップはHDDへという手もある RT @yuroyoro: .@higayasuo .@tenja EC2だと今度はレイテンシが問題なるわけですか。難しいなー #bpstudy |
| key3 | masterでcreate table, slaveにレプリケーション成功しているデモ #bpstudy (bp-study live > http://ustre.am/6r8D) |
| yuroyoro | このslaveの立ち上げだけでも十分利用価値がある #bpstudy |
| key3 | これは便利そうだなあ #bpstudy (bp-study live > http://ustre.am/6r8D) |
| yuroyoro | もうちょっと字が大きいといいなぁ #bpstudy |
| toshiak_netmark | なんかもう、いろいろすげー RT @haru860: すげー #bpstudy |
| tokibito | RT @yuroyoro このslaveの立ち上げだけでも十分利用価値がある #bpstudy |
| toshiak_netmark | jsonの設定ファイル、{}とか[]とか多くて見づらいなぁ。 #bpstudy |
| haru860 | そんなあなたにXML RT: @toshiak_netmark jsonの設定ファイル、{}とか[]とか多くて見づらいなぁ。 #bpstudy |
| key3 | inclineのコマンドラインからキューテーブル作成 #bpstudy (bp-study live > http://ustre.am/6r8D) |
| yuroyoro | Queueテーブル出来た。 Triggerはどうなってんだろ? #bpstudy |
| key3 | yamlが好きです RT @haru860: そんなあなたにXML RT: @toshiak_netmark jsonの設定ファイル、{}とか[]とか多くて見づらいなぁ。 #bpstudy |
| toshiak_netmark | 目が眩みそう。XML好きですけどねｗ RT @haru860: そんなあなたにXML RT: @toshiak_netmark jsonの設定ファイル、{}とか[]とか多くて見づらいなぁ。 #bpstudy |
| tenja | この手順はツール化できるか、そうするとかなり楽だな #bpstudy |
| tokibito | YAMLで。 RT @haru860 そんなあなたにXML RT: @toshiak_netmark jsonの設定ファイル、{}とか[]とか多くて見づらいなぁ。 #bpstudy |
| toshiak_netmark | どんだけペアプロしたら、こんなに堂々とできるようになるんだろう #bpstudy |
| key3 | キューテーブル作成と同時に、master側にはincline同作用のtriggerが適用される。 #bpstudy (bp-study live > http://ustre.am/6r8D) |
| toshiak_netmark | XMLよりもYAMLのほうがすっきりしそう。RT @tokibito: YAMLで。 RT @haru860 そんなあなたにXML RT: @toshiak_netmark jsonの設定ファイル、{}とか[]とか多くて見づらいなぁ。 #bpstudy |
| key3 | masterのtimelineテーブルにinsertする #bpstudy (bp-study live > http://ustre.am/6r8D) |
| yuroyoro | triggerの発火順序が問題になるケースはあるのかな? #bpstudy |
| toshiak_netmark | MySQLは1table 1triggerだから問題にならないtsRT @yuroyoro: triggerの発火順序が問題になるケースはあるのかな? #bpstudy |
| key3 | triggerで関連するユーザのデータにもinsertされる #bpstudy (bp-study live > http://ustre.am/6r8D) |
| yuroyoro | ナルホディウス! RT @toshiak_netmark: MySQLは1table 1triggerだから問題にならないtsRT @yuroyoro: triggerの発火順序が問題になるケースはあるのかな? #bpstudy |
| yuitowest | 奥さん楽しそう #bpstudy |
| buzztter | http://buzztter.com/ja ちゅいったー, mステ, [14文字] via, 文字] via, チキンタツタ, chuitter, 14文字, エアタグ, #bpstudy, perfume |
| key3 | inclineの転送デーモン動かしていなかったｗ #bpstudy (bp-study live > http://ustre.am/6r8D) |
| monjudoh | 1table 1triggerなのか RT @toshiak_netmark: MySQLは1table 1triggerだから問題にならないts RT @yuroyoro: triggerの発火順序が問題になるケースはあるのかな? #bpstudy |
| key3 | A better cacheの話 #bpstudy (bp-study live > http://ustre.am/6r8D) |
| yuitowest | デモおしまい #bpstudy |
| sh2nd | MySQLはinsert before triggerが1つ、insert after triggerが1つ。なのでincline使うと業務アプリはトリガ使っちゃダメ縛りが発生すると思う #bpstudy |
| tenja | 書き込みはIncline使って、複雑な読み込みは自前で実装するのが良さそうだ #bpstudy |
| key3 | inclineのアーキテクチャをどこかで見たと思ったがPostgreSQL/Slony-Iに似ている #bpstudy (bp-study live > http://ustre.am/6r8D) |
| key3 | RDBMSスケールしない→スケールするキャッシュが欲しい #bpstudy (bp-study live > http://ustre.am/6r8D) |
| chkfj | mycached #bpstudy |
| key3 | incline/pacific使えばRDBMSスケールする！→でもSQLは遅い #bpstudy (bp-study live > http://ustre.am/6r8D) |
| conceal_rs | ライブ感たっぷり #bpstudy |
| key3 | mycached: MySQLのテーブルにmemcached protocolでアクセスできる→ただしprimary keyにでのgetのみ #bpstudy (bp-study live > http://ustre.am/6r8D) |
| matsunobu | UDFでネットワークサーバを実装するという発想がすごい。 #bpstudy |
| yuroyoro | memcachプロトコルのGETのケツにフォーマット指定できるのか−。こういうの好き #bpstudy |
| tenja | テーブルによっては、JavaScriptでデータ取れるようになる？ #bpstudy |
| key3 | レスポンス形式はmemcache native, json, messagepack #bpstudy |
| key3 | レスポンス形式選べるのかっこいいな! RESTfulなweb apiのようだ #bpstudy (bp-study live > http://ustre.am/6r8D) |
| tenja | DB自体もキャッシュするから、3次キャッシュ的な？ #bpstudy |
| PinkSweets | バッテリー切れタイミング良くて吹いた #bpstudy |
| key3 | おしまい #bpstudy (bp-study live > http://ustre.am/6r8D) |
| bongole | 8888888 #bpstudy |
| monjudoh | ぱちぱちぱちぱち #bpstudy |
| sugyan | 終了ー。お疲れさまでした。 @kazuho++ #bpstudy |
| sh2nd | とてもよかった ustreamありがとうございます＞運営の方 #bpstudy |
| key3 | http://mitsukuni.org/bpstudy_25.txt メモ。必要な方どうぞ。 #bpstudy (bp-study live > http://ustre.am/6r8D) |
| Masahito | お疲れ様でした。 #bpstudy |
| matsunobu | 発表 & ustreamありがとうございました。 #bpstudy |
| chkfj | すげー面白かった、スレーブ簡単に作れるだけでもすごいとか思いました #bpstudy |
| tadayosi | あ、 @kentaro714 さんがBPStudyに参加しているようだ。 #bpstudy |
| Surgo | ありがとございます RT: @key3: @Surgo http://bit.ly/5OAfM これかな #bpstudy (bp-study live > http://ustre.am/6r8D) |
| Surgo | ゆーすとありがとございました！ #bpstudy (bp-study live > http://ustre.am/6r8D) |
| shibukawa | #bpstudy 行きたかったな。とレモン牛乳を飲みながら。 |
| cisvul | YAML... me, too!! RT @key3 yamlが好きです RT @haru860: そんなあなたにXML RT: @toshiak_netmark jsonの設定ファイル、{}とか[]とか多くて見づらいなぁ。 #bpstudy |
| MiCHiLU | #BPStudy 素晴らしい |
| kazunori_279 | @kazuho 今日は #bpstudy ありがとうございました！Incline/Pacificすごいですね。Linuxのスレッドスケーラビリティの話も面白かったです〜。 |
