Purpose of a separate index storage for primary id for MongoDB

[Moditha Hewasinghage]

Hi,

I have asked the question on the wired tigr group as well but i think this will be a better audience.

Can anyone explain me or direct me for the reason behind storing the primary id separately in MongoDB when using wired tiger. If the key of the b-tree for the storage is the primary id itself wouldn't it be redundant to store the primary Id separately ? I understand that this could be the case for a secondary index to store it separately. But why do so for the primary index ?

Moreover, is there a way to see the actual statistics of the b-tree such as the depth of the tree, size of a leaf and internal nodes instead of the maximum values ? And is the b-tree a clustered index or not ?

Thank you,

Regards,

Moditha.

[MarkCallaghan]

I assume this is an artifact of supporting only mmap many years ago, which doesn't do clustered indexes. Then the engine API arrived and this has yet to be fixed. I was impressed by the speed at which the engine API was added and the speed in general at which the MongoDB team reduces their tech debt, so I expect this to eventually be fixed.

There is a jira issue for this and you can vote/watch it. But there hasn't been public activity on it -- https://jira.mongodb.org/browse/SERVER-14569

I have written about the impact from extra indexes on performance. It can be significant as it means extra indexes are used, maintained and searched.
* http://smalldatum.blogspot.com/2015/07/summary-of-linkbench-for-mongodb-mysql.html
* http://smalldatum.blogspot.com/2015/07/linkbench-for-mysql-mongodb-with-cached.html

[david.b....@gmail.com]

If I recall there were access methods even in the SEAPI still using this for work units. At Percona we talked about removing it specifically with Igor for RocksDB but there was as you said Mark some TD that needs clean up and as such is not as simple as disabling the extra index. 

That was pre 4.0 however so many be there been fixed I have not been focused on MongoDB most recent api changes as I should be since leaving Percona. 

Cheers

David 

Sent from my iPhone

--
You received this message because you are subscribed to the Google Groups "mongodb-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-dev...@googlegroups.com.
To post to this group, send email to mongo...@googlegroups.com.
Visit this group at https://groups.google.com/group/mongodb-dev.
To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-dev/f3b8d998-64aa-4353-bf54-a0112cd74451%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Geert Bosch]

As Mark Callaghan indicated, the origin of this decision was the MMAPv1 storage engine. There, indexes would map keys to 'DiskLoc' values, containing a pair of 32-bit integers representing the file number in the database and offset in that file. Since then we have replaced DiskLoc by a RecordId that does not represent a physical location, but rather a logical document number.

As you note, we could gain efficiency (both time and space) by using the primary key directly to index the data. However, as MongoDB puts few restrictions on the primary key, it is common for these primary keys to have a non-trivial size. This in turn means that all secondary indexes become less efficient. Some users have many indexes, so they'd be negatively affected by such a change. Making clustered indexes a non-default opt-in means that the large majority of users will not benefit. For clustered indexes to be a win for sharded clusters, one would likely want to cluster on a document key consisting of the shard key followed by _id.

So, implementing clustered indexes is more complex than it may seem at first. If you're interested, please vote and/or watch SERVER-14569. If you have a specific use case yourself that would benefit in particular, feel free to share that.

[MarkCallaghan]

Geert,

If the decision were mmap style (secondary indexes point to rows directly) vs clustered index style there might be a debate. But I don't see how that holds in this case because there are extra indexes leading to more space used, more CPU/IO spent maintaining the extra indexes, more CPU/IO spent accessing the extra index in addition to the index that you wanted to access. I don't see how the current situation is anything but lousy for performance.

I have much respect for you and the core Mongo team, but I disagree. Alas, I am no longer trying to make MongoDB faster so my opinion doesn't matter as much. We might never learn whether fixing this is useful unless someone spends a lot of time on it. I have quietly shared many perf reports showing a significant difference between Mongo/WiredTiger and MySQL/{MyRocks, InnoDB} for IO-heavy transaction processing workloads and I suspect this is a significant part of the problem. But someone would have to spend a lot of time on this to figure it out and maybe it isn't a priority on your side.

[MARK CALLAGHAN]

I assume there will be a small number of workloads for which proper support of clustered indexes hurts their performance with MongoDB, but most of them can adapt by using a surrogate PK. There is no workaround to avoid the perf penalty from the current code.

--
You received this message because you are subscribed to the Google Groups "mongodb-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-dev...@googlegroups.com.
To post to this group, send email to mongo...@googlegroups.com.
Visit this group at https://groups.google.com/group/mongodb-dev.

To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-dev/0e0eedb9-7546-42c7-86da-4611702eea9d%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Mark Callaghan
mdca...@gmail.com

[Geert Bosch]

I don't think we actually disagree here. Clustered indexes are desirable for performance, and doing them properly requires significant engineering time. However, that does not mean they will not get done eventually. We always appreciate your reports as valuable input and will keep making performance improvements in addition to implementing new features, such as multi-document cross-shard transactions.

[Moditha Hewasinghage]

Well I am not an expert in MongoDB internals. But, as a user what I have seen with some of the experiments is that this also has an impact on cache usage

1. The index b-tree and the data b-tree compete for the cache because for the cache policy its two different structures trying to use the memory space.
2. The frequency of the access to both b-trees are the same if it is access through the primary index.
3. If the memory is below a certain level this results in that even if the index fits in the memory it will not (i am not sure what the exact threshold will be)
4. this will result in a performance hinderance as not only the data, but also the index needs to be fetched from the disk
5. if you could pin the index or give it higher priority in the eviction policy it could be benificial

This is just my observations and view on the matter.