私は最近、 Red HatがSatelliteからMongoDBサポートを削除していることを発見しました（ライセンスの変更によるものです）。 過去数年間で、MongoDBがどれほどひどいもので、誰も使用すべきではないという記事をたくさん見たと思いました。 しかし、この間、MongoDBははるかに成熟した製品になりました。 どうしたの？ すべての憎しみは、本当に新しいDBMSのマーケティング開始時の間違いによるものですか？ または、間違った場所でMongoDBを使用しているだけですか？



突然MongoDBを保護していると思われる場合は、記事の最後にある免責事項をお読みください。

新しいトレンド

私はソフトウェア業界にきちんと話すのに十分な時間以上働いてきましたが、それでも私たちの業界を襲ったトレンドのごく一部しか説明できませんでした。 4GL、AOP、アジャイル、SOA、Web 2.0、AJAX、ブロックチェーンの成長を目の当たりにしました...リストは無限です。 毎年新しいトレンドが現れます。 すぐに消えてしまうものもあれば、ソフトウェアの開発方法を根本的に変えるものもあります。



すべての新しいトレンドの周りに、特定の一般的な興奮が生まれます。人々はボートに飛び込むか、他の人が生成するノイズを見て、群衆を追います。 このプロセスは、ガートナーによって誇大広告サイクルで体系化されています 。 議論の余地はありますが、このグラフは、最終的に使用可能になる前にテクノロジーに何が起こるかを大まかに説明しています。



しかし、たった1つの特定の実装によって駆動される新しい技術革新が登場する場合があります（または、この場合のように再登場が発生します）。 NoSQLの場合、誇大広告はMongoDBの出現と急速な上昇によって大きく推進されました。 MongoDBはこの傾向を開始しませんでした。実際、大規模なインターネット企業は大量のデータの処理に問題を抱え始め、非リレーショナルデータベースが復活しました。 一般的な動きは、GoogleのBigtableやFacebookのCassandraなどのプロジェクトで始まりましたが、ほとんどの開発者がアクセスできるNoSQLデータベースの最も有名で手頃な実装となったのはMongoDBでした。



注：文書データベースと列データベース、キー/値ストア、またはNoSQLの一般的な定義に該当する他の多くの種類のデータストアのいずれかと混合していると思われるかもしれません。 そしてあなたは正しい。 しかし、当時は混乱が支配していました。 誰もがNoSQLに夢中になっており、誰もが絶対にそれを必要としていましたが、多くの人は異なる技術の違いを見ていませんでした。 多くの場合、MongoDBはNoSQLと同義語になりました。



そして、開発者は彼女を攻撃しました。 これは、問題を解決するために魔法のように拡張するスキーマのないデータベースにとって非常に魅力的なアイデアでした。 2014年頃、MySQL、Postgres、SQL Serverなど、1年前にリレーショナルデータベースが使用されていたすべての場所で、MongoDBデータベースが展開され始めたようです。 なぜかという質問に対して、「これはWebの規模です」という考えから、「私のデータは非常に構造が悪く、スキームなしでデータベースにうまく収まる」という答えを得ることができます。



MongoDBとドキュメントデータベースは、通常、従来のリレーショナルデータベースに関する多くの問題を解決することを覚えておくことが重要です。

• 厳密なスキーム ：リレーショナルデータベースでは、動的に生成されたデータがある場合、ランダムな「異なる」データ列の束を作成するか、そこにデータBLOBをプッシュするか、 EAV構成を使用する必要があります...これには重大な欠点があります。
  
  
• スケーリングの難しさ ：1つのサーバーに収まらないほど多くのデータがある場合、MongoDBは複数のマシンでそれらをスケーリングするメカニズムを提供しました。
  
  
• 洗練された回路変更 ：移行なし！ リレーショナルデータベースでは、データベースの構造を変更することは大きな問題になる可能性があります（特に大量のデータがある場合）。 MongoDBはプロセスを大幅に簡素化することができました。 そして、非常に簡単になったため、外出先で回路を更新してすぐに移動できます。
  
  
• パフォーマンスの記録 ：MongoDBのパフォーマンスは良好で、特に適切に調整されていました。 しばしば批判されることが多い、すぐに使用できるMongoDB構成でさえ、いくつかの印象的なパフォーマンスメトリックを示しました。

