1

I have a MongoDB with compound index by 4 fields and I want to reorder physical data distribution at HDD by this index. I am looking for something like creating chunk in NOT sharded environment.
Is any way to do this?

UPDATE:
As workaround solution I can enumerate my collection by index and write it to another collection in this order. I didn't test it, but it should make sence.

  • This makes only sense for spinning disks, if any. The seek times on spinning disks may actually cause some considerable delay. On the other hand, you have worse problems than seek latency when using spinning disks – the IO performance in general is horrible. There is a reason why SSDs are the preferred technology in production environments and I am not too sure wether doing workarounds is cost efficient in the long run. Scale your workaround up, and it itself will require resources beyond the point of simply using SSDs. – Markus W Mahlberg Oct 18 '15 at 7:47
  • I understand that SSD is much more better. But unfortunately I haven't it on my envoronment. – Alexander Oct 19 '15 at 9:26
2

The feature you are describing is a clustered index, which MongoDB (as at 3.2) does not support.

The most relevant feature request to upvote/watch is currently SERVER-3294.

I am looking for something like creating chunk in NOT sharded environment.

Chunks in a MongoDB sharded cluster are metadata representing contiguous ranges of shard keys. All documents for a given chunk range will exist on the same shard, but the chunk does not currently determine the locality of data on disk.

|improve this answer|||||
  • Thanks. I am looking for some workaround. Any ideas? – Alexander Oct 16 '15 at 10:58
  • @Alexander The order of indexes & data on disk is determined by the storage engine, so in the absence of a supported feature I don't think there is any effective workaround to influence this in a normal use case (collections with document updates and deletions). If you happen to have a much more narrow use case you could consider a capped collection, but this acts more like a FIFO queue (insert-only fixed-size collection where updates cannot grow documents). I would suggest tuning performance based on existing features, instead. – Stennie Oct 17 '15 at 11:30
  • In my case, documents wont be update or delete. The goal is to improve performance on existing data. I think, my problem is data fragmentation and I don't understand how capped collection can be useful. But thanks for your help. I'll be glad to hear any new ideas. – Alexander Oct 19 '15 at 9:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.