Bad use-case for mongoDB

139 views
Skip to first unread message

Durga Deep

unread,
Nov 14, 2014, 4:44:06 PM11/14/14
to mongod...@googlegroups.com

Folks,

   Was looking at the following capability in mongodb
    We are planning on using a collection in mongodb to act as a MUTEX - so essentially using an entry in the collection so that four applications (running) on different JVMs not duplicate the effort. Based on this use-case and this capability of mongodb - we can set our TTL on this record to few minutes.

   But again was also looking at the following link - which illustrates how mongodb stores it's data.
   Would we end up doing a repairDatabase periodically as  illustrated in the link below ?
   Thank you!.
   D

  


s.molinari

unread,
Nov 15, 2014, 2:14:32 AM11/15/14
to mongod...@googlegroups.com
Can you please explain what this means more precisely? 

so that four applications (running) on different JVMs not duplicate the effort.

What effort, for example?

Scott 

Durga Deep Tirunagari

unread,
Nov 15, 2014, 3:20:30 PM11/15/14
to mongod...@googlegroups.com

We're making an entry in one of the collections in our mongodb.

In-order to avoid multiple servers (running on different Virtual Machines) trying to handle the same request from a queue. But once the request is served this record (entry) in the collection will be expired based on TTL.

Coming back to my question - from the memory allocation model in mongodb I see that this type of use case can cause the file system to fill up ?

_D

--
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.
 
For other MongoDB technical support options, see: http://www.mongodb.org/about/support/.
---
You received this message because you are subscribed to a topic in the Google Groups "mongodb-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mongodb-user/ZSWDUN9830o/unsubscribe.
To unsubscribe from this group and all its topics, send an email to mongodb-user...@googlegroups.com.
To post to this group, send email to mongod...@googlegroups.com.
Visit this group at http://groups.google.com/group/mongodb-user.
To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-user/12f6af6b-8ea7-4a2e-9e53-7e6ca5f1573f%40googlegroups.com.

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



--
_Durga Deep

s.molinari

unread,
Nov 16, 2014, 3:08:53 AM11/16/14
to mongod...@googlegroups.com
Is the queue supposed to be the Mongo collection itself? If so, you might want to think about using a capped collection. It is better made for queueing data. You'd just need to make sure the collection is big enough in size, so that the oldest document never gets deleted/ pushed out of the collection/ queue, before it was "worked" on by one of the JVMs.  

Also, as far as I know, Mongo reuses space available from deleted documents in a TTL scenario. So you shouldn't see an issue with space. What you might have an issue with is de-fragmentation of the data and thus a possible issue with performance. This is why the capped collection might also be a better choice for you. The data stays in a "serial" format and thus is highly performant.

Scott  


Durga Deep Tirunagari

unread,
Jan 29, 2015, 1:25:05 AM1/29/15
to mongod...@googlegroups.com
Sorry for the delay - 

This is the exactly what we were looking for thanks a million!

_D

--
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.
 
For other MongoDB technical support options, see: http://www.mongodb.org/about/support/.
---
You received this message because you are subscribed to a topic in the Google Groups "mongodb-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mongodb-user/ZSWDUN9830o/unsubscribe.
To unsubscribe from this group and all its topics, send an email to mongodb-user...@googlegroups.com.
To post to this group, send email to mongod...@googlegroups.com.
Visit this group at http://groups.google.com/group/mongodb-user.

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



--
_Durga Deep
Reply all
Reply to author
Forward
0 new messages