问创建可扩展的MongoDB短ids的策略

EN

通常的方法是对唯一的id进行base64编码，但是：

为每个文档添加一个带索引的postid字段

您肯定想使用这种方法。在这两种方法中，我会说这种方法是最具伸缩性和性能的，首先它只需要一次往返就可以得到一个简短的URL详细信息，而第二种选择需要2次。另一个考虑因素是维护额外集合的索引开销不足，这有点不费吹灰之力。

我也不会替换文档中的_id字段，因为在可预见的将来，默认的ObjectId仍然有用。

因此，这将URL的短码限制为一个单独的字段和索引(唯一键)。

下一件事是您不想要一个ID，它迫使您在每次插入之前查询数据库的唯一性。这就是ObjectId大放异彩的地方。ObjectId擅长在客户端应用程序中创建，同时在数据库中是唯一的，而不必专门查询这些假设。

不需要首先查询数据库的唯一ids通常是基于时间的。在PHP ( http://php.net/manual/en/function.uniqid.php )和MongoDB驱动程序( http://docs.mongodb.org/manual/core/object-id/ )中，甚至在github上链接的插件( https://github.com/dylang/shortid/blob/master/lib/shortid.js#L50 )中，它们都使用时间作为唯一的基础。

考虑到您所链接的插件不会查询数据库以检查其it的唯一性，我想说这个插件的性能可能相当好，如果您将它与您所说的第一个解决方案一起使用，您应该会得到一个很好的基准测试结果。

如果你想用自定义的用户友好的短id替换内置的ObjectID，那么就这么做吧。您可以使用内置的_id字段，也可以为您的自定义ids添加一个新的唯一索引字段id。使用内置的ObjectID的好处是，即使你的数据库非常大，它们也不会复制。所以，用短id代替它们，你就冒着id重复的风险。

现在来看一下表演。我认为最好的解决方案不是查询数据库中的id，因为通过适当调整id长度，重复的可能性非常小。因此，在此模型中处理is重复的最好方法是检查Mongo响应。如果它返回"duplicate key error“，那么你应该生成一个新的。

现在是关于缩放的问题。要缩放您的自定义it，您只需向其添加一些符号即可。“重复键错误”将触发进行该更改。通常不会有这样的错误。因此，如果它们开始出现，那么就是时候进行扩展了。

我不认为为_id字段生成ObjectId会直接影响可伸缩性或性能。这是如何发生的呢？

主要区别在于，ObjectIds是由MongoDB创建的，您不必为此承担任何责任。否则，您必须自己确定id的最佳大小，并确保存储在集合中的文档的每个_id字段的值是唯一的。它是必需的，因为_id用作主键。如果您没有非常大的集合，且需要自定义标识符的值，则可以证明这是合理的。

但是使用_id字段有这样的额外好处，它将ObjectId值存储为从时间创建对象id的机会，并在查询中利用这一事实。也可以通过getTimestamp()方法获取ObjectId创建的时间戳。在这种情况下，对_id进行排序相当于按创建时间排序。

但是，如果您打算在URL或HTML语言中使用ObjectId，那么出于安全考虑，您可以对其进行加密。以防止信息泄露和访问对象的创建时间。这可能会带来安全风险。

关于您的解决方案：

1)我认为这是一个非常方便和灵活的解决方案。在这种情况下，您可以在不直接依赖于_id的postId中指定任何值。

但这种解决方案的一个小缺点是，您必须拥有额外的字段并创建额外的索引。而_id是自动索引的。

2)从性能和noSQL方法的哲学角度来看，我认为这不是一个好的解决方案。