試しにデータを入れてみる
ではさっそくデータを投入してみましょう。MongoDBの場合、一個のデータを「ドキュメント」と呼び、ドキュメントが沢山集まった、検索とか集計の単位を「コレクション」、コレクションの集まりである管理単位を「データベース」と呼びます。データベースやコレクションを作るのに特別な手続きは必要はなく、単にそこを指定してドキュメントを作成するだけです。ドキュメント形式もやはりJSONです。
では、この連載であるOSS on SoftLayer Showcaseの情報を集めたデータベースOSSonSoftLayerを作り、そこに連載記事の情報をコレクションarticlesに格納してみます。先ほどからつないでいるプライマリノードでそのまま作業します。
1 | replSetSLDemo:PRIMARY> use OSSonSoftLayer |
2 | switched to db OSSonSoftLayer |
4 | WriteResult({ "nInserted" : 1 }) |
5 | replSetSLDemo:PRIMARY> db.articles.insert({title: "OpenStack Juno on SoftLayer by RDO", OSS: "OpenStack", authors: [{name: "熊谷育朗", yomi: "KUMAGAI, Ikuo"}, {name: "鈴木智明", yomi: "SUZUKI, Toshiaki"}], URL: "http://thinkit.co.jp/story/2014/12/15/5484"}) |
6 | WriteResult({ "nInserted" : 1 }) |
とりあえず二つのドキュメントを追加してみました。
検索してみましょう。
01 | replSetSLDemo:PRIMARY> db.articles.findOne() |
03 | "_id" : ObjectId("551f511648f585534212d0d7"), |
04 | "title" : "IBMのSoftLayerで最新のDrupal 8を試してみよう！", |
09 | "yomi" : "OSONOI, Yasushi" |
14 | replSetSLDemo:PRIMARY> db.articles.find() |
15 | { "_id" : ObjectId("551f511648f585534212d0d7"), "title" : "IBMのSoftLayerで最新のDrupal 8を試してみ よう！", "OSS" : "Drupal", "authors" : [ { "name" : "小薗井 康志", "yomi" : "OSONOI, Yasushi" } ], "URL" : "http://thinkit.co.jp/story/2014/12/15/5484" } |
16 | { "_id" : ObjectId("551f511948f585534212d0d8"), "title" : "OpenStack Juno on SoftLayer by RDO", "OSS" : "OpenStack", "authors" : [ { "name" : "熊谷育朗", "yomi" : "KUMAGAI, Ikuo" }, { "name" : "鈴木智明", "yomi" : "SUZUKI, Toshiaki" } ], "URL" : "http://thinkit.co.jp/story/2014/12/15/5484" } |
ちゃんと入っているようですね。
さて、レプリカセットなので、投入したデータはほかのノードにもレプリケーションされているはずです。mongo2につないで確認してみましょう。標準だとセカンダリノードからのREADはできないので、rs.slaveOk()コマンドで許可してから検索してみます。
1 | $ mongo 〈mongo2のプライベートIP〉/OSSonSoftLayer |
2 | MongoDB shell version: 2.6.9 |
3 | connecting to: 〈mongo2のプライベートIP〉/OSSonSoftLayer |
4 | replSetSLDemo:SECONDARY> rs.slaveOk() |
5 | replSetSLDemo:SECONDARY> db.articles.find() |
6 | { "_id" : ObjectId("551f511648f585534212d0d7"), "title" : "IBMのSoftLayerで最新のDrupal 8を試してみよう！", "OSS" : "Drupal", "authors" : [ { "name" : "小薗井 康志", "yomi" : "OSONOI, Yasushi" } ], " |
8 | { "_id" : ObjectId("551f511948f585534212d0d8"), "title" : "OpenStack Juno on SoftLayer by RDO", "OSS" : "OpenStack", "authors" : [ { "name" : "熊谷育朗", "yomi" : "KUMAGAI, Ikuo" }, { "name" : "鈴木智明", "yomi" : "SUZUKI, Toshiaki" } ], "URL" : "http://thinkit.co.jp/story/2014/12/15/5484" } |
ばっちりですね。
もっと大量のデータを！
せっかくのデータベースなのでもうちょっと大きなデータを入れてみましょう。日本郵便の「郵便番号データダウンロード」サービス（http://www.post.japanpost.jp/zipcode/download.html）から、ローマ字読みのデータを取ってきて展開します。
3 | $ unzip ken_all_rome.zip |
4 | Archive: ken_all_rome.zip |
5 | inflating: ken_all_rome/KEN_ALL_ROME.CSV |
このデータはシフトJISなので、iconvでutf-8に変換します。
2 | $ iconv -f SJIS -t UTF-8 KEN_ALL_ROME.CSV -o KEN_ALL_ROME.utf8.csv |
これを、zipsデータベースのjapanコレクションにインポートします。データファイルの仕様を参照してフィールド名を決めると、次のようなコマンドでインポートできます。
1 | $ mongoimport --host 〈mongo1のプライベートIP〉 -d zips -c japan --type csv --fields zip,prefecture,city,town,pref-en,city-en,town-en --file KEN_ALL_ROME.utf8.csv |
プライマリノードとセカンダリノードのMongoDBシェルで
1 | $ for (;;) {print(db.japan.count(); sleep(1000)} |
というスクリプトを走らせ、zipデータベースのjapanコレクションのサイズを表示するようにしてみました。ちゃんとリアルタイムで同期されているのがわかりますね（上がプライマリ、下がセカンダリ）。
自動フェイルオーバー
次はちょっとした実験をしてみましょう。以下のようなPython3スクリプトを書いてappで実行します。レプリカセットに接続し、さきほど投入した電話番号データの全件を問い合わせし、順に表示するものです。アプリケーションでキャッシュしているわけではないので、順に問い合わせているときでもデータベースとの通信は発生します。
03 | from pymongo import MongoClient |
06 | # connect to replicaset |
07 | client = MongoClient([u'〈mongo1のプライベートIP〉',u'〈mongo2のプライベートIP〉',u'〈mongo3のプライベートIP〉']) |
09 | # access japan collection in zips database |
13 | # put all entries in japan collection, except Japanese field |
14 | for zip in japan.find({},{"_id":0, "zip":1, "pref-en":1, "city-en":1, "town-en":1}): |
実行にはpip経由でpymongoのインストールが必要になるので別途appにインストールしておきます（python3-pipパッケージを導入してpip3 install pymongo）。
さて、これを実行するとこんなふうな画面になりますが、
2 | {'town-en': 'IKANIKEISAIGANAIBAAI', 'zip': 600000, 'city-en': 'SAPPORO SHI CHUO KU', 'pref-en': 'HOKKAIDO'} |
3 | {'town-en': 'ASAHIGAOKA', 'zip': 640941, 'city-en': 'SAPPORO SHI CHUO KU', 'pref-en': 'HOKKAIDO'} |
4 | {'town-en': 'ODORIHIGASHI', 'zip': 600041, 'city-en': 'SAPPORO SHI CHUO KU', 'pref-en': 'HOKKAIDO'} |
5 | {'town-en': 'ODORINISHI(1-19-CHOME)', 'zip': 600042, 'city-en': 'SAPPORO SHI CHUO KU', 'pref-en': 'HOKKAIDO'} |
ここでSoftLayerのコンソールから、さっきまでプライマリノードだったmongo1の電源を止めてしまいましょう。パワーオフ！
……ちょっとひっかかりますが、なにごともなかったように再開して処理は継続されます。これぞレプリカセットの威力！ 読み込みの場合はほとんど気にならない程度の時間でスイッチします。mongo2につないで、レプリカセットのステータスを確認してみましょう。
01 | replSetSLDemo:SECONDARY> rs.status() |
03 | "set" : "replSetSLDemo", |
04 | "date" : ISODate("2015-04-04T05:23:13Z"), |
06 | "syncingTo" : "〈mongo3のプライベートIP〉:27017", |
10 | "name" : "〈mongo1のプライベートIP〉:27017", |
13 | "stateStr" : "(not reachable/healthy)", |
15 | "optime" : Timestamp(1428119806, 1244), |
16 | "optimeDate" : ISODate("2015-04-04T03:56:46Z"), |
17 | "lastHeartbeat" : ISODate("2015-04-04T05:23:05Z"), |
18 | "lastHeartbeatRecv" : ISODate("2015-04-04T05:20:34Z"), |
20 | "syncingTo" : "〈mongo3のプライベートIP〉:27017" |
24 | "name" : "〈mongo2のプライベートIP〉:27017", |
27 | "stateStr" : "SECONDARY", |
29 | "optime" : Timestamp(1428119806, 1244), |
30 | "optimeDate" : ISODate("2015-04-04T03:56:46Z"), |
35 | "name" : "〈mongo3のプライベートIP〉:27017", |
38 | "stateStr" : "PRIMARY", |
40 | "optime" : Timestamp(1428119806, 1244), |
41 | "optimeDate" : ISODate("2015-04-04T03:56:46Z"), |
42 | "lastHeartbeat" : ISODate("2015-04-04T05:23:12Z"), |
43 | "lastHeartbeatRecv" : ISODate("2015-04-04T05:23:12Z"), |
45 | "electionTime" : Timestamp(1428123061, 1), |
46 | "electionDate" : ISODate("2015-04-04T04:51:01Z") |
さきほどまでプライマリだったmongo1のstateStrが”(not reachable/healthy)”となっていて、mongo3がプライマリに昇格していることがわかります。ここでmongo1の電源を入れなおしたらどうなるでしょうか。
01 | replSetSLDemo:SECONDARY> rs.status() |
03 | "set" : "replSetSLDemo", |
04 | "date" : ISODate("2015-04-04T05:33:06Z"), |
06 | "syncingTo" : "〈mongo3のプライベートIP〉:27017", |
10 | "name" : "〈mongo1のプライベートIP〉:27017", |
13 | "stateStr" : "SECONDARY", |
15 | "optime" : Timestamp(1428119806, 1244), |
16 | "optimeDate" : ISODate("2015-04-04T03:56:46Z"), |
17 | "lastHeartbeat" : ISODate("2015-04-04T05:33:04Z"), |
18 | "lastHeartbeatRecv" : ISODate("2015-04-04T05:33:05Z"), |
20 | "syncingTo" : "〈mongo3のプライベートIP〉:27017" |
セカンダリとして復旧しました。強制パワーオフはともかく、たとえばサーバーのスケールアップを行う場合など、アプリケーション側の設定はそのままに、サービスを停止することなく作業できるのは嬉しいと思います。
MongoDBとSoftLayerは仲がいい？
MongoDBのレプリカセットの構成を作ってみました。こういう複数ノードの環境を作って試すにはSoftLayerのようなクラウドは便利でよいですね。各ノードの設定は完全に同じなので、Provision ScriptやCLIを用いれば、もっと手間を少なく構築できると思います。
最後に、ちょっとした小咄です。
つい数年前の常識では、非常にハイパフォーマンスな（MongoDB的にはメモリを大量に載せた）ハードウェアは非常に高価で、それよりコモディティハードウェアを並べたほうが（台数が増える分の管理コストを考えても）低コストということは言えたでしょう。そして、ノード数が増えてくると物理ハードウェアを並べるよりも管理が圧倒的にラクなので、クラウドとMongoDBは親和性が高い、というのが定説だったと思います。
しかし今はハイエンドのサーバーも価格は下がってきました。クラウドでもかなり高い性能のインスタンスを提供するようになってきましたので、台数を増やして管理コストが上がるスケールアウトより、スケールアップでできるところまで頑張りたい、できれば物理ハードウェアも視野に入れたい、でも自社でホスティングはしたくない……そんなニーズにMongoDB on SoftLayerはうまくハマるのではないかな、と思います。
今回はアプリケーション側の話はほとんどしませんでしたが、事前のスキーマ定義が不要で、スクリプト系言語でいうところのハッシュをほぼそのままデータベースに永続化できるMongoDBはとてもアプリケーションが作りやすいです。レプリカセット一つだけで、いや要件によってはシングルノードで始めても、MongoDBのメリットは大きいと思います。ぜひぜひ、MongoDB on SoftLayerで楽しい開発を！
