MongoDB和复合主键 [英] MongoDB and composite primary keys
问题描述
我正在尝试确定在mongo db中处理复合主键的最佳方法.在此系统中与数据进行交互的主键由2个uuid组成. uuid的组合被保证是唯一的，但是每个uuid都不是唯一的.
I'm trying to determine the best way to deal with a composite primary key in a mongo db. The main key for interacting with the data in this system is made up of 2 uuids. The combination of uuids is guaranteed to be unique, but neither of the individual uuids is.
我看到了几种管理方法:
I see a couple of ways of managing this:
-
使用由2个值组成的主键对象(如建议的此处)
使用标准的自动生成的mongo对象ID作为主键，将我的键存储在两个单独的字段中，然后在这两个字段上创建一个复合索引
Use a standard auto-generated mongo object id as the primary key, store my key in two separate fields, and then create a composite index on those two fields
使主键成为2个uuid的哈希
Make the primary key a hash of the 2 uuids
我目前不知道的其他一些很棒的解决方案
Some other awesome solution that I currently am unaware of
这些方法的性能含义是什么?
What are the performance implications of these approaches?
对于选项1，由于具有非顺序键，我担心插入性能.我知道这可能会杀死传统的RDBMS系统，而且我已经看到有迹象表明，在MongoDB中也是如此.
For option 1, I'm worried about the insert performance due to having non sequential keys. I know this can kill traditional RDBMS systems and I've seen indications that this could be true in MongoDB as well.
对于选项2，拥有一个系统永远不会使用的主键似乎有些奇怪.同样，查询性能似乎可能不如选项1那样好.在传统的RDBMS中，聚集索引可提供最佳查询结果.在MongoDB中这有多重要?
For option 2, it seems a little odd to have a primary key that would never be used by the system. Also, it seems that query performance might not be as good as in option 1. In a traditional RDBMS a clustered index gives the best query results. How relevant is this in MongoDB?
对于选项3，这将创建一个单一的id字段，但是在插入时，它也不是连续的.这种方法还有其他优点/缺点吗?
For option 3, this would create one single id field, but again it wouldn't be sequential when inserting. Are there any other pros/cons to this approach?
对于选项4，嗯...什么是选项4?
For option 4, well... what is option 4?
此外，在将来的某个时刻，有一些讨论可能使用CouchDB代替MongoDB.使用CouchDB会建议其他解决方案吗?
Also, there's some discussion of possibly using CouchDB instead of MongoDB at some point in the future. Would using CouchDB suggest a different solution?
MORE INFO: some background about the problem can be found here
推荐答案
您应该使用选项1.
主要原因是您说您担心性能-使用始终存在并且已经唯一的_id索引将使您不必维护第二个唯一索引.
The main reason is that you say you are worried about performance - using the _id index which is always there and already unique will allow you to save having to maintain a second unique index.
对于选项1，我担心插入性能会影响 非顺序键.我知道这会杀死传统的RDBMS系统 而且我已经看到有迹象表明在MongoDB中也是如此.
For option 1, I'm worried about the insert performance do to having non sequential keys. I know this can kill traditional RDBMS systems and I've seen indications that this could be true in MongoDB as well.
您的其他选项不能避免此问题，它们只是将其从_id索引转移到二级唯一索引-但是现在您有两个索引，一个是右平衡的，另一个是随机访问的.
Your other options do not avoid this problem, they just shift it from the _id index to the secondary unique index - but now you have two indexes, once that's right-balanced and the other one that's random access.
只有一个理由质疑选项1，即您是否打算仅通过一个或另一个UUID值来访问文档.只要您始终提供这两个值，并且(这部分非常重要)您在所有查询中始终以相同的方式对其进行排序，那么_id索引将有效地发挥其全部作用.
There is only one reason to question option 1 and that is if you plan to access the documents by just one or just the other UUID value. As long as you are always providing both values and (this part is very important) you always order them the same way in all your queries, then the _id index will be efficiently serving its full purpose.
详细说明为什么在比较子文档{ a:1, b:2 }不等于{ b:2, a:1 }时必须始终以相同的方式对两个UUID值进行排序-您可能有一个集合，其中两个文档具有这些值_ID.因此，如果您首先将_id与字段一起存储，则必须始终在所有文档和查询中保持该顺序.
As an elaboration on why you have to make sure you always order the two UUID values the same way, when comparing subdocuments { a:1, b:2 } is not equal to { b:2, a:1 } - you could have a collection where two documents had those values for _id. So if you store _id with field a first, then you must always keep that order in all of your documents and queries.
另一个警告是_id:1上的索引将可用于查询:
The other caution is that index on _id:1 will be usable for query:
db.collection.find({_id:{a:1,b:2}})
但不能用于查询
db.collection.find({"_id.a":1, "_id.b":2})
这篇关于MongoDB和复合主键的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
