devkuma – MongoDB

MongoDB シャーディングの概要

kc@example.com (kc kim) — Wed, 19 Jan 2022 09:19:00 +0900

スケーリング(scaling)

シャーディングについて話す前に、まずスケーリングについて見てみよう。

一般的なスケーリングで言えば、システム規模が大きくなるとスケーリング、つまり拡張が必要になる。スケーリング方法は大きく「垂直スケーリング」と「水平スケーリング」の2種類に分けられる。

垂直スケーリング

垂直スケーリングは、CPU、RAM、ストレージをより高性能なものへ交換していく方法である。スケーリングは簡単だが、そもそも CPU やメモリには限界があるため、ある程度の性能限界がある。

水平スケーリング

データセットごとにシステムを分割し、複数のサーバーから並列で処理する方法である。総合的な性能は垂直スケーリングより高くできるが、スケーリングするほど複雑性が増すため管理が難しくなる。

シャーディング(sharding)とは?

シャーディングとは、データを複数サーバーに分散させる「水平スケーリング」の仕組みである。

シャーディングには大きく3つの利点がある。「読み書き処理が速くなり、性能を上げやすい」、「ストレージを増設しやすい」、「可用性が高い」である。それぞれの詳細を以下で見ていく。MongoDB は標準機能としてシャーディング、つまり水平スケーリングをサポートする。

読み書き

データをシャードクラスターに分散して保存すると、読み書き処理、つまりファイル I/O を分散処理できる。ファイルの読み書きは遅い処理であるため、これを分散することでより高速な読み書きが可能になる。また、読み書きの負荷が増えても、サーバーを増やすことで水平スケーリングできる。

ストレージ

シャードクラスターには、分割されたデータが分散して保存される。データ量が増える場合でも、サーバーを増やして水平スケーリングできる。

高可用性

シャードクラスターでは部分的な読み書きが可能である。読み書きできない場合でも、作業を実行できるシャードサーバーから取得できることがある。

シャードクラスター

MongoDB のシャーディングは、シャード、ルーター、構成サーバーという3つの構成要素から成る。それぞれの関係と説明は次のとおりである。

シャード

シャードサーバーには、コレクションを分割した断片データ、つまりチャンクを保存する。シャードサーバーはレプリカセットとして構成できる。

ルーター

mongos はクエリルーターであり、アプリケーションからシャードクラスターへのインターフェースを提供する。シャードクラスターにアクセスするときは常に mongos 経由でアクセスする。シャード化されていないコレクションであっても、必ず mongos 経由でアクセスする。

構成サーバー

シャードクラスター設定に関するメタデータを保存する。どのシャードサーバーにデータがあるかといった情報もこのサーバーに保存される。MongoDB 3.4 以降では、構成サーバーをレプリカセットとして構成する。

シャードキー

「シャードキー」とは、データを分散してシャードサーバーに保存するときにキーとして利用する情報を指す。MongoDB は「シャードキー」を使って、コレクション内のドキュメント分散を行う。

次の図は、x シャードキーで分散された簡単な例である。

… 図 …

「シャードキー」に関するポイントは次の3つである。

すべてのドキュメントに存在する不変のフィールド、またはフィールド群で構成する。
一度シャードキーを決定して分散を実行すると、シャードキーを再度変更することはできない。
シャーディングするコレクションには、シャードキーを含むインデックスが必要である。

もちろん、シャードキーの選択が性能、効率、拡張性に大きな影響を与えることは言うまでもない。シャードキーの選択が不適切であれば、上で説明したようにシャードサーバーに偏りが発生し、非効率な動作が発生する可能性がある。

チャンク

前述のように、MongoDB は「シャードキー」の値でデータ保存を分散するが、このとき「チャンク」という塊ごとにグループ化してシャードサーバーへ分散保存する。MongoDB は自動的に「チャンク」がシャードクラスター内で均等に分散されるよう移動する。

チャンクに分割し、それを各シャードへ分散保存するイメージは以下のとおりである。

… 図 …

シャードデータに対する操作制約

シャーディングされたデータ、つまりシャードデータに対する操作にはいくつかの制限がある。

