MongoDB中的伪主键 - 坏主意？

http://code.flickr.com/blog/page/4/MongoDB中的伪主键 - 坏主意？

本博客文章是从Flickr的开发者的，并概述了简化的方法来生成的GUID使用MySQL的一个分片数据库环境的照片。

我正在使用MongoDB进行数据存储的应用程序，该应用程序对嵌入文档中存储的项目有类似的要求。基本上，集合中的文档代表项目列表，然后是中的单个项目，其中每个文档都需要具有某种标识符以用于查找目的。我宁愿不将项目放在不同的集合中，因为不是项目的列表键实际上只是元数据，并且不需要拥有自己的集合。理想情况下，它应该是一个文件。

我在想博客文章中详述的方法可以实现来解决这个问题 - 一个端点为这些条目生成GUID并保存上次使用的值。问题是，我不确定这种方法是否会在将数据存储分为mongo时引入问题。我没有任何经验在几台机器上发布Mongo。我假设我可以让应用程序层在保存数据时检查此端点，并将_id键设置为适当的，但我不知道这将如何影响对数据集的查询。

设置这种GUID系统是否有缺陷？我意识到它与一般NoSQL的一些原则背道而驰，但是由于文档是嵌入的，所以还有什么替代方法？

来源

2011-11-23 DeaconDesperado

您是否考虑过简单地使用MongoDB中提供的ObjectId功能？ http://www.mongodb.org/display/DOCS/Object+IDs您可以在自己的字段中使用这些字段，也可以在集合中为文档使用id字段。 –

@Hightechrider这实际上是我不确定的 - 如果中断默认设置，其中ObjectIds是唯一的主标识符，并且它们只在文档中出现一次，则会导致分割写入/读取行分割。从文档看来，这似乎不是一个问题，我阅读的内容越多... – DeaconDesperado

以这种方式使用它们是很好的。 –

我认为ObjectID是要走的路。它们的存储比GUID/UUID更紧凑，并且保持大致递增的顺序，这对索引有好处。它也被设计为生成客户端，而不需要文章中描述的票务服务器。与他们的解决方案相比，唯一的缺点是它们使用12个字节，而int64使用8个（GUID/UUID使用16进制或32进制加上几个字节的开销）。另一个潜在的缺点（在大多数情况下更可能是一种好处）是因为创建时间在ObjectId中编码，如果它们用于公共可见标识符，它可能会泄漏可能不需要的信息给用户，例如另一个用户签名为您的服务。

来源

2011-11-28 19:06:50 mstearn

MongoDB中的伪主键 - 坏主意？

回答

相关问题