データベースの文書数

答えがないとわかっていながらも、何かよい答えを言ってくれる人がいるのでは・・・と回答を期待してしまう質問の１つに「Notesのデータベースは何文書まで大丈夫ですか」というのがあります。
でも、きっと本当の意味での正解は、「it depends」でしょう（つまり正解は存在しない）。

そこで、１つの指標として、事例として存在する巨大DBを参考にしてみる、というのが考えられます。残念ながら、私の周りはわりと平和的な使い方をしているため、無謀なケースはあまり知りません。知っている限り最も文書数が多いデータベースは、developerWorks上のフォーラムです。

こちら、2006年6月15日現在のステータスは以下の通り。
Notes/Domino 4 and 5 Forum (Notes1/NotesWeb)
文書数：885,938文書
DBサイズ：9,986MB
全文索引サイズ：1,573MB

実体はこれです。
http://www-10.lotus.com/ldd/46dom.nsf

大量文書を持ちながらも、わりと快適にWebでサービス提供が出来ていることを考えると、データベースの環境次第（DB設計、サーバーの環境）では、100万文書も十分にありえると思います。


さて、「文書数」というのは、ある意味「DBサイズ」よりもパフォーマンスにとっては重要で、特に文書数が多い場合「ビューの数」や「ビューの複雑さ（選択式、列の数、列式、ソートの有無、カテゴリ展開の有無、索引更新の頻度など）」には細心の注意を払わないと、ビューが開かなかったり、サーバー全体のパフォーマンスへ影響があったりします。
また、いかにビューをシンプルにしたとしても、文書数が非常に多い場合、破損時や移行時などのビューの再構築には、それなりの時間がかかるので注意が必要です。


なお、私個人の感覚では、「削除スタブ」の数もパフォーマンスに影響するのではないかと思っています。このため、新規にアプリケーションをデザインするときは、表面的な文書数だけでなく、削除運用を含めた上で、考えたほうがよいと思っています。

既にパフォーマンスに問題のあるDBを調査するときには、文書数のほかに削除スタブの数も知っておきたいところです。削除スタブの数え方はいくつかあるかと思いますが、私はサーバー上で「show database データベース名」を叩いて確認しています。

削除スタブの削除の仕方は、こちらをどうぞ。
How to purge document deletion stubs on the server immediately
もちろん、削除時は複製運用などに注意が必要です。


以上、よく問い合わせを受ける話なので、私個人が持っている意見などを書きましたが、この考えは絶対ではないと思いますし、もっと参考になる事例などもあると思います。あくまで１つの参考としてご参照下さい。またよい事例はシェアさせて頂けると幸いです。