group コマンドは使用できない。
代わりに aggregate なしで MapReduce を利用する。
updateOne または deleteOne では _id を指定する必要がある。
シャードキー _id が含まれていない場合はエラーが発生する。
シャーディングしたコレクションにはユニークインデックスが必要である。

シャードコレクションと非シャードコレクション

MongoDB では、シャード化するコレクションとシャード化しないコレクションを混在させることができる。シャード化するコレクションはシャードクラスターに分散保存されるが、シャード化されていないコレクションはプライマリシャードに保存される。

データ分散方法

シャード化するときの分散方法には、「ハッシュシャード」と「レンジシャード」の2つがある。

ハッシュシャード

シャードキーのハッシュ値を利用してデータ分散を行う。ハッシュを利用したシャードの場合、シャードキーの値が近くてもチャンクが散らばりやすい特徴がある。つまり、シャードキーが単調変化する場合に分散しやすい分散方法である。逆にデータが分散されやすいため、データ構造や取得方法によってはブロードキャスト操作が増える可能性もある。

レンジシャード

シャードキーの範囲に従ってデータ分散を行う。ハッシュシャードと異なり、シャードキーの値が近い場合、同じチャンク上に存在する可能性が高くなる分散方法である。シャードキーの選定が不適切であれば、せっかくシャードという分散技術を利用しようとしても、特定サーバーに負荷が偏ってしまう可能性がある。

MongoDB mongod コマンドの使い方

kc@example.com (kc kim) — Thu, 13 Jan 2022 07:57:00 +0900

mongod コマンドの基本的な主な使い方、つまりオプションを整理する。

ここで扱っているのは重要と思われるオプションだけであるため、その他の多くのオプションについては公式マニュアルを参照すること。

基本オプション

オプション	説明
`--config <filename>`, `-f <filename>`	起動オプションを含む構成ファイルを指定する。構成ファイルのパスに空白が含まれる場合は、ダブルクォート(`"`)で囲む。構成ファイルは ASCII エンコーディングを使用する。UTF-8 など ASCII 以外はサポートしない。構成ファイルと起動オプションを同時に指定した場合は、起動オプションの値が優先される。
`--port <port>`	デフォルト: 27017 MongoDB が TCP 接続を待ち受けるポート番号を指定する。
`--maxConns <number>`	MongoDB が許可する同時接続数を指定する。
`--logpath <path>`	ログファイルを出力するパスを指定する。
`--logappend`	MongoDB を再起動すると、既存ログファイルの続きとしてロギングされる。 MongoDB のデフォルトでは、再起動時に既存ログファイルをバックアップして新しいログファイルを作成する。
`--slowms <integer>`	デフォルト: 100 プロファイリングするしきい値をミリ秒で指定する。
`--profile <level>`	デフォルト: 0 データベースプロファイリングレベルを変更する。 - 0: Off。プロファイリングを行わない。 - 1: On。遅い操作のみプロファイリングを行う。 - 2: On。すべての操作をプロファイリングする。
`--auth`	データベースアクセス制御を使用する。ユーザーの設定変更は `mongo` コマンドで行う。ユーザーが存在しない場合は、`localhost` からのアクセスのみ許可される。
`--bind_ip <address>`	デフォルト: すべての接続 MongoDB が接続を受け付ける IP アドレスを指定する。
`--dbpath <path>`	デフォルト: `C:\data\db` データベースファイルを保存するストレージパスを指定する。

Windows サービスインストールオプション

オプション	説明
`--install`	MongoDB を Windows サービスに追加する。必要に応じて `--serviceName`、`--serviceDisplayName` を同時に指定する。
`--remove`	Windows サービスから MongoDB サービスを削除する。 `--serviceName` でデフォルト以外の名前をインストールした場合は、`--serviceName` を指定する必要がある。
`--serviceName <name>`	デフォルト: MongoDB サービス名を指定する。ここで指定した名前は `net start <name>`、`net stop <name>` の引数として使用される。
`--serviceDisplayName <name>`	デフォルト: MongoDB サービス管理ツールに表示される名前を指定する。
`--serviceDescription <description>`	デフォルト: MongoDB Server サービス管理ツールの説明に表示する文字列を指定する。空白が含まれる場合はダブルクォート(`"`)で囲む。
`--serviceUser <user>`	MongoDB を実行するユーザーを指定する。
`--servicePassword <password>`	MongoDB を実行するユーザーのパスワードを指定する。

