某所のRDBMS書き物が停滞して久しいけれども、少しづつ書く気力も湧いてきたので頑張って書きためる意味でも草稿のような覚え書きからはじめてみる。

RDBMSというかSQLデータベースは多数の実装があり山のような機能差がある。が、実際には、比較すべき部分はそれほど無い。良く「どのRDBMSを採用すべきか」というので機能表を延々作って議論するようなのがあるが、どれもあまりにもたくさんの項目を雹に出来るため、一見仕事をしているように見せられるが、実は馬鹿げている。

主要部分のうち、自分の欲しい機能をピックアップして、それを備えているかどうか、あとは得意なOSやサポート体制、価格で決めればいい。SQLの書きやすさとかストアドプロシージャの、とかいうのは二の次である。どうせ、そのRDBMSに適したノウハウがあってそのノウハウに沿ったチューニングが必要になるという意味で、どれも同じなのだ。

ここではその「決め手になる機能」について具体的に言及したい。内容はあくまでL.starの偏見に基づいた何かであり、ブレインストーミングがてら書いているので、必ずしも完璧ではない。が、まあ参考になれば幸いである。

  • ネットワーク接続
    いわゆるスタンドアロン型かどうかの壁。通常、ネットワーク接続が必要ない場合は多数のロック競合とかマルチセッション向け機能が不要なため、わざわざネットワーク接続を前提としたサーバ型DBを使う必要はない。逆にシングルプロセスを前提にしたようなのは、ロックの競合とかで悩まされるため多数のユーザ向けにならない。

  • ACID特性の初歩 - トランザクションとWAL等のロギング
    次にポイントになるのはまじめにACIDをサポートする気があるかどうかである。はっきり言ってACIDはまじめに実装するとコストが高いので、必要でないなら使わないことが一番である。ここでのポイントはちゃんと一貫性を持ったトランザクション、そしてクラッシュリカバリ機構を持つかどうかである。
    ここで落ちる代表者はMySQL-MyISAMである。ただし、ロック競合を気にせずやってしまうMyISAMの検索性能は非常に印象的である(少なくとも昔はそうだった)
    ついでにいうと、WALを持つDBはたいていPITRとバイナリレベルのオンラインバックアップをサポートしている。ここがないと、データ巻き戻しが必要になるかもしれない、バックアップが必要になる中規模社内アプリケーションでは使いづらい。

  • ACID特性の応用 - 行ロック あるいは MVCC
    その次は、トランザクションにあわせてロックをどの程度に取るかである。テーブルロックしか取れないDBはここで脱落する。レコードレベルの書き換えを性能維持しつつ行えるため、更新に関する使いやすさが格段に増す。ここまでクリアするDBは、単一ノードによる汎用アプリケーション基盤に使える。意外なことに、スタンドアロンでも使えると言うのが売りのJava製DB、Apache Derbyはここまでクリアしている。
    ちなみに個人的には読み-書きor書き-読みでロックしないMVCCは素晴らしいと思うが、一方でデータ管理が煩雑と言う欠点を抱える。これを完全に解決しているのは見たことがない。この管理がどの程度まで作り込まれているかは、メンテナンスフリーと真に言えるかどうかの分かれ目である。
    さらに付け加えると、ロックの多寡はマルチCPU時の性能に顕著に効いてくる。つまり、ロックの少ないDBはCPUを増やすほど性能がリニアに向上する。この部分は、どの程度のマシンでどの程度の性能を要求するか、という決定のためには重要である。

  • HA機構、パーティショニング、レプリケーション、あるいは何らかのクラスタリング
    複数台数による分散の壁。数秒/数分レベルの障害検知切り替えが出来るかどうかは、高可用性を必要とするミッションクリティカルなアプリケーションの必須条件である。
    またそれとも共通するが、分散による性能向上は、これがないと、巨大Webサイトなどを構築することはまず不可能だろう。また、どの程度の台数までスケールするか、という点が、サイトをどこまで簡単に巨大化できるか、という部分に直結してくる。
    また、ここでロックの多寡も影響してくる。つまり、CPUに関するのと同じように、台数が増えるとどれだけスケールするかというデータが重要である。ちなみに、私個人としては、たいていのRDBMSクラスタはせいぜい4程度、という認識である。それ以上、たとえば数百クラスになると、最近ではBigTableやHadoop hbaseなどのRDBMSとは根本的に異なるタイプの提案がされている。
    なお、クラスタリング等に関しては、現実に自分たちの欲しているものに合致しているか検討するのは非常に難しい。一つには機能要求が非常に多岐にわたること、そしてもう一つは実装が複雑なため、望む品質に達しているとは言い難いことが多いことである。システムは出来るだけシンプルにつとめよう。複数のアドオンをごちゃごちゃと詰め込んで一見要件リストを満たすようにしても、現実にはうまくいかないものである。その点も含めて、ノウハウが難しい。


どうだろう。ここに出てきた機能は数としては決して多くないが、そのDBをユニークたらしめる部分をかなり網羅出来ていると思う。ビジネス案件ではやはりACID+HA必須、大規模Web案件では複数台動作必須、など、類型化しているのも確かであるが、プログラムとしての複雑さは上記で説明しきれると考えている。

あとはこれをどうまとめるかだが、そこは本番に取っておくと言うことで。