すべてのリスクはあなたにあります。

MongoDBの潜在的な利点は、特に特定のクラスの問題にとっては大きなものでした。 コンテキストを理解せず、経験のない上記のリストを読んだ場合、MongoDBは真に革命的なDBMSであるという印象を受けるかもしれません。 唯一の問題は、上記の利点にいくつかの予約が伴うことであり、その一部を以下に示します。



公平に言えば、10gen / MongoDB Inc.には誰もいません 彼は以下が真実ではないと言うことはありません；それはただの妥協です。

• トランザクションの損失 ：トランザクションは、多くのリレーショナルデータベースの主要な機能です（すべてではなく、ほとんど）。 トランザクションとは、複数の操作をアトミックに実行でき、データの一貫性を維持できることを意味します。 もちろん、NoSQLデータベースでは、トランザクション性は同じドキュメント内にある場合があります。または、2フェーズコミットを使用してトランザクションのセマンティクスを取得することもできます。 しかし、この機能を自分で実装する必要があります...これは、複雑で時間のかかるタスクになる可能性があります。 多くの場合、操作の原子性を保証することは不可能であるため、データベース内のデータが許容できない状態になるまで、問題を認識していません。 注：多くの人が、昨年MongoDB 4.0にトランザクションが登場したが、いくつかの制限があると言っていました。 この記事の結論は変わりません。テクノロジーがどのようにニーズを満たしているかを評価してください。
  
  
• 関係の整合性の損失（外部キー） ：データに関係がある場合、アプリケーションに適用する必要があります。 これらの関係に準拠したデータベースを持つことにより、アプリケーションから、したがってプログラマから作業の大部分が削除されます。
  
  
• データ構造を適用する能力の欠如 ：厳密なスキームは大きな問題になることがありますが、正しく使用された場合、優れたデータ構造化のための強力なメカニズムでもあります。 MongoDBなどのドキュメントデータベースは、非常に柔軟なスキーマを提供しますが、この柔軟性により、データをクリーンに保つ責任がなくなります。 それらの世話をしない場合は、最終的には、アプリケーションに大量のコードを記述して、期待するフォームに保存されていないデータを考慮する必要があります。 当社がよく言うように、Simple Thread ...いつかはアプリケーションが書き換えられ、データは永久に存続します。 注：MongoDBはスキーマ検証をサポートしています。これは便利ですが、リレーショナルデータベースと同じ保証は提供しません。 まず、スキーマチェックを追加または変更しても、コレクション内の既存のデータには影響しません。 新しいスキームに従ってデータを更新することを確認する必要があります。 これでニーズに十分かどうかを自分で判断します。
  
  
• ネイティブクエリ言語/ツールのエコシステムの喪失 ：SQLの出現は絶対的な革命となり、それ以来何も変わっていません。 非常に強力な言語ですが、非常に複雑です。 JSONフラグメントで構成される新しい言語でデータベースクエリを設計する必要性は、SQLの経験がある人々によって大きく後退したと見なされています。 IDEからレポート作成ツールまで、SQLデータベースと対話するツールの全体があります。 SQLをサポートしていないデータベースにアクセスするということは、これらのツールのほとんどを使用できないか、使用するためにデータをSQLに変換する必要があることを意味します。

MongoDBに目を向けた多くの開発者は、トレードオフを実際に理解しておらず、しばしば真っ向から飛び込んで、プライマリデータストアとして設定しました。 この後、戻ることは非常に困難でした。

別に何ができたでしょうか？

誰もが最初に頭を跳ねて底を打ったわけではない。 しかし、多くのプロジェクトがMongoDBベースをインストールしましたが、それが収まりきらない場所でした。そして、さらに何年もそこに住まなければなりません。 これらの組織がある程度の時間を費やし、テクノロジーの選択を系統的に検討した場合、多くの組織が別の選択を行っていたでしょう。