参考文書

MongoDB の特徴

kc@example.com (kc kim) — Sun, 09 Jan 2022 18:38:00 +0900

今回は MongoDB の特徴について見てみよう。

公式サイトにも記載されている内容として、特徴は大きく以下のように整理できる。

ドキュメントデータベース(NoSQL)
特殊クエリ
高性能
高可用性
水平スケーラビリティ

ドキュメントデータベース(NoSQL)

JSON のようにキー・バリュー(Key-Value)の組み合わせをそのまま保存できる、ドキュメント形式のデータベースである。バリューにはさまざまな形式を指定できる。たとえば数値や文字列はもちろん、配列やオブジェクトを保存できることも特徴である。また、このバリューの形式は動的に変更でき、同じフィールド名に複数の形式を入れることもできる。つまり、スキーマレス(schemaless)なドキュメントデータベースである。

性能

性能を出すために、次のような機能が実装されている。

埋め込みデータモデルによる I/O 処理の削減
インデックス(index)のサポート

NoSQL でありながら「インデックス」をサポートしていることが MongoDB の特徴である。「インデックス」に関連して「ユニークキー」を指定することもできる。

特殊クエリ

JSON 形式で指定する特殊クエリを活用して DB を検索する。クエリで実行できる操作は基本的な CRUD 操作はもちろん、以下のような特徴的なクエリがある。

集計(Aggregation、Map-Reduce)
「テキストインデックス」を使った文字列検索
地理空間クエリ

集計(Aggregation、Map-Reduce)では、保存されたデータに対してさまざまな統計処理を実行できる。クエリ単体の組み立ては独特な実装なので慣れが必要だが、処理順序がパイプライン化されているため、コードの見通しはよい。

「地理空間クエリ」は、組み込みの「GeoJSON」形式を利用して「範囲内のポイント検索」を行うことができる。

可用性

MongoDB はレプリカセットという機能でレプリケーション機能を提供する。このレプリカセットは自動フェイルオーバーとデータ冗長性を提供する。

水平スケーリング

水平スケーリングという特徴は、「マシンを増やすことで性能を向上できる」ということである。MongoDB では、コア機能であるシャーディングという仕組みによって水平スケーラビリティを実現している。

複数ストレージエンジンのサポート

MongoDB は複数のストレージエンジンをサポートする。一般的に使用されるファイルシステムのほか、インメモリエンジンを選択できる。また、ストレージエンジン API を公開しているため、サードパーティ製ストレージエンジンを作成することもできる。

参考文書

MongoDB Docker インストール

kc@example.com (kc kim) — Mon, 10 Jan 2022 08:53:00 +0900

MongoDB Docker インストール

MongoDB Docker イメージのダウンロード

以下のコマンドを実行して MongoDB Docker イメージをダウンロードする。タグにバージョンを指定しない場合は、最新バージョンがダウンロードされる。

docker pull mongo

実行結果は以下のとおりである。

% docker pull mongo
Using default tag: latest
latest: Pulling from library/mongo
ea362f368469: Pull complete
ecab26900ceb: Pull complete
1847fcb70562: Pull complete
a7de23811c0d: Pull complete
29dd51833fb9: Pull complete
5eccd2be8afb: Pull complete
cd8a8cd6879f: Pull complete
e6ca3abc397d: Pull complete
7481c3682d3c: Pull complete
af377cb9eb7d: Pull complete
Digest: sha256:6743836d42756b2ae50549b2eb4585c688fce81a243cedd152b56266c2fb3d17
Status: Downloaded newer image for mongo:latest
docker.io/library/mongo:latest

MongoDB のバージョンを指定するには、タグにバージョンを指定する必要がある。ダウンロード可能な MongoDB バージョンは Docker Hub で確認できる。

