我测试了像CouchDB，MongoDB和Cassandra这样的NoSQL数据库，并观察到tendence吸收了相对于插入的键值对的非常大量的驱动器空间。 当比较CouchDB和MySQL无模式数据库时，CouchDB消耗的驱动器空间比MySQL多得多。 我知道默认情况下的键值数据库是版本控制的，并且具有很长的uuid并且需要关键优化 - 比较之间的比较是在MySQL中约1500万行与列出的NoSQL DB的1-5毫升文档之间。驱动器空间饥饿NoSQL的数据库
我的问题是：是否有NoSQL具有良好的压缩/压缩数据？ 为了让我的NoSQL数据库的大小接近5GB而不是50GB？
MongoDB具有“数据库修复”功能，该功能还可以执行压缩。但是，数据库运行时不会发生这种压缩。
但是，如果数据库空间是一个严重的问题，那么尝试设置一个MongoDB主/从对。由于数据需要压缩，请在从站上运行修复，使其“赶上”，然后将其切换。您现在可以安全地压缩主站。
但我必须回显jbellis的评论：您可能需要更多的空间，这些产品中的大部分都假设磁盘空间相对便宜。如果磁盘空间非常紧张，那么您会发现MongoDB的大小合理，但与表格CSV数据竞争会很困难。
想想这样，什么是更有效的空间？
格式相同的数据显然JSON将是较长的B/C你每次重复字段名。这里唯一的例外是具有100列的CSV文件，其中每行只填充少量列。 （但这可能不是你的数据）
你在检查“文件长度”还是实际的分配大小？
许多数据库稀疏地分配文件结构，它们的“长度”比它们的磁盘大小大得多。
我也检查过，那个文件缓冲区并不是那么大，所以我甚至没有考虑过像15毫升文件那样的db（即使它只有几GB）。我认为这个“太空饥饿”是无血清db的周期，但我不确定。 – jlmfao 2010-06-09 18:01:34
磁盘空间是今天最便宜的资源，所以如果你可以用较少的搜索量或较少的CPU进行交易，这是一个很好的交易。这就是卡桑德拉所做的。
磁盘空间是，但不是SSD空间，这正是您希望无论如何都要存储高性能DB的原因。另一方面，SSD寻求几乎免费。而且，将数据高效地打包到磁盘上的页面意味着可能在数据库中的页面缓冲层更有效的缓存，另一个胜利。 – TheManWithNoName 2010-12-22 07:16:56
磁性与ssd不是万能的;如果你的热门数据集适合内存（非常普遍！）那么ssd就是把钱冲到流失中。对于可预测性较差的工作负载，您确实看到了Cassandra部署在SSD上，其避免了对写入的寻求对于（非）写入放大而言是一个巨大的胜利。 – jbellis 2010-12-23 05:48:05
我认为问题是关键。 CouchDB将其数据存储在B树中。 UUID - 密钥是导致需要大量磁盘空间的原因。 B-tree存储的数据本质上是UptID的。尝试找到一个更适合b-tree的密钥。
的确如此，如果使用长字段名称，则在使用Mongodb时需要更多的磁盘空间。 Mongodb预先分配2GB的文件。 – TTT 2010-06-10 07:27:22
是的，在测试后，CouchDB具有“紧凑”选项，可以减少数据库大小多次（Cassandra由于组织大量写入而在后台执行操作）。 – jlmfao 2010-06-10 09:25:44
对此有吝啬的支持，如果1节点拥有足够的磁盘空间时出现问题，请尝试类似HBase或Cassandra的方法，只需添加更多节点即可轻松添加更多数据存储（以及处理能力！）。我不知道MongoDB/CouchDB是如何构建的，所以我不知道你是否可以轻松简单地对它们做同样的事情。 – Drizzt321 2011-08-18 23:19:52