存储2亿个可变长度的字符串会导致碎片/表格膨胀

Question

我试图存储超过2亿个键值对。超过50％的键的值将在一周内更改，并且将永久删除约5％的行。使用传统的SQL解决方案，这已被证明会导致大量碎片，导致表膨胀（原始表大小的4倍）以及一些性能问题。在SQL中解决此碎片需要相当长的停机时间。我们使用了重建索引和重组技术，但两者都无法跟上碎片。此外，我需要将这些数据复制到另外两个系统，这也证明是非常有问题的。

表设计很简单：

关键NVARCHAR（50）

值VARCHAR（MAX）

我们正在考虑使用像MongoDB这样的其他技术，但担心我们会遇到类似的碎片问题。

有没有人对我们如何以可能限制碎片的不同方式解决此问题有任何建议？

Answer 1

这对MongoDb来说非常完美。

MongoDb还支持capped collections（您可以使用它）。您可以在数据库中拥有对象，在某种意义上，当您不再需要它时，它会滚动出视图。如果事情每周都在变化，这可能会减少您对数据库的管理。

Answer 2

也许有一种方法可以在MSSQL中创建版本控制和分区机制：

<强>版本： 如果更改了值，则旧值将标记为is_active=False并插入新值。然后，您每周批量删除值，这将导致整体碎片减少​​。您可以使用视图仅过滤is_actvie=True值。

<强>分区： 我不确定这里最好的分区方案是什么。由于某些值具有较长的使用寿命，因此我认为按时间划分将不起作用。也许按密钥划分更好。这样，至少，您可以尝试单独对每个分区进行碎片整理，并且更好地包含降级。

Answer 3

MongoDb是一个不错的选择，因为它易于设置和管理，可以轻松实现水平扩展（出色的分片支持）和轻松复制（通过副本集）。只要索引适合内存，性能就很好。但是，MongoDb也容易碎片化。从v2.0开始，理论上可以通过使用“compact”命令来管理碎片。要在没有任何停机时间的情况下压缩数据库，您必须使用复制，因为该过程将是：

• 对于每个副本集（分片）
  • 紧凑型奴隶
  • 下台大师
  • compact master
  • （可选）恢复原始主人

以下是一个示例脚本：https://github.com/mongodb/mongo-snippets/blob/master/js/compact-example.js