次のコマンドで、ダウンロードした Docker イメージを確認する。

docker images

実行結果は以下のとおりである。

% docker images
REPOSITORY                                      TAG            IMAGE ID       CREATED         SIZE
mongo                                           latest         ee13a1eacac9   2 days ago      696MB

MongoDB Docker コンテナの作成と実行

docker run --name my-mongodb -v ~/mongodb/db:/data/db -d -p 27017:27017 mongo

-v ~/mongodb/db:/data/db は、ホスト、つまりコンテナを起動するローカルコンピュータの ~/mongodb/db ディレクトリと、コンテナの /data/db ディレクトリをマウントする。このようにボリュームを設定しないと、コンテナを削除したときに保存されたデータも削除されるためである。一度削除されたコンテナデータは復元できない。

% docker run --name my-mongodb -v ~/mongodb/db:/data/db -d -p 27017:27017 mongo
ade97bdb08fde4eaa72ceb0135b0a570d97b21616affb7949a0fc479fec25e0e

MongoDB Docker コンテナの開始、停止、再起動

MongoDB Docker コンテナを停止する。

docker stop my-mongodb

MongoDB Docker コンテナを開始する。

docker start my-mongodb

MongoDB Docker コンテナを再起動する。

docker restart my-mongodb

MongoDB Docker コンテナの実行確認

次のコマンドを実行する。

% docker ps -a
CONTAINER ID   IMAGE                                                  COMMAND                  CREATED          STATUS                      PORTS                                       NAMES
ade97bdb08fd   mongo                                                  "docker-entrypoint.s..."   37 seconds ago   Up 36 seconds               0.0.0.0:27017->27017/tcp                    my-mongodb

MongoDB Docker コンテナへの接続

次のコマンドを実行する。

docker exec -it my-mongodb bash

実行結果は以下のとおりである。

% docker exec -it my-mongodb bash
root@ade97bdb08fd:/#

MongoDB mongo コマンドの使い方

kc@example.com (kc kim) — Tue, 11 Jan 2022 18:21:00 +0900

MongoDB に接続するクライアントモジュールである mongo を使用して接続する方法について見てみよう。

基本オプション

オプション	説明
`--host <hostname>`	接続する MongoDB サーバーのホスト名を指定する。ホスト名を指定しない場合は localhost に接続する。
`--port <port>`	MongoDB サーバーに接続するポート番号を指定する。ポート番号を指定しない場合は `27017` に接続する。
`--username <username>, -u <username>`	認証機能が有効な MongoDB にアクセスするときのユーザー名を指定する。
`--password <password>, -p <password>`	認証機能が有効な MongoDB に接続するときのパスワードを指定する。
`--authenticationDatabase <dbname>`	認証するデータベース名を指定する。

ファイル

.dbshell

mongo シェルで実行されたコマンドの履歴が保存される。ファイルはホームディレクトリ(%UserProfile%)直下に自動的に作成される。Windows の場合、たとえば次の場所になる。

%UserProfile%

C:\Users\<ユーザー名>\.dbshell

.mongorc.js

.mongorc.js ファイルを決められたディレクトリ(%UserProfile% または %ProgramData%)の直下に置くと、mongo 起動時に自動で .mongorc.js がロードされて実行される。これを使うと、シェル実行中に共通で使いたい変数や関数をあらかじめ定義しておくことができる。.mongorc.js はユーザー定義(%UserProfile%)よりもグローバル定義(%ProgramData%)を先に読み込む。

.mongorc.js をロードしたくない場合は、--norc オプションを付けて mongo を起動するとロードされない。

Windows の場合、たとえば次のようなディレクトリになる。 %UserProfile%

C:\Users\<ユーザー名>\.mongorc.js

%ProgramData%

C:\ProgramData\MongoDB\.mongorc.js

参考記事

MongoDB でインデックスを適用する方法

kc@example.com (kc kim) — Wed, 12 Jan 2022 08:39:00 +0900

