我正在使用RavenDB进行一些测试，以便根据iphone应用程序存储数据。该应用程序将发送一串5个GPS坐标和一个GUID的密钥。我在RavenDB中看到每个文档大约是664-668字节。对于10位小数和一个guid来说，这是巨大的。有人能帮助我理解我做错了什么吗？当一百万条记录超过磁盘上的一个演出时，我注意到它的大小非常大。根据我的计算，它应该小得多。纯粹基于数据大小不应该是文件大约100字节？并且鉴于文档数据库具有内置的对象模式，假设将其加倍为200字节。鉴于该计算，数据库应该是大约200兆，具有100万条记录。但它要大十倍。有人可以帮我解决数学问题吗？
（有一位朋友检查我的数学，我稍微关闭了 - 更新了数字）
答案 0 :(得分：17)
作为一般原则，NoSQL数据库未针对磁盘空间进行优化。这是RDBMS的传统要求。通常使用NoSQL，您将选择以出于各种原因将数据一式两份或一式三份存储。
特别是使用RavenDB，每个文档都是JSON格式，因此你有一些开销。但是，它实际上是以BSON格式保存在磁盘上，节省了一些字节。此实现细节从客户端隐藏。此外，每个文档都有两个流 - 主文档内容和关联的元数据。这非常强大，但确实占用了额外的磁盘空间。文档和元数据都以BSON格式保存在ESENT支持的文档存储中。
然后您需要考虑如何访问数据。您创建的任何静态索引以及您要求Raven通过其LINQ API为您创建的任何动态索引都会将数据复制到索引存储中。这是一个使用Lucene.net专有索引文件格式实现的独立存储。如果要估算磁盘空间要求，则需要考虑这一点。 （顺便说一句 - 你也会关注RDBMS解决方案中的索引）
如果您非常关心优化磁盘空间的每个字节，可能NoSQL解决方案不适合您。几乎市场上的每种产品都有这些类型的开销。但请记住，磁盘空间今天很便宜。关系数据库针对磁盘空间进行了优化，因为存储在发明时非常昂贵。世界已经发生了变化，NoSQL解决方案也接受了这一点。