[mongodb-dev] 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

[d***@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

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
--
You received this message because you are subscribed to the Google Groups "mongodb-dev" group.
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' via mongodb-dev]

On Thursday, November 8, 2018 at 6:30:09 AM UTC-5, Moditha Hewasinghage

Post by 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 ?
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
<https://jira.mongodb.org/browse/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.

Post by 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.
--
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
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
<https://groups.google.com/d/msgid/mongodb-dev/0e0eedb9-7546-42c7-86da-4611702eea9d%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

--
Mark Callaghan
***@gmail.com

['Geert Bosch' via mongodb-dev]

Post by 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.

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.