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