MongoDBの割り切りっぷりがすごい件について
32-bit limitations
http://blog.mongodb.org/post/137788967/32-bit-limitations
32-bit MongoDB processes are limited to about 2 gb of data. This has come as a surprise to a lot of people who are used to not having to worry about that. The reason for this is that the MongoDB storage engine uses memory-mapped files for performance.
By not supporting more than 2gb on 32-bit, we've been able to keep our code much simpler and cleaner. This greatly reduces the number of bugs, and reduces the time that we need to release a 1.0 product. The world is moving toward all 64-bit very quickly. Right now there aren't too many people for whom 64-bit is a problem, and in the long term, we think this will be a non-issue.
[意訳]
32bitのMongoDBは、データサイズが2GBまでという制限があります。このような制約に悩んだことのない多くの人にとって、これはびっくりな事実です。
こうなっている理由は、MongoDBストレージがパフォーマンス向上のためにmemory-mappped fileを使っているからです。
32bitシステムでの2GB超データのサポートをしないおかげで、我々はソースコードをシンプルかつきれいに保つことができています。これはバグの数を大幅に減らし、バージョン1.0をリリースするための時間を短縮する役に立っています。世の中は、オール64bitの世界に向かって猛スピードで進んでいます。32bitシステムでの制約は、長期的に見れば問題ではなくなるでしょう。
2009年7月の時点でこのような見解を出すというのは、すごい割り切りっぷりだと思います。
ext3は非推奨
また、MongoDBをext3で使うとパフォーマンス上の問題(いわゆるプチフリ)があります。CentOS5などを使っているとデフォルトがext3になるので、私はこの問題で苦労しました。
- MongoDBをext3で使ったら死んだ
- MongoDBをext3とext4でベンチマークしてみたらext4が圧勝だった。
- [続報]MongoDBをext3とext4でベンチマークしてみた(mongod 2.0編)
古い仕組みを捨てることでイノベーションが生まれるのかも。
2009年~2011年ごろまでのクラウドサーバでは、32bitアーキテクチャやext3ファイルシステムは割と普通に使われていたと思います。この頃に構築したサーバでMongoDBを動かそうとすると苦労するでしょう。
例えば、AmazonEC2はかつて、スモールインスタンスでは32bitの選択肢しかありませんでした。
スモールインスタンスで64bitが使えるようになったのは2012年3月からのようです。
【AWS発表】 EC2に新ミディアム・インスタンス追加、64ビット対応のインスタンスタイプ2種追加、さらにWebコンソールにSSHクライアント統合
また、ニフティクラウドではCentOSの公式提供がver5系しかなかったので、サーバのデフォルトファイルシステムがext3でした。
CentOS6が公式提供されたのは2012年4月からでした。
スタンダードイメージ「SQLServer2008」 「CentOS6.2」、パブリックイメージ「Ubuntu11.10」をリリースしました!: NIFTY Cloud ユーザーブログ [クラウドコンピューティング]
今でこそAmazonEC2やニフティクラウドで64bitかつext4な環境が簡単に作れるようになりましたが、やっと時代がMongoDBに追いついたということでしょうか。
イノベーションというのは、レガシーシステムを切り捨てるところから始まるのかもしれませんね。
カテゴリ:
MongoDB