8

iPhoneアプリケーションに基づいてデータを保存するために、RavenDBでいくつかのテストを行っています。アプリケーションは、キーの GUID を含む 5 つの GPS 座標の文字列を送信します。各ドキュメントが約 664 ～ 668 バイトであることを RavenDB で確認しています。これは、小数点以下 10 桁と GUID では巨大です。誰かが私が間違っていることを理解するのを手伝ってくれますか? 100 万レコードがディスク上のギグを超えると、サイズが異常に大きくなることに気付きました。私の計算では、それははるかに小さいはずです。純粋にデータ サイズに基づいて、ドキュメントは約 100 バイトであるべきではありませんか? ドキュメント データベースにオブジェクト スキーマが組み込まれているとすると、その 2 倍の 200 バイトになります。その計算を考えると、データベースは 100 万レコードで約 200 メガバイトになるはずです。しかし、それは10倍大きいです。誰か助けてくれませんか？

(友達に数学をチェックしてもらいましたが、少しずれていました - 数字が更新されました)

4

1 に答える 1

19

一般的な原則として、NoSQL データベースはディスク容量に対して最適化されていません。これは、RDBMS の伝統的な要件の一種です。多くの場合、NoSQL では、さまざまな理由から、データを複製または三重に保存することを選択します。

特に RavenDB では、各ドキュメントは JSON 形式であるため、オーバーヘッドが発生します。ただし、実際には BSON 形式でディスクに永続化されるため、数バイト節約できます。この実装の詳細は、クライアントから隠されています。また、すべてのドキュメントには、メインのドキュメント コンテンツと関連するメタデータの 2 つのストリームがあります。これは非常に強力ですが、追加のディスク容量を必要とします。ドキュメントとメタデータの両方が、ESENT でサポートされているドキュメント ストアに BSON 形式で保持されます。

次に、データへのアクセス方法を検討する必要があります。作成する静的インデックスと、LINQ API を介して Raven に作成を依頼する動的インデックスでは、データがインデックス ストアにコピーされます。これは、独自のインデックス ファイル形式を使用して Lucene.net で実装された別のストアです。ディスク容量の要件を見積もる場合は、これを考慮する必要があります。(ところで-RDBMSソリューションのインデックスにもこの懸念があります)

ディスク領域のすべてのバイトを最適化することに非常に関心がある場合、おそらく NoSQL ソリューションは適していません。市場に出回っているほぼすべての製品には、これらのタイプのオーバーヘッドがあります。ただし、今日のディスク容量は安価であることを覚えておいてください。リレーショナル データベースは、ストレージが発明された時点では非常に高価だったため、ディスク スペース用に最適化されています。世界は変化し、NoSQL ソリューションはそれを取り入れています。

于 2012-11-19T15:48:26.770 に答える