MVCC(Oracle, MySQLのInnoDB, PostgreSQL)と
ロッキング・メカニズム(Microsoft SQL Server, DB2)の
2つがあることがわかったのですが、
一般的にどちらが優れているのでしょうか。
いろいろな書籍やWebの情報をあたってみたのですが、
この件については、ケースバイケースとお茶を濁している
ように見受けられます。本音のところをお聞きしたいと思います。
私はMVCCの方が優れていると思います。
ロッキング・メカニズムのように複雑なロックについて
理解する必要がありませんし、MS SQL Serverの2005では、
MVCCを実装しているようだからです。
では、ご意見お待ちしております。
一番下に書いてある説明が的を得ていて、
いくら考えてもコレだけで十分な理由に足るのではと思ってしまいますが。
読み書きがお互いをブロックしないと
運用設計の面でも、可用性は高いですよね。
稼動サポート時間が延びるとか、
レスポンスがあがるとか。
技術的に複雑、高度なのはどちらかといわれると確かに詰まります。
可用性が高い、設計しやすい
→MVCCが優れている
のは確かだとは思いますが。
手抜きというわけではないですが、
MS SQL Server 2000 も古いと思うので、
当時は単に実装できず、ズルズル今まで
来ているだけという気がしますが。
単純に、MVCCの方がロッキング・メカニズムよりも
優れていると考えて良さそうですね。
気になるのは、Microsoft SQL Server 2005で
データの一貫性を保障する場合、どちらも使えるので
どちらを使えばよいかということです。
MVCCは優れているとはいえ、実績がないので。
私もMVCCの方が使い勝手はいいと思いますが、MVCCの問題点も把握しておくべきでしょう。
上に書いたPDFの10ページ目に「組版数が増えると不要なアクセスがあるため、性能が低下する。」とあります。
また私的な見解ですが、組版を複数持つということは外部記憶を余分に必要とするということは忘れてはいけないと思います。外部記憶が潤沢に使えるようになったという背景のもと出てきた考え方ではないでしょうか?
>「組版数が増えると不要なアクセスがあるため、性能が低下する。」
なぜそうなるかというのが、いまいちピンとこないのですが、
まぁ、そういう欠点もあると認識したいと思います。
ご意見ありがとうございました。
>MVCCの特徴は問い合わせ(読み込み)ロックの獲得と、
>書き込みロックの獲得が競合しないことです
>(読み込みは書き込みをブロックしませんし、
>書き込みも読み込みをブロックしません)。
なるほど。
逆にいうと、そうなっていないロッキング・メカニズムは
手抜きの実装ということになり、そのわりには、
MS SQL Server も DB2 も支持されているのが
不思議に思ったのです。