最近知ったのですが、 Red Hat、Satellite から MongoDB サポートを削除 (ライセンス変更のためなど)。 ここ数年、MongoDB がどれほどひどいものであり、誰もそれを使用すべきではないという記事をたくさん目にしてきたのだと思いました。 しかしこの間に、MongoDB はより成熟した製品になりました。 どうしたの？ 本当にすべての嫌悪感は、新しい DBMS のマーケティング開始時の間違いによるものなのでしょうか? それとも、単に間違った場所で MongoDB を使用しているだけなのでしょうか?

突然、私が MongoDB を擁護しているように感じた場合は、以下をお読みください。 免責事項 記事の最後に。

新しいトレンド

私は、言うに及ばないほど長年ソフトウェア業界に携わってきましたが、それでも、私たちの業界を襲うトレンドの一部にすぎませんでした。 私は 4GL、AOP、アジャイル、SOA、Web 2.0、AJAX、ブロックチェーンの台頭を目の当たりにしてきました…リストは無限です。 毎年新しいトレンドが生まれます。 急速に衰退しつつあるものもあれば、ソフトウェアの開発方法を根本的に変えつつあるものもあります。

新しいトレンドが生まれるたびに、ある種の一般的な興奮が生まれます。人々は自らボートに飛び込むか、他の人が生み出す騒音を見て、群衆に続きます。 このプロセスは Gartner によって体系化されています。 ハイプサイクル。 議論の余地はありますが、このグラフは、テクノロジーが最終的に実用化される前にテクノロジーに何が起こるかを大まかに表しています。

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

注: ドキュメント データベースと、列データベース、キー/値ストア、または NoSQL の一般的な定義に該当するその他の種類のデータ ストアを混同していると思われるかもしれません。 そして、あなたは正しいです。 しかし、当時は混乱が支配していました。 誰もが NoSQL に夢中になり、それがすべてになっています 絶対に しかし、多くの人はさまざまなテクノロジーの違いを理解していませんでした。 多くの人にとって、MongoDB は 同義の ノーSQL。

そして開発者たちはそれに飛びつきました。 あらゆる問題を解決するために魔法のように拡張できるスキーマレス データベースのアイデアは、非常に魅力的でした。 2014 年頃、XNUMX 年前には MySQL、Postgres、SQL Server などのリレーショナル データベースが使用されていたすべての場所で、MongoDB データベースがデプロイされているように見えました。 理由を尋ねると、「これが Web の規模です」というありきたりなものから、「私のデータは非常に緩やかに構造化されており、スキーマがなくてもデータベースにうまく収まる」というより思慮深いものまで、さまざまな答えが得られます。

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

• 厳格なスキーム: リレーショナル データベースでは、データが動的に生成されている場合、ランダムな「異なる」データ列を多数作成するか、そこにデータ BLOB をプッシュするか、構成を使用する必要があります。 EAV…これらすべてには重大な欠点があります。
• スケーリングの難しさ: データが多すぎて XNUMX つのサーバーに収まらない場合、MongoDB は複数のマシンにスケールアウトできるメカニズムを提供しました。
• 複雑な回路の変更: 移行はありません! リレーショナル データベースでは、データベースの構造を変更することは大きな問題になる可能性があります (特に大量のデータがある場合)。 MongoDB はプロセスを大幅に簡素化することができました。 また、非常に簡単になったので、外出先でスキーマを更新するだけで、非常に迅速に作業を進めることができます。
• 書き込みパフォーマンス: 特に適切に調整された場合、MongoDB のパフォーマンスは良好でした。 しばしば批判される MongoDB のすぐに使える構成でも、いくつかの素晴らしいパフォーマンス数値を示しました。

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

MongoDB の潜在的な利点は、特に特定の種類の問題に対しては非常に大きなものでした。 文脈を理解せず、何の経験も持たずに上記のリストを読むと、MongoDB が本当に革新的な DBMS であるという印象を受けるかもしれません。 唯一の問題は、上記の利点には多くの注意事項が伴うことであり、その一部を以下に示します。

