2

私は多くのキーと値のペアを書いているアプリケーションに取り組んでいます。本番環境では、データベースのサイズは数百テラバイト、場合によっては数ペタバイトにもなります。キーは 20 バイトで、値は最大 128 KB で、4 KB より小さいことはほとんどありません。現在、MongoDB を使用しています。明らかに多くのオーバーヘッドが発生しているため、パフォーマンスはあまり良くありません。MongoDB はファイル システムに書き込み、LVM はさらに RAID 6 アレイに書き込みます。

私たちの要件は非常に基本的なものなので、汎用データベース システムを使用するとパフォーマンスが低下すると思います。ドキュメント (または「値」) を生のドライブ (実際には RAID アレイ) に直接配置し、キー (および値が生のドライブに存在する場所へのポインター) を格納できる単純なデータベース システムを実装することを考えていました。ドライブ) を、SSD に支えられた高速なインメモリ データベースに格納します。これにより、（ファイルシステムを使用するのとは対照的に）断片化がまったくないため、読み取りも高速化されます。

ドキュメントが削除されることはめったにありませんが、デバイスで使用可能な空き容量のプールを維持する必要があります (ファイルシステムが提供するもの)。

私の質問は、これは本当に重要な改善をもたらすのでしょうか? また、このようなことを行う文書保管システムはありますか? または、開始点として使用できる同様のものはありますか?

4

2 に答える 2

5

ApacheCassandraが頭に浮かびます。これは、大規模なスケーリングが関係する現在の選択されたNoSQLソリューションです。大規模なスケーリング要件を持ついくつかの大企業での生産使用量が見られます。 少し作業を重ねた結果、ストレージエンジンの配置に合わせてデータモデルを再考するには、少し時間がかかると言えます。有名な引用記事「WTFはスーパーコラムです」は、これをしっかりと紹介しています。警告：Cassandraは、巨大なデータセットを保存することを計画している場合にのみ意味があり、単一障害点のない配布はミッションクリティカルな要件です。あなたがあなたのデータを説明した方法で、それはぴったりのように聞こえます。

また、少なくともキー参照を保存するために、redisを調べたことはありますか？メモリ要件は、単一のインスタンスが処理できるものをはるかに上回っていますが、Redisをシャーディングするように構成することもできます。これは主なユースケースではありませんが、CraigslistとGrouponの両方で本番環境で使用されています。

また、mongoを最適化するために可能な限りのことを行いましたか？特に、インデックス作成を改善する方法を調査しましたか？Mongoはディスクに保存しますが、可能であればセットの最もホットな部分をメモリに保持するように最適化すると、比較的パフォーマンスが高くなるはずです。

一時的すぎない場合、このデータをキャッシュすることは可能ですか？

私はこれであなた自身を転がすことに対してあなたに完全に警告します。 公正な警告です。それはあなたや他の誰かをノックするものではありません。それは私が以前に頭を悩ませた社内の開発者によって書かれたカスタムの「データインデックス」を個人的に維持しなければならなかったということです。私の仕事では、私たちは大規模な私たちのシステムの主要なパフォーマンスのボトルネックであるディスクキーバリューストアで、それ以来会社から離れた開発者によって書かれました。今日のエキサイティングなNoSQLの機会の中で、そのようなソリューションが行き詰まっているのはイライラします。上で引用したようなプロジェクトは、オープンソースコミュニティの全体的な強みを利用して、それらの使用を証明および最適化します。時間、労力、昇進に多大な投資をしない限り、それはあなたがあなた自身の解決策に取り組むことを達成することができるものではありません。少なくとも、すべてのnosqlオプションを確認することをお勧めしますそして多分あなた自身を転がすのではなくあなたが貢献できるプロジェクトを見つけるでしょう。データベースサーバー自体を作成することは、特にあなたが与えた要件では、間違いなく巨大なチームを必要とする重要なタスクです（しかし、あなたがそうすることになった場合、私はあなたに幸運を祈ります！=））

于 2013-03-20T13:36:28.370 に答える