MongoDB はドキュメント型データベースであるため、少し異なるインデックスが存在する。今回は RDB にはないインデックスの概念について見てみよう。

MongoDB のインデックス

MongoDB では基本的に、ドキュメントを作成するたびに _id 属性がユニークインデックスとして自動的に生成される。これで不足する場合は、独自に db.collection.createIndex() を使用してインデックスを作成する。db.collection.createIndex() によって作成されるインデックスは、B-tree データ構造のインデックスである。

MongoDB は単純なキー指定以外にも、いくつかのインデックス型をサポートする。具体的にサポートされるインデックス型は次のとおりである。

単一キー
複合キー
マルチキー
地理空間
テキスト
ハッシュ

「複合キー」と「マルチキー」は名称が似ているが内容は異なる。「複合キー」は複数フィールドを組み合わせたキーであり、「マルチキー」は配列を扱う属性について、その配列に含まれるすべての値を対象にするキーである。

以下では、基本となる「単一キーインデックス」、「複合キーインデックス」、「マルチキーインデックス」について、具体的な使い方をサンプルコードで見ていく。

インデックスの基本作成

mongo シェルで次のコマンドを実行すると、指定したコレクションに対してインデックスを作成できる。

JavaScript コードでも関数は同じだが、3番目の引数にコールバックを指定できる点が異なる。

構文

db.collection.createIndex(keys, options)

引数

引数	Type	説明
`keys`	`string`/`object`	値を持つフィールド名を指定する。昇順キーであれば `1`、降順キーであれば `-1` を指定する。
`options`	`object`	インデックス作成に関するオプションを指定する。オプションとして指定できるものには `unique`、`collation` がある。他にもあるが、ここではこれだけ覚えておこう。

使用例

以下で「単一キーインデックス(Single field index)」、「複合キーインデックス(Compound index)」、「マルチキーインデックス(Multi-key index)」の使用例を見てみよう。

単一キーインデックスの作成

以下のようなサンプルドキュメントにインデックスを作成するサンプルコードを3つ扱う。MongoDB はドキュメント型データベースであるため、RDB にはない「埋め込みフィールド」や「埋め込みドキュメント」に対するインデックス作成ができる。

{
  "score": 1034,
  "location": { city: "Seoul", county: "Korea Republic of" }
}

単一フィールド

もっとも単純な「単一フィールド」に対するインデックス作成のサンプルコードである。

> db.collection.createIndex({ score: 1 })

> db.collection.find({ score: 1034 })
> db.collection.find({ score: { $gt: 1000 } })

埋め込みフィールド

MongoDB は属性値としてドキュメントを指定することもできる。このような場合、ドキュメント内のフィールド、つまりネストされた要素についてもインデックス化できる。

> db.collection.createIndex({ "location.city": 1 })

> db.collection.find({ "location.city": "Kyunggi" })

埋め込みドキュメント

上の「埋め込みフィールド」と似ているが、元のオブジェクトを指定することもできる。ただし、この場合は属性の数と属性の順序を含めて完全一致が求められる点に注意する必要がある。

> db.collection.createIndex({ location: 1 })

> db.collection.find({ city: "Seoul", county: "Korea Republic of" })

複合キーインデックスの作成

RDB にも存在する複合キーインデックスである。MongoDB では複数のフィールドをキーとして指定して作成できる。MongoDB の複合キーインデックスでは、「指定された複合キーすべてに一致する」パターンだけでなく、「一部に一致する」パターンでもインデックスが有効である。

次のサンプルデータに対して「複合キーインデックス」を作成する例を見てみよう。

{
  "item": "Apple",
  "location": "xxx store",
  "stock": 4,
  "type": "cases"
}

> db.collection.createIndex({ item: 1, location: 1, stock: 1 })

> db.collection.find({ item: "Apple" })
> db.collection.find({ item: "Apple", location: "xxx store" })
> db.collection.find({ item: "Apple", location: "xxx store", stock: { $gt: 0 } })

上の例ではインデックスの作成が item -> location -> stock であるため、その先頭部分である item や item -> location などでもインデックスが有効になる。

マルチキーインデックスの作成