公平を期すために言うと、10gen/MongoDB Inc. には誰もいません。 以下が真実ではないとは言いません。これらは単なる妥協です。

• 取引の損失A: トランザクションは、多くのリレーショナル データベース (すべてではありませんが、ほとんど) の中核機能です。 トランザクションとは、複数の操作をアトミックに実行でき、データの一貫性を確保できることを意味します。 もちろん、NoSQL データベースでは、トランザクション性を XNUMX つのドキュメント内に収めることも、XNUMX フェーズ コミットを使用してトランザクション セマンティクスを取得することもできます。 ただし、この機能は自分で実装する必要があります...これは困難で時間のかかる作業となる可能性があります。 操作のアトミック性を保証することが不可能であるため、データベース内のデータが無効な状態になるまで問題に気づかないことがよくあります。 注: トランザクションは昨年 MongoDB 4.0 で導入されましたが、いくつかの制限があると多くの人が聞いています。 この記事の結論は変わりません。テクノロジーがニーズにどのように適合するかを評価してください。
• リレーショナル整合性の喪失 (外部キー): データにリレーションシップがある場合は、それらをアプリケーションに適用する必要があります。 これらの関係を尊重するデータベースを作成すると、アプリケーション、つまりプログラマの作業が大幅に軽減されます。
• データ構造を適用できない: 厳密なスキーマは大きな問題になることがありますが、賢く使用すれば、適切なデータ構造化のための強力なメカニズムでもあります。 MongoDB のようなドキュメント データベースは、スキーマの柔軟性に優れていますが、その柔軟性により、データをクリーンに保つ責任が失われます。 これらに注意しないと、期待した形式で保存されていないデータを処理するためにアプリケーションに大量のコードを記述することになります。 当社の Simple Thread でよく言われるように、アプリケーションはいつか書き換えられますが、データは永久に残ります。 注: MongoDB はスキーマ検証をサポートしています。これは便利ですが、リレーショナル データベースと同じ保証は提供されません。 まず、スキーマ検証を追加または変更しても、コレクション内の既存のデータには影響しません。 新しいスキーマに従ってデータを更新していることを確認する必要があります。 これでニーズに十分かどうかは自分で判断してください。
• 独自のクエリ言語 / ツール エコシステムの喪失: SQL の出現は絶対的な革命であり、それ以来何も変わっていません。 これは信じられないほど強力な言語ですが、非常に複雑でもあります。 JSON フラグメントで構成されるデータベース クエリを新しい言語で構築する必要があるということは、SQL の経験がある人々にとっては大きな後退であると考えられています。 IDE からレポート ツールに至るまで、SQL データベースと対話するツールが数多く存在します。 SQL をサポートしていないデータベースに移行すると、これらのツールのほとんどが使用できなくなるか、ツールを使用するにはデータを SQL に変換する必要があり、これは思っているよりも難しい場合があります。

MongoDB に頼った開発者の多くは、トレードオフをよく理解しておらず、真っ先に MongoDB をプライマリ データ ストアとして設定することに取り掛かることがよくありました。 その後、元に戻るのは信じられないほど困難になることがよくありました。

もっと違う方法は何だったでしょうか?

誰もが頭から飛び降りて底に激突したわけではありません。 しかし、かなりの数のプロジェクトが、MongoDB ベースが適合しない場所にインストールされており、今後何年もそれを使用しなければならないことになります。 これらの組織がテクノロジーの選択を系統的に検討するのに時間をかけていたら、多くの組織が別の選択をしていたでしょう。

適切なテクノロジーを選択するにはどうすればよいでしょうか? 技術評価のための体系的な枠組みを作成する試みがいくつかありました。 「ソフトウェア組織におけるテクノロジー実装のフレームワーク」 и 「ソフトウェア技術評価用フレームフォーク」、しかし、これは不必要な複雑さであるように私には思えます。

