データベースコンサルタントのノウハウちょい見せ ACIDを超える概念か？ 新しいトランザクションの考え方 - BASE
各種インフラ技術(OS、ストレージ、ネットワーク)やオラクル製品といった話題を取り上げます。著者は小田圭二、「門外不出のOracle現場ワザ」、「絵で見てわかるOracleの仕組み」、「絵で見てわかるOS/ストレージ/ネットワーク」などの著作もあります DB使いであれば、ACID(Atomicity、Consistency、Isolation、Durability)は当たり前の考えかと思います。実は、DBMSならACIDが当たり前というのは、思いこみと言っても良いのです。少なくとも、ACID以外の考え方が存在するのは事実です。 今回は、そんな考え方である、BASE(Basically Available、Soft state、Eventually consistent)を紹介します。クラウドなどの世界で徐々に広がりつつある、トランザクションの考え方です。 この記事は、「BASE: An A
Drop ACID and Think About Data - High Scalability -
The abstract for the talk given by Bob Ippolito, co-founder and CTO of Mochi Media, Inc: Building large systems on top of a traditional single-master RDBMS data storage layer is no longer good enough. This talk explores the landscape of new technologies available today to augment your data layer to improve performance and reliability. Is your application a good fit for caches, bloom filters, bitma
エイプリルフールネタ：スケールアウトするMySQL互換RDBMS - Scale41リリース！ - Blog by Sadayuki Furuhashi
2009年4月1日は記念すべき日になったと確信しています。 内部に状態を持たないアプリケーションサーバーは、サーバーを足すだけで比較的簡単にスケールアウトすることができます。一方でACID特性が求められる用途に用いるRDBMSは、単にサーバーを足すだけでスケールアウトするのは非常に困難です。 システムが大規模になるほど徐々にRDBMSの性能が足を引っ張るようになってしまうため、高価なハードウェアに頼ってスケールアップせざるを得ないケースも多いでしょう。 データベースを水平に分割して分散させる方法では、JOIN命令が使えなくなるなどの制約が発生するため、あらかじめデータベースを分散させることを念頭に入れてアプリケーションを設計しておく必要があります。既存のアプリケーションとの互換性を維持したままデータベースを水平分割するのは困難だと言えます。 そこで、サーバーを足すことで書き込み・読み込み共
クラウド上のリレーショナルデータベースはなぜ難しいのか？ BASEとCAP定理について
今週18日からマイクロソフトがラスベガスで「MIX09」を開催します。Windows 7やWindows Azureが発表された昨年秋のPDC（Professional Developers Conference）とは異なり、MIXはWebデザイナーとWebデベロッパー向けのイベントです。 ところで、デザイナーとデベロッパー向けのイベントといえばアドビシステムズのイベントが有名。その名称はたしか「MAX」ですよね......。 さて。MIX09ではWindows Azureの料金体系の発表があるかもしれないといわれています。もし発表されれば、IT系メディアのヘッドラインを飾ることでしょう。 僕が注目しているのは、先日「マイクロソフトがクラウドでリーダーシップを握る可能性が高まる」で書いた、SQL Server完全互換の「SQL Data Services」（SDS）についての具体的な内容の
Microsoft PowerPoint - PODC-keynote
1 PODC Keynote, July 19, 2000 PODC Keynote, July 19, 2000 Towards Robust Towards Robust Distributed Systems Distributed Systems Dr. Eric A. Brewer Dr. Eric A. Brewer Professor, UC Berkeley Professor, UC Berkeley Co Co- -Founder & Chief Scientist, Inktomi Founder & Chief Scientist, Inktomi PODC Keynote, July 19, 2000 PODC Keynote, July 19, 2000 Inktomi at a Glance Inktomi at a Glance Company Overvi
Brewer’s CAP Theorem
We know three chords but you can only pick two On Friday 4th June 1976, in a small upstairs room away from the main concert auditorium, the Sex Pistols kicked off their first gig at Manchester’s Lesser Free Trade Hall. There’s some confusion as to who exactly was there in the audience that night, partly because there was another concert just six weeks later, but mostly because it’s considered to b
2009-02-10
ACIDの代替手段としてBASEという手法を提唱している人がいることを id:nowokayさんのblogで知った。 http://d.hatena.ne.jp/nowokay/20090209#1234150066 なんか気になったので軽く調べてたら、JTA実装である、Atomikos作ってる人が ひっかかる。CAPに関して一言あるエントリがあった。 http://guysblogspot.blogspot.com/ AtomikosはXTPも簡単だ！とか言ってるけど、なんかそれでいいのかと思うくらい 単純なソリューションになってるが。 http://guysblogspot.blogspot.com/2008/11/atomikos-for-xtp-transactions-for.html BASEがきちんとわかってないのできちんと読む必要がある。 中身をおさえる必要がありそうなら、
L'eclat des jours(2008-11-20)
_ ACIDからBASE ちょっと勉強。 BASE：ACIDの代わりをどうぞ 要約(のつもりだったがのりで)抄訳：（誤読は十分あり得る） これまでは垂直拡散（うまい訳はなんだろう？ vertical scaling）ってのがひとつの方法だった。よりパワフルなマシンへ移行するという道筋だ。何より簡単だってのがいいところ。でも、問題がある。どこまででもでかくできるわけでもないし、何より金食い虫だ。 それに対して水平拡散（horizontal scaling）ってのもある。いや、でもこれは複雑になる。この場合は、2次元で考えるといいね。横方向は機能分割。縦方向は断片化だ。Oracleのパーティショニングあたりとかかな。 機能分割はいいんだけど、そうなると1つのトランザクションが複数のデータベースサーバーをまたがる必要が出てくる。 エリック?ブルーワっていうバークレーの先生で、インクトミの首席サイ
EventuallyConsistent - 結果整合性
EventuallyConsistent - 結果整合性 目次 この文書について 結果整合性 歴史の話 クライアント側の整合性 サーバ側の整合性 まとめ 結果整合性 この文書について Werner Vogels "Eventually Consistent" の日本語訳です. http://www.allthingsdistributed.com/2007/12/eventually_consistent.html 推敲歓迎: 誤訳, タイポ, 訳語の不統一, そのほか... 近年, データ複製の文脈で 結果整合性(eventual consistency) に関する議論が盛んだ. この記事では大規模データの複製における原則や抽象, 高可用性とデータ整合性のトレードオフに関する話題をいくつか集めてみたいと思う. 現在進行中の分野であり, 全ての定義が最初から明快であるとは思わないでほ
Eventually Consistent
Eventually ConsistentDecember 19, 2007 • 2491 words I wrote a first version of this posting on consistency models in December 2007, but I was never happy with it as it was written in haste and the topic is important enough to receive a more thorough treatment. ACM Queue asked me to revise it for use in their magazine and I took the opportunity to improve the article. I posted an update to this art
Lessons from Internet Services: ACID vs. BASE Dr. Eric A. Brewer UC Berkeley Inktomi Corporation
Dr. Eric A. Brewer UC Berkeley Inktomi Corporation 11/15/98 Click here to start
bliki: Transactionless
A couple of years ago I was talking to a couple of friends of mine who were doing some work at eBay. It's always interesting to hear about the techniques people use on high volume sites, but perhaps one of the most interesting tidbits was that eBay mostly hardly ever uses database transactions. For most people, coming into a transactionless environment is quite a shock. Using transactions is a ver
クラウド時代のトランザクション（2009-02-09 - きしだのはてな）
今のデータベースシステムでは、トランザクションはACIDという考え方が基本になってます。 これらの用語の頭文字をとってACIDです。 Atomicty 原子性：トランザクション中の処理は全部行われるか全く行われないか Consistency 一貫性：トランザクションが完了したとき、データの状態が正しい Isolation 分離性：複数のトランザクションが実行されても、完了してないトランザクションが他のトランザクションに影響しない Durability 永続性：トランザクションが完了したら、その状態は保存される。 ただ、分散システムでACIDを適用しようとすると、複数のサーバーで処理を分担させたときに一台のサーバーがこけてたらトランザクションが全く行えないとか、トランザクションマネージャーがボトルネックになってしまうとか、スケールアウトしにくくなってしまいます。 Brewerという人が、一貫
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
分散アーキテクチャにおいて一貫性と交換でスケーラビリティを手に入れる