3

15 TB 以上の範囲のデータ ウェア ハウスを構築しています。ストレージは安価ですが、予算が限られているため、データ形式が頻繁に変更されるため、パフォーマンスと柔軟性を維持しながら、できるだけ多くのデータをそのスペースに詰め込む必要があります。

SQL ソリューションとして Infobright (コミュニティ エディション) を試してみましたが、ストレージとパフォーマンスの点では素晴らしいですが、データ/テーブルの変更の制限により、ほとんどうまくいきません。また、エンタープライズ版の infobright の価格設定はかなり高額です。

MongoDB を調べたところ、1 つのことを除いて有望に思えます。私は第 10 世代の男性とチャットしていましたが、彼は、パフォーマンスと柔軟性を実現するためにデータをフラット化するため、ストレージ スペースに関してあまり考えていないと述べました。彼らの意見では、ストレージは安すぎます。悩む今日この頃。

そのため、経験豊富な mongo ユーザーであれば、そのストレージ スペースと mysql についてコメントできます (これは、現在比較している対象の標準であるため)。大きいか小さいか、おおよその比率を教えてください。SQLに入れるデータの種類や、フィールドの定義方法、インデックス作成などに非常に依存する状況であることは知っています...しかし、私は一般的なアイデアを得ようとしています。

事前に助けてくれてありがとう！

4

2 に答える 2

3

MongoDB は、小さなディスク スペース用に最適化されていません。「ディスクは安価です」と言ったように。

私が見て読んだことから、次の理由により、必要なディスク容量を見積もるのは非常に困難です。

  • インプレース更新を可能にするドキュメントのパディング
  • 属性名は各コレクションに保存されるため、省略形を使用するとかなり節約できます
  • ビルトインコンプレッションなし (現時点)
  • ...

私見一般的なアプローチは、プロトタイプを作成し、データを挿入し、特定のユースケースに必要なディスク容量を確認することです。クエリ (挿入と更新) をより現実的にモデル化できるほど、より良い結果が得られます。

詳細については、http://www.mongodb.org/display/DOCS/Excessive+Disk+Spaceも参照してください。

于 2012-10-04T09:23:51.157 に答える