大量のデータを生成してディスクに保存するシステムに取り組んでいます。同社で以前に開発されたシステムは、データを保存するために通常のファイルを使用していましたが、いくつかの理由で管理が非常に困難になりました。
NoSQLデータベースは私たちにとって良いソリューションだと思います。保存するのは、通常、メタデータで注釈が付けられたドキュメント（通常は約100Kですが、場合によってははるかに大きくなったり小さくなったりすることもあります）です。クエリのパフォーマンスは最優先事項ではありません。優先順位は、I/Oができるだけ面倒にならないように書くことです。データ生成速度は約1Gbpsですが、将来的には10Gbps（またはそれ以上）に移行する可能性があります。
私の他の要件は、（できれば十分に文書化された）CAPIの可用性です。現在、MongoDBをテストしています。これは良い選択ですか？そうでない場合、他にどのようなデータベースシステムを使用できますか？
データ生成の速度は約1Gbpsです...私は現在MongoDBをテストしています。これは良い選択ですか？
わかりました。明確にするために、データレートは10秒あたり約1ギガバイトです。それで、あなたは20分かそこらごとに1TBのハードドライブを満たしていますか？
MongoDBの書き込み速度はかなり安定していますが、RAMとデータの比率が適度に低い状況で理想的に使用されます。少なくともプライマリインデックスをいくつかのデータとともにメモリに保持する必要があります。
私の経験では、5〜10GBのデータごとに約1GBのRAMが必要です。その数を超えると、読み取りパフォーマンスが劇的に低下します。100GBのデータに対して1GBのRAMに到達すると、インデックスがRAMに収まらなくなるため、新しいデータの追加でさえ遅くなる可能性があります。
ここでの大きな鍵は次のとおりです。
どのクエリを実行する予定ですか？MongoDBはこれらのクエリの実行をどのように簡単にしますか？
データはすぐに十分なスペースを占有するため、基本的にすべてのクエリがディスクに送られます。非常に具体的なインデックス作成とシャーディングの戦略がない限り、ディスクスキャンを実行するだけになります。
さらに、MongoDBは圧縮をサポートしていません。したがって、多くのディスク領域を使用することになります。
そうでない場合、他にどのようなデータベースシステムを使用できますか？
圧縮されたフラットファイルを検討しましたか？または、HadoopのようなビッグデータのMap / Reduceシステム（HadoopはJavaで記述されていることを知っています）
Cが重要な要件である場合、東京/京都内閣を見たいと思いませんか？
編集：詳細
MongoDBは全文検索をサポートしていません。そのようなことについては、他のツール（Sphinx / Solr）を探す必要があります。
ラージインデックスは、インデックスを使用する目的を無効にします。
あなたの数によると、あなたは1000万の文書/20分または約30M/時間を書いています。各ドキュメントには、インデックスエントリに約16バイト以上が必要です。ObjectID用に12バイト+2GBファイルへのポインター用に4バイト+ファイルへのポインター用に1バイト+ある程度のパディング。
すべてのインデックスエントリに約20バイトが必要であるとすると、インデックスは600MB/時間または14.4GB/日で増加します。そして、それは単なるデフォルトの_idインデックスです。
4日後、メインインデックスはRAMに収まりなくなり、パフォーマンスが劇的に低下し始めます。（これはMongoDBで十分に文書化されています）
したがって、実行するクエリを特定することが非常に重要になります。
カサンドラを見てください。書き込みは読み取りよりもはるかに高速です。おそらく、それがあなたが探しているものです。