はじめに

　本書『RDBエンジニアでもできる！MongoDBの構築と運用入門』を手に取っていただき、ありがとうございます。

　本書は、ドキュメント指向NoSQLの代表ともいえる、MongoDBの構築そして運用の入門書です。MongoDBを扱った際に苦労した点、後になってああすればよかったと気がついた点、構築時や運用時に注意すべき点など、筆者が業務でMongoDBを扱った経験から得た知識を記載しています。

　さて、今まで筆者は技術同人誌を含め何冊か執筆してきましたが、PostgreSQL¹がメインでした²。しかし、今回は趣向を変えてNoSQLについてです。なぜNoSQL、特にMongoDBについて書くことにしたかといいますと、意外にも認知度が低いからです。

　筆者は、業務でMongoDBを扱ったことがあります。しばらくその業務からは離れていたのですが、ある日突然「トラブルが発生したから来てくれ」と、休みの日に呼び出されました。

　原因は単純なことでしたが、MongoDBの構造を知らず、運用マニュアルに沿って定型的な作業しか行わない運用チームにはわかりづらい原因でした。

　トラブルの原因を突き止めた後、筆者が運用チームに説明をしていると、その運用チームの中の1人が驚くべき発言をしました。

　「トラブルが起きてからMongoDBを使っていることを知った」

　「MongoDBを使っているところを初めて見た」

　「MongoDBなんて業務で使うことあるんだ」

　いやいや、MongoDBは確かに日本のエンタープライズ用途³では少ないかもしれませんが、NoSQLでは最も使われているデータベースですよ！？データベース全体で見ても、メジャーといっても過言ではありません。

　しかし、確かに筆者の周りにはOracle⁴やMySQL⁵、PostgreSQLを使った経験のある人はたくさんいますが、MongoDBを扱った経験がある人は少数です。だから、休日に突然呼び出しを食らったりするわけです。そのような悲劇を少しでも減らすためにはどうすればいいか？MongoDBの技術者を増やすしかありません。本書を執筆したのはそのためです。

　以上の経緯からもわかる通り、本書では「リレーショナルデータベースは使ったことがあるが、MongoDBには詳しくない人」を対象にしています。MongoDBやNoSQLについて知識や経験が豊富な方は、本書から得ることは少ないでしょう。また、本書はMongoDBの構築と運用の入門書であり、「MongoDBを使ったプログラミング」については記述していません。MongoDBを使ったプログラミングについて知りたい方は、本書を読んでも得ることは少ないと思われます。逆に、これからMongoDBを構築するけど、経験がないという方には役に立つものを目指しました。

　なお、2021年7月にMongoDB 5.0がリリースされ、本書執筆時点（2021年9月）では最新版は5.0ですが、本書ではMongoDB 4.4を対象として説明します。5.0との差異については、本文中で必要があれば触れていきます。また、本書ではLinux OSでの操作を説明しています。Windowsでの操作については説明していませんが、MongoDBのコマンドは共通しています。OSの基本的な操作や、リレーショナルデータベースの基本的な用語については説明を省きます。

表記関係について

　本書に記載されている会社名、製品名などは、一般に各社の登録商標または商標、商品名です。会社名、製品名については、本文中では©、®、™マークなどは表示していません。

免責

　本書は情報の提供のみを目的としています。本書の内容を実行・適用・運用したことで何が起きようとも、それは実行・適用・運用した人自身の責任であり、著者や関係者はいかなる責任も負いません。

第1章NoSQL概要

MongoDBは、いわゆるNoSQLのひとつということは、ご存じの方も多いでしょう。

では、NoSQLとは何でしょうか？なぜNoSQLやMongoDBが必要とされるようになったのでしょうか？

MongoDBについて説明する前に、本章では、NoSQLとはいったいどういうものかということを説明します。

1.1NoSQL登場前

　MongoDBはNoSQLのひとつです。では、NoSQLとは何か？それについて、まずはNoSQLが登場する経緯を説明します。それには、リレーショナルデータベース（以下、本書では「RDB」と書きます）の話からする必要があります。

1.1.1RDBの席巻

　NoSQLについて説明するのに、なぜRDBの話をするのかと思うかもしれませんが、NoSQLの登場はRDBがなければありえなかったからです。

　RDB登場以前にもデータベースと呼ばれるものは存在していました。しかし、RDBが登場し、その堅牢性や使い勝手のよさから過去のデータベースを駆逐し、世の中のデータベースのほとんどがRDBとなりました。単に「データベース」といえば、普通はRDBのことを指すようにまでなりました。

1.1.2RDBの壁

　RDBがデータベース界を席巻した後も、技術はどんどん進歩していきます。大容量のメモリーやディスクが当たり前となり、10年前20年前では考えられないような巨大なファイルを保存するようになりました。また、そのファイルをネットワークを通じてやり取りするなんてことも、普通に行われるようになりました。

　インターネットもISDNからADSL、そして光ファイバーを使った通信になり、大容量・高速化していきました。また、Wi-Fiも充実し、家庭の固定PCからだけではなく、モバイル端末からもいつでもどこでも通信できる環境になりました。その結果、ネットワーク上を行き来するデータの量も、一昔前とは比べ物にならないほど大容量になりました。

　当然データベースが処理するトランザクションも激増したわけですが、その増加するスピードにRDBの処理速度が追いつかなくなってきました。RDBだけでなく、データベースの使命は「データを矛盾なく安全に保存すること」です。RDBには様々な機能がありますが、どうしてもそのために速度が犠牲になるところがありました。

　また、社会が変化し必要とするデータが変化することで、保存するデータの構造も変化します。RDBはどのようなデータを格納するかあらかじめ決めてテーブルを設計する必要があり、急激な変化には弱いのも特徴です。