MongoDB には、配列を値として使用するフィールドもある。配列の値は「プリミティブ」でも「オブジェクト」でも、どちらの場合でも「マルチキーインデックス」を作成できる。

以下では、配列フィールド ratings を含むコレクションに対してインデックスを作成し、検索するサンプルを見てみる。

{ "item": "Apple",  ratings: [ 2, 9 ] }
{ "item": "Banana", ratings: [ 4, 3 ] }

インデックス作成は、単純に ratings に対して createIndex() を呼び出して作成できる。

> db.collection.createIndex({ ratings: 1 })

配列フィールドに対する検索は、通常 $elemMatch を使用する。以下の例では「3以上6以下の ratings が1レコード以上存在するドキュメント」を抽出している。

> db.collection.find({ ratings: { $elemMatch: { $gte: 3, $lte: 6 } } })
{ "_id" : ObjectId("5a2d24459c684f917e3ec0c2"), "item" : "XYZ", "ratings" : [ 4, 3 ] }

以下のように入力すると、「3以上または6以下を満たすレコードが1件以上存在するドキュメント」を抽出するため、結果的にすべて抽出されてしまう。

> db.collection.find({ ratings: { $gte: 3, $lte: 6 } })
{ "_id" : ObjectId("5a2d24399c684f917e3ec0c1"), "item" : "ABC", "ratings" : [ 2, 9 ] }
{ "_id" : ObjectId("5a2d24459c684f917e3ec0c2"), "item" : "XYZ", "ratings" : [ 4, 3 ] }

参考文書

MongoDB で unique 制約を適用する方法

kc@example.com (kc kim) — Wed, 12 Jan 2022 08:59:00 +0900

今回は「MongoDB で unique 制約を適用する方法」について見てみよう。

unique 制約の適用

MongoDB で unique 制約を適用するには、インデックスを作成するときに createIndex() のオプションとして unique に true を指定すればよい。

以下では、「単一キーインデックス」の場合と「複合キーインデックス」の場合について、サンプルコードを見ていく。

単一キーインデックス

単一キーインデックスであれば、単純に次のようなコードを mongo シェルで実行すると作成できる。

> db.members.createIndex({ userId: 1 }, { unique: true })

複合キーインデックス

複合キーインデックスの場合も、単一キーインデックスとコードは変わらない。

> db.members.createIndex({ firstname: 1, lastname: 1 }, { unique: true })

複合キーインデックスの場合、複合キーの組み合わせとして一意であればよいため、以下は問題なく設定できる。

> db.members.insert({ firstname: "kc", lastname: "Kim" })
> db.members.insert({ firstname: "et", lastname: "Kim" })
> db.members.insert({ firstname: "kc" })

unique 制約の設定制限

RDB の場合と似ているが、すでに重複データが登録されているコレクションに対して unique 制約を設定することはできない。すでに重複している状態では当然と言えば当然である。

また、ハッシュインデックスに対して unique 制約を設定することは推奨されない。(Hashed Indexes の Considerations)

unique 制約キーに値が設定されていない場合の動作

上で「複合キーインデックス」に unique 制約を設定したデータ登録例のように、値がないフィールドが存在する場合、内部的には null が指定されたものとして処理される。

たとえば、次のようにフィールド x に対する unique 制約があるコレクションがあるとする。

> db.collection.createIndex({ x: 1 }, { unique: true })

フィールド x を指定しないデータが登録されたと仮定する。

> db.collection.insert({ y: 1 })
WriteResult({ "nInserted" : 1 })

最初は x: null として指定されるため、正常に登録できる。続けて、フィールド x が存在しない別のデータを挿入するとどうなるだろうか。

> db.collection.insert({ z: 1 })
WriteResult({
    "nInserted" : 0,
    "writeError" : {
        "code" : 11000,
        "errmsg" : "E11000 duplicate key error collection: test.collection index: x_1 dup key: { : null }"
    }
})

上記のようにエラーが発生し、挿入できないことがわかる。また、エラーメッセージからも、指定がない場合は null が指定されることがわかる。

参考文書

MongoDB - Unique Indexes