もう二度と、絶対にMongoDBを使うべきじゃない理由

  • このエントリーをはてなブックマークに追加

      2016/02/19

もう二度と、絶対にMongoDBを使うべきじゃない理由

MongoDBは悪だ。なぜならそれは…

  • …データを無くす(ソース:12)。
  • …実際、長期間、デフォルトでエラーを無視し続け、何があってもすべての単一書き込みが成功したとみなした( 32ビットのシステムで3GBかそこらを使用したら、MongoDBの制限によって何の警告もなしに全データを失うことになった)。
  • …宣伝していたユースケースでですら遅く、これが早いと主張するには完全に証拠に欠けている(ソース:34)。
  • …ほぼ全てのユースケースで、暗黙のスキーマという悪しき習慣を強要してくる(ソース:4)。
  • …ロッキングに問題がある(ソース:4)。
  • …セキュリティの問題になるくらい、応答時間が酷く遅い。求めてきた人全員に認証なしで全データをさらしてしまうという危険なデフォルト設定をパッチするのに2かかった(ソース:5)。
  • …ACID特性に準拠していない(ソース:6)。
  • …拡張やメンテナンスをするのが大変すぎる。
  • …提供するJSONベースのストレージにおいても排他的でない。PostgreSQLも同様に提供しているし、CouchDBなど他の(もっと良い)ドキュメントストアも昔からある(ソース:78)。

 
…つまり現実的には、MongoDBが得意とするところは何もなくて、あるのは明らかに不得意なことばかりだ。そしてここまで箇条書きにしてきた内容は全て事実で、「あなただけの意見」ではない。他のサイトを見て自分で確かめてきてもいい。
 
ほとんどの場合、本当に必要なのはリレーショナル・データベースだ。この場合、PostgreSQLはとても良い選択肢で、クエリビルダやORMを使えば、より作業が捗る。Node.jsでは、Knex(クエリビルダとして)、BookshelfSequelizeWaterline(ORMとして)などがある。
 
あなたのプロジェクトが、ユーザアカウント、または2レコード間の関係が関与してくるものであれば、最終的にデータはリレーショナルになるため、ドキュメントストアではなくリレーショナル・データベースを使うべきだ。
 
もし自分がMongooseを使っていることに気づいたなら、リレーショナル・データベースも使っていて然るべきだ。Mongooseのようなライブラリは、ドキュメントストアを使ったスキーマフルなリレーショナル・データベースを(下手に)エミュレートしようとしているだけなので、最初からリレーショナル・データベースを使ったほうがよさそうだ!
 
たとえドキュメントストアが必要だとしても(もう一度言うが、ほとんどのケースで必要ではない)、MongoDBより有用な選択肢はたくさんある。ここにドキュメントストアデータベースのリストがある。注意してほしいのは、このリストは人気順になっていて、データベースのクオリティについては触れていない。
 
決して、「みんなが使っているから」という理由でデータベースを使ってはならない。人気のデータベースの長所と短所を自分で調べること。人気というのは広告によるところが大きいし、優れたマーケティングチームの手にかかれば、凡庸なソリューションでも世に広めるのは難しいことではない。

そして、「プロトタイピングに良い」というのもまた違う。結局は満足に製品化もできないようなデータベースで自分自身をがんじがらめにしてしまうのがオチだ。あなたのプロトタイプが実行可能そうなら、違うデータベースを使って全部書き換えなければならなくなるだろう。
 
現在のほぼ全ての開発におけるエコシステムには、ロールバックを伴うマイグレーションがある。それは、プロトタイプとして同等の使い勝手の良さを提供してくれるもので、本番用コードを書き直さなければならないという欠点はない。
 
MongoDBには有効なユースケースがない。MongoDBは、他の選択肢に比べて技術的に劣っていて、実際に使える機能もこれといって提供していない。開発者たちは、データベースにとってほぼ最重要とも言える、データの整合性とセキュリティを守ることができないのだ。

原文:http://cryto.net/~joepie91/blog/2015/07/19/why-you-should-never-ever-ever-use-mongodb/ (2016-2-18)
※元記事の筆者には直接翻訳の許可を頂いて、翻訳・公開しております。

あとがき

プロダクション環境で運用したことが無く実際に困らされたわけではないので、大きな期待を持って現れた MongoDB が今ではオチ担当のような扱いを受ける現状に不憫だなと思う昨今……(得意とするところは何もないとまで言わなくても)。
技術を選定する時は、不得意な領域や罠を事前に把握して、自分たちのニーズに合ってるかを的確に判断しないといけないですね。

 -Tech,

FAworksではプロのコンサルタントが案件をお探しします

  関連記事

あなたも聞いてる?テック系ポッドキャスト3選

あなたも聞いてる?テック系ポッドキャスト3選

最近、エンジニアの間でにわかに話題になっているのが「ポッドキャスト配信」です。エンジニア自身が時事的

webを利用してイケてるガールにデプロイする方法

webを利用してイケてるガールにデプロイする方法

エンジニアに出会いはない。 彼らが業務で関わりを持つのは、チームのメンバーとPCのみ。 そしてそのメ

エンジニアとして実力を持って生きていくなら絶対取るべき資格

エンジニアとして何年か生きているのですが、そんな中で「これは受けて良かった! 勉強して良かった!」と

LL系カンファレンスの歴史

WEBエンジニアの祭典!LL系カンファレンスの歴史

例年夏から秋にかけて開催されているLL(lightweight language, 軽量プログラミン

トリバゴがどうやってマテリアル・デザインアプリの堅実な基盤を作っているか

トリバゴがどうやってマテリアル・デザインアプリの堅実な基盤を作っているか

トリバゴのデザイナーたちは、会社のブランディングについて共通の認識を持っていますが、急成長を遂げるト

Dockerコンテナとイメージの仕組みを視覚化してみた

この記事は、Docker 102レベルを意図して書かれている。Dockerが何か分からない、または仮

Twitterはどうやって1秒に3,000もの画像を処理しているのか

Twitterはどうやって1秒に3,000もの画像を処理しているのか

現在、Twitter は1秒間あたり3,000枚の画像(約200GB)を作成し持続している。 しかし

NGINXのスレッドプールがパフォーマンスを9倍にする!

NGINXのパフォーマンスをスレッドプールで9倍にする

はじめに NGINXが接続処理に非同期かつイベント駆動のアプローチを用いていることは、よく知られてい

基本的なシステム性能とOSジッタを計測するためのツールキット

Linux サーバの基本的なシステム性能とOSジッタを計測するためのツールキット

Jean Dagenaisは、mechanical-sympathyのスレッドで、Gil Teneの

Javaアプリケーションのパフォーマンスを(ほぼ)自動的に上げる方法

Javaアプリケーションのパフォーマンスを(ほぼ)自動的に上げる方法

コードを書き換えずに簡単な手順をいくつか踏むだけで、複雑なJavaアプリケーションを10%以上スピー