1.2NoSQLの登場

　そのような時代の要請として、

　・高機能じゃなくていいので

　・変化に強く

　・とにかく大量のデータを

　・高速で保存・参照できる

　ようなデータベースが求められ、実際に様々なデータベースが世に現れました。

　これらのデータベースはRDBのアーキテクチャとは異なり、また操作にSQLも使用しないため、NoSQLと呼ぶようになりました。このような経緯でNoSQLという言葉が生まれてNoSQL製品が登場したため、RDB以前のデータベースも当然SQLを使っていないわけですが、それらは普通NoSQLとは呼びません¹。

　NoSQLとは「SQLなんかいらない！」という意味ではなく、「Not Only SQL」、すなわち「SQLだけじゃない！RDBとは異なる思想でも使いやすいデータベースがあるんだ！」という意味であると、一般的に解釈されます。

1.3NoSQLの特徴

　「1.2 NoSQLの登場」で説明したNoSQLに求められた条件を満たすようなデータベースをNoSQLというわけですが、実はNoSQLという言葉に明確な定義はありません。みんなが「NoSQLとはこういうものだろう」と思っているものがNoSQLです。そしてそれは、おおむね次の特徴を持っています。

データ構造が固定ではない

RDBでは、あらかじめテーブルを設計し、どのようなデータを格納するかを決める必要があります。しかし、NoSQLの多くはデータの構造をあらかじめ決めておく必要はありません。取り込むデータの構造が変化しても大丈夫。どのようなデータ構造でも格納可能です。このことをスキーマが固定ではないとか、スキーマレスとかいったりします²。

結合操作をしない

テーブルの結合は、筆者は個人的にリレーショナルモデルの真骨頂であると思っています。しかし、結合はデータ数が増えれば増えるほど負荷の高い処理になり、性能に影響を及ぼします。そのため、速度を重視するNoSQLでは結合操作ができない製品が多いです。

スケールアウトが容易である

RDBの性能を上げようとする場合、物理メモリーを増設する、読み書きがより高速なディスクにするなど、サーバーのハードウェアを増強するのが近道です（スケールアップ）。しかし、搭載できるハードウェアにも限界がありますし、性能がいいハードウェアは高価であり、コストと性能のバランスも問題になります。NoSQLでは、データを水平に分散させることで1台あたりの負荷を下げ（スケールアウト）、性能を上げることが容易であることが多いです。1台のサーバーの性能を上げるより、そこそこの性能のサーバーを多数用意するほうが安価で容易という思想です。

トランザクション処理がない

トランザクションはRDBでデータの整合性を保つ要といえる機能ですが、トランザクションの整合性を保つために、スケールアウトが難しくなります。多くのNoSQLでは結果整合性のみを保証し、複雑なトランザクションや同時実行制御機能を持ちません。その代わりに、スケールアウトが容易な設計となっています。

　NoSQL製品の中にはトランザクションがあったり結合できたりするものもあり、全てが上記条件に当てはまるわけではありません。ですが、変化に強く、極力機能を省いて高速な処理を目指しているという特徴は共通しています。

1.4NoSQLの種類

　NoSQLはRDBと異なり、標準化された規格はありません。いくつかデータモデルが存在します。具体的にどのようなNoSQLがあるかご紹介しましょう。

1.4.1Key Value Store（KVS）

　キーとバリューの組み合わせからなるNoSQLです。キーを指定すると、それに紐付くバリューが取得できます。基本的にはキーの完全一致で検索しますが、高速で動作します。製品によってはバリューには単純な値しか入れられないものから、複雑な値を格納することができるものまであります。代表的なKVSとしては、memchached・Redisなどがあります。

1.4.2カラム指向データベース

　カラム指向データベースは、KVSより複雑なデータを持てるようにしたものです³。

　キーに対し、カラムと値を指定します。カラムは複数持つこともできます。プログラミングに慣れた人向けにたとえるなら、KVSが連想配列で、カラム指向データベースは二次元連想配列に似ているといえば、なんとなくわかるでしょうか。代表的な製品として、Apache CassandraやApache HBaseがあります。

1.4.3ドキュメント指向データベース

　ドキュメント指向データベースは、データをXMLやJSONといったドキュメントで保管するのが特徴です。

　XMLやJSONなどの規格に合っていれば、複雑なデータを扱うことができます。レコードごとに異なったデータ構造のドキュメントでも保存でき、データ構造の変化に柔軟に対応できるデータベースです。

　本書で扱うMongoDBも、このドキュメント指向データベースに該当します。代表的な製品としては、MongoDBの他にCouchbaseやAmazon DynamoDB⁴があります。

1.5NoSQLとRDBとの関係は？

　NoSQLは「Not Only SQL」のことであると説明しました。「SQLだけではない」の言葉どおり、RDBの不得意分野を補う形で使われています⁵。これ以上NoSQLが普及したとしても、RDBがなくなることは、とりあえず今のところは考えられないでしょう。

　また、NoSQLはRDBに比べてまだまだ歴史が浅く、技術を持つエンジニアもRDBに比べれば少数です。RDBのスキルを持つエンジニアに違和感なく使ってもらうためか、最近はNoSQLにもスキーマを考慮できたりSQLに似たインターフェースを採用したり、NoSQL側からRDBに機能を寄せていくこともあります。

　逆にNoSQLの台頭によってRDB側でもNoSQLの機能を取り込んでおり、主要なRDBではJSONを扱えるようになってきています。

　RDBとNoSQL、どっちがより優れているということはありません。必要なところで必要な製品を使うことが必要です。

目次