適切なテクノロジーを選択する方法は？ 「技術をソフトウェア組織に導入するためのフレームワーク」や「ソフトウェア技術を評価する ためのフレームワーク」など、技術を評価するための体系的なフレームワークを作成しようとする試みがいくつかありましたが、これは不必要な複雑さのようです。



多くのテクノロジーは、2つの基本的な質問をするだけで合理的に評価できます。 問題は、責任を持って回答できる人を見つけることであり、回答を探すのに時間を費やし、偏りがないことです。

問題が発生しない場合、新しいツールは必要ありません。 ポイント。

質問1：どのような問題を解決しようとしていますか？

問題が発生しない場合、新しいツールは必要ありません。 ポイント。 解決策を探して問題を思いつく必要はありません。 新しいテクノロジーでは既存のテクノロジーよりもはるかに優れた解決策が得られないという問題が発生していない場合は、議論することはありません。 他の人がどのように使用しているのかを見たためにこのテクノロジーの使用を検討している場合は、彼らが直面している問題を検討し、そのような問題があるかどうかを尋ねてください。 他の人が使用しているため、この技術を受け入れるのは簡単です。同じ問題に直面しているかどうかを理解することは困難です。

質問2：何を失っていますか？

もちろん、これはより難しい質問です。古い技術と新しい技術の両方を掘り下げて理解する必要があるからです。 新しいものを実際に理解することができない場合があります。それを使用して何かを構築するか、そのような経験を持つ従業員がいない場合です。



どちらも持っていない場合は、このツールの価値を判断するために可能な最小の投資について考えるのが理にかなっています。 また、投資を行う場合、決定を覆すことはどれほど難しいでしょうか？

人々は常にすべてを台無しにします

これらの質問に可能な限り公平に答えようとすると、1つのことを覚えておいてください。人間の本性と格闘しなければなりません。 技術を効果的に評価するために克服しなければならない多くの認知バイアスがあります。 ほんの一部を次に示します。

• 大多数に参加することの効果は、誰もがそれについて知っていることですが、それと戦うことはまだ困難です。 テクノロジーが実際のニーズに本当に合っていることを確認してください。
  
  
• ノベルティの効果 -多くの開発者は、長い間使用してきたテクノロジーを過小評価し、新しいテクノロジーの利点を過大評価する傾向があります。 プログラマーだけでなく、誰もがこの認知的歪みの影響を受けます。
  
  
• 肯定的な特性の効果 -私たちは何が見えるのか、欠けているものを見失う傾向があります。 これは、新しい技術を過大評価するだけでなく、その欠点を無視するため、ノベルティ効果と組み合わせて混乱を招く可能性があります。

客観的な評価は簡単ではありませんが、基本的な認知バイアスを理解することは、より合理的な決定を下すのに役立ちます。

まとめ

特定の技術革新が現れると、2つの質問に細心の注意を払って答える必要があります。

• このツールは実際の問題を解決しますか？
  
  
• 妥協点をよく理解していますか？

これら2つの質問に自信を持って答えることができない場合は、いくつかの手順を踏んで考え直してください。



それでは、MongoDBは一般的に正しい選択でしたか？ もちろん、はい。 ほとんどのエンジニアリング技術と同様に、これは多くの要因に依存します。 これらの2つの質問に答えた人の多くは、MongoDBから恩恵を受けており、引き続きMongoDBから恩恵を受けています。 これをしなかった人は誰でも、誇大広告サイクルに沿った動きについての貴重で痛くないレッスンを受けたと思います。

免責事項

私は、MongoDBに対する愛も憎しみもないことを明確にしたいと思います。 MongoDBが最適な問題がなかったというだけです。 10gen / MongoDB Inc. 最初、彼女は非常に大胆に行動し、安全でないデフォルト値を設定し、MongoDBをあらゆる場所（特にハッカソンで）であらゆるデータを扱うための普遍的なソリューションとして宣伝しました。 これはおそらく悪い決断でした。 ただし、ここで説明するアプローチは確認されています。これらの問題は、表面的な技術評価でも非常に迅速に検出できます。