はじめに
MongoDBは使い始めるのが簡単で、インターフェースもJSONを出し入れするだけとシンプルなため、DBMSに関して知識が少ないアプリ開発者でも簡単にアプリを開発することができます。サクッとアプリを作り、サンプルデータで動作を確認し、いざ本番データで動かしてみたら「あれ？思った以上に性能が出ない」なんてことはないでしょうか？
「MongoDBはNoSQLなんだから速い」という思い込みは危険です。MongoDBをはじめとするNoSQLは「水平分散(シャーディング)が得意で、水平分散すれば単体構成よりも速い」というのは事実ですが、単体構成が速いかどうかはチューニング次第です。また「NoSQLなんだからRDBMSより速い」という考えもよくありません。単体性能を比較した場合、どちらが速いかは単純には比較できません。
「じゃあ、性能を上げるために水平分散をしよう！」と考えるかもしれませんが、ちょっと待ってください！
意外かもしれませんが、MongoDBの大原則はできるだけシャーディングしないことです。
MongoDBのシャーディングは一見魅力的に見えますが、性能を出すためにはそれなりの設計が必要ですし、なにより運用が格段に難しくなります。特にシャーディングしたデータのバックアップは難易度が高いです。
そのため、 単体性能を最大限まで上げることが重要です。
MongoDBは複雑なクエリでなければ、一般的なハードウェアで、シャーディングなしで秒間3000～10000件程度のクエリを処理することができます。そのため、かなり大規模でない限りシャーディングは必要ありません。実際にMongoDBを使っている人の大半はシャーディングをせずに利用しています。
そこで、第1回と第2回ではMongoDBの単体性能についてじっくり説明してきます。第1回では「何が遅いのか知る」所に注力し、第2回で「なぜ遅いのか」を説明していきます。
何が遅いのかを知る
性能問題に取り組む時に最初にやるべきことは、何が遅いのかの切り分けです。私は仕事ではインフラチームですので、よくアプリケーションチームから「DBが遅いんだけどなんとかして欲しい」という相談を受けます。そう聞かれた時に真っ先に聞くのは「何の処理が遅いの？」です。
具体的には「特定のクエリの応答速度(TAT)が遅いのか」それとも「DB全体の処理性能(TPS)」が遅いのか、更にはその中で「参照が遅いのか」それとも「更新が遅いのか」、最低でもこの点は切り分ける必要があります。例えば、書き込みへのTATが遅いという状態でメモリを拡張しても、多くの場合応答速度は改善されません。
では、MongoDBで何が遅いのかを調べる方法を見て行きましょう。
