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になるので、私はこの問題で苦労しました。

古い仕組みを捨てることでイノベーションが生まれるのかも。

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に追いついたということでしょうか。

イノベーションというのは、レガシーシステムを切り捨てるところから始まるのかもしれませんね。
カテゴリ: