スペルを修正してください。MongoDB である必要があります。
各データベースには独自の長所と短所があり、適用される状況も異なります。私は MongoDB 側で、上で MySQL と HDFS について言及した人がいるので、データ分析における MySQL や HDFS に対する MongoDB の利点を分析します。質問者は、これらの利点があなたが望むものであるかどうかを確認し、プロジェクトの実際の状況に基づいて決定を下したいと考えているかもしれません。
MySQL は長年にわたって確立されている RDBMS であり、RDBMS の共通機能と ACID の完全なサポートを備えています。その技術は長期間にわたる沈殿および適用テストを経ており、すでに比較的安定した適用段階にあります。実際のアプリケーションにおける NoSQL に対する RDBMS の主な利点は、強力なトランザクションです。ただし、OLAP アプリケーションでは、強力なトランザクションはあまり役に立ちませんが、分散サポートの妨げになります。完全な開発を前提とすると、最終的には水平方向の拡張が MySQL の選択における主なボトルネックになります。さらに、クローラーなどのアプリケーションの場合、通常、非構造化データがクロールされるため、リレーショナル モデルのストレージとクエリに大きな制限があります。ただし、関心のある Web サイトがすべて同じタイプの Web サイトであり、Web ページ上の特定のコンテンツのみに関心がある可能性もあります。そのため、それらを構造化データに整理できるため、MySQL は依然として次のような機能を備えています。この点に関しては。しかし、それでも、アプリケーションが将来開発されるにつれて、データ ストレージの柔軟性は依然として犠牲になるでしょう。したがって、クローラなどのアプリケーションにとって、MySQL の主な問題は、データ モデルの柔軟性が十分ではなく、水平方向に拡張できない (または拡張するのが難しい) ことです。
上記の 2 つの主な問題に関する限り、HDFS は実際にそれらを処理できます。したがって、HDFS は、クローラなどのアプリケーションにおいて MySQL よりも優れています。同様に、MongoDB もこれら 2 つの問題をうまく解決します。では、HDFS に対する MongoDB の利点は何でしょうか?非常に重要な点は、MongoDB がリレーショナル データベースと同様にドキュメント内の任意のフィールドにセカンダリ インデックスを確立できるため、分析プロセス中にインデックスによってもたらされるパフォーマンスの利点を最大化できるという事実から来ています。さらに、HDFS はファイル システムに近いものを提供し、MongoDB は地理的分散や期限切れのドキュメントのアーカイブなどの操作を MongoDB 上で簡単に実装できる柔軟なデータベース テクノロジを提供します。
エコシステムの観点から見ると、HDFS の周辺ツールはもっと充実しているはずですが、開発の歴史はどこにあるのでしょうか。 MongoDB は現在主に以下をサポートしています:

• BI コネクタ: MongoDB は、既存の BI ツールを利用するために PostgreSQL または MySQL インターフェイスを外部に提供します

• Spark コネクタ: MongoDB は計算のために Spark に接続します

質問に戻りますが、公平に見て、どのデータベースを使用しても、正しく使用すればパフォーマンスに質的な違いはありません。可用性の問題に関しては、MongoDB の高可用性により、第 2 レベルのエラー回復を実現できます。 MySQL にも対応するソリューションがありますが、運用とメンテナンスがより複雑になる可能性があります。安全性に関しては各社とも大きな差はありません。

MySQL は大量のデータを処理する場合に非常に緊張します。逆に、MongoDB はクラスター経由の方が優れています。

実際、データベースはまったく必要ありません。これはクローラーにとって IO ボトルネックになる可能性があります。

Hadoop で HDFS を試すことができます。

この場合、基盤となるデータ ストレージは、一般に、春節祭のライブ ブロードキャスト中の集中砲火などのリアルタイム モニタリングに MySQL の .mangodb+hadoop の組み合わせを使用する方が適しています。 mongodb はミリ秒レベルのデータクエリ、リアルタイム分析をサポートします。 Hadoop は一度書き込めば何度でも取得できます。MySQL と組み合わせると、プロジェクトにより適しています。セキュリティは実際にはほぼ同じです。結局のところ、データベースが分離されていれば、主要なファイアウォールが安全であれば問題ありません。したがって、MySQL を選択することをお勧めします。

これから大量のデータを取得するクローラーを作成します (後に 200 万から 2,000 万レコードに達すると予測されます)

この少量のデータしかない場合は、MySQL または MongoDB が機能しますが、比較的に言うと、MongoDB の方が柔軟性があります。

200w と 2000w の間は比較的データ量が少ないので、どちらが使いやすいかを考えて、そちらを使用してください。ただし、基本的に、データベースが数千万レベルに達すると、クエリのパフォーマンスの問題が発生するため、データが増大し続ける場合は、mongodb の使用を検討できます。結局のところ、mysql クラスターよりも mongodb シャードクラスターを構築する方がはるかに簡単です。そして、より柔軟に扱うことができます。

1. チームが Hadoop テクノロジー スタックに精通していない限り、200 ～ 2000 ワットのデータ量に Hadoop を使用する必要はありません。

2. パフォーマンスの観点から見ると、このレベルのデータは MySQL と mongoDB の両方で使用できます。その鍵は、データが構造化されているか非構造化されているかによって決まります。

たまたま私が働いている会社がこの分野で何かを行ったので、参考までにそれについてお話しします。
ここで私が主に行っているのは、ログの処理とアーカイブ、日々発生するアクセスログのホット/コールド統計の作成、各種データレポートの作成などです。実際、クローラも結局は同じようなものです。
最初はMYSQLも検討しましたが、1つのMYSQLテーブルで数千万を超えるとパフォーマンスが悪かったので、その時はmongodbを使うことにしました。
実際に行うことは非常に簡単です。Python を使用して毎日のサーバー ログをローカルでキャプチャし、グループ集計を計算する必要がある場合は、pandas ライブラリを使用してデータを構築するだけです。最後に、毎日のデータ結果を mongodb に投げ込むだけです。
同社には現在約 8KW の mongodb データがあり、データ検索効率は依然として許容範囲内です。インデックスを追加することを忘れないでください。
mongodb にデータを記録することに加えて、オペレーション システムのデータ統計結果を特別に呼び出すための RESTful API も作成しました。操作側は、mongodb から統計を収集するためのテーブルも作成します。は再度合計データとして計算され、MYSQL に配置されるため、データが API から取得されるたびに mongodb を呼び出して集計計算を繰り返し実行する必要はありません。