Live data from Hacker News

Document-level locking and compression come to MongoDB

docs.mongodb.org

1–10 of 13 posts

Re: Document-level locking and compression come to MongoDB

#3
Keep in mind that document-level locking will be available only for WiredTiger storage engine and not default one (MMAPv1). MMAPv1 will support only collection level locking. The same story goes for compression. Also only available in WiredTiger. Question remains - how stable will WiredTiger be in 2.8...

Re: Document-level locking and compression come to MongoDB

#5
I haven't checked WiredTiger storage driver nor it's source but I think it's safe to say that the in-place updates are not possible with Wired Tiger (even without compression) and most future storages.

People must be careful not to heavily update big documents with these.

Re: Document-level locking and compression come to MongoDB

#6

Nice to see WiredTiger getting some love. LevelDB gets all the credit these days (and LMDB to a [much] lesser extent).

What is WiredTiger? I checked the github, but couldn't find any high level information other than it uses a LSM much like LevelDB. What advantages/tradeoffs have they made in WiredTiger vs. LevelDB?

Re: Document-level locking and compression come to MongoDB

#8

Nice to see WiredTiger getting some love. LevelDB gets all the credit these days (and LMDB to a [much] lesser extent).

What is WiredTiger? I checked the github, but couldn't find any high level information other than it uses a LSM much like LevelDB. What advantages/tradeoffs have they made in WiredTiger vs. LevelDB?

It's an embedded ordered key value store, like LevelDB. It's actually configurable to either LSM or BTree. Everything I read says it's much faster than LevelDB, but I never tested it myself.

Re: Document-level locking and compression come to MongoDB

#9
I would say that document-level locking is a big deal for MongoDB. When I was working at a company running MongoDB, we were running into latency issues when multiple larger documents would be updated or created. Coupled with the fact that we were using AWS and provisioning even 1000 IOPS was expensive and limited compared to IOPS available to SSDs. On top of all of that we weren't using the fire-and-forget default for writing data. We were requesting write receipts.

Document-level locking will likely result in much better performance for MongoDB.

Post reply on HN