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