多くのテクノロジーは、たった XNUMX つの基本的な質問をするだけで賢く評価できます。 問題は、時間をかけて偏見なく答えを見つけ、責任を持って答えられる人を見つけることにあります。

何らかの問題に直面しなければ、新しいツールは必要ありません。 ドット。

質問 1: 私が解決しようとしている問題は何ですか?

何らかの問題に直面しなければ、新しいツールは必要ありません。 ドット。 解決策を探してから問題を考える必要はありません。 新しいテクノロジーが既存のテクノロジーより大幅に解決できない問題に直面している場合を除き、ここで議論する必要はありません。 他の人がこのテクノロジーを使用しているのを見たためにこのテクノロジーの使用を検討している場合は、その人が抱えている問題について考え、自分もそのような問題を抱えているかどうかを尋ねてください。 他の人がテクノロジーを使用しているため、テクノロジーを受け入れるのは簡単ですが、難しいのは、自分が同じ問題に直面しているかどうかを知ることです。

質問 2: 何が足りないのでしょうか?

確かに、これはより難しい質問です。古いテクノロジーと新しいテクノロジーの両方を掘り下げて理解する必要があるからです。 新しいものを使って何かを構築するか、その経験を持つ同僚がいない限り、新しいものを本当に理解できない場合があります。

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

人はいつもすべてを台無しにする

これらの質問にできるだけ公平に答えようとするとき、XNUMX つ覚えておいてください。それは、人間の本性と戦わなければならないということです。 テクノロジーを効果的に評価するには、克服しなければならない認知バイアスが多数あります。 以下にほんの一部を示します。

• 過半数に加わることの効果 誰もが彼のことを知っていますが、それでも彼と戦うのは難しいです。 テクノロジーが実際のニーズに本当に合っているかどうかを確認してください。
• ノベルティ効果 多くの開発者は、長年取り組んできたテクノロジーを過小評価し、新しいテクノロジーの利点を過大評価する傾向があります。 プログラマーだけでなく、誰もがこの認知バイアスの影響を受けます。
• プラスの属性効果 私たちは、あるものだけを見て、そうでないものを見失ってしまう傾向があります。 新しいテクノロジーを本質的に過大評価するだけでなく、その欠点を無視するため、目新しさの効果と相まって混乱が生じる可能性があります。.

客観的な評価は簡単ではありませんが、根底にある認知バイアスを理解することで、より合理的な意思決定ができ​​るようになります。

サマリー

イノベーションが現れるときは、次の XNUMX つの質問に細心の注意を払って答える必要があります。

• このツールは実際の問題を解決しますか?
• 私たちはトレードオフを理解できていますか?

これら XNUMX つの質問に自信を持って答えることができない場合は、数歩下がって考えてください。

では、la MongoDB は一般的に正しい選択だったのでしょうか? もちろんはい; ほとんどのエンジニアリング技術と同様に、それは多くの要因に依存します。 これら XNUMX つの質問に回答した人の多くは、MongoDB の恩恵を受けており、今後も恩恵を受け続けています。 まだの方にとっては、誇大広告サイクルを通過することについて、それほど苦痛ではない貴重な教訓を学べたことを願っています。

免責事項

はっきりさせておきたいのは、私は MongoDB が好きでも嫌いでもないということです。 MongoDB が解決するのに最適な種類の問題がありませんでした。 10gen/MongoDB Inc. は知っています。 当初は非常に大胆に行動し、安全でないデフォルトを設定し、あらゆるデータを扱うためのワンストップ ソリューションとして MongoDB をあらゆる場所 (特にハッカソン) で宣伝しました。 おそらくそれは間違った決断だったでしょう。 しかし、ここで説明したアプローチが裏付けられています。これらの問題は、テクノロジの表面的な評価でも非常に迅速に検出できるということです。

出所： habr.com