I am currently evaluating feasibility of using MongoDB in our application. Here's the basic outline of our use case.
1. My main feature of interest at this time is flexible schema/efficient search(indexing). Our deployment model would be single-node, no replication, no sharding. Our transaction volume is expected to be moderate and expected collection size average about 1 million items/per collection in likely less than 10 collections. High availability currently is less critical for us, but data durability is important.
2. Our product offering is security appliance that runs in a headless, unattended fashion. Assume there will be no human intervention to perform monitoring or execute manual recovery steps upon system crash. Also, assume there's no inbound/outbound web traffic from 3-rd party vendors so we can't use MMS service for monitoring. The way I see it we would need to develop kind of stripped-down, very basic version of MMS to perform basic monitoring/recovery for a single-node instance.
I am just trying to assess feasibility of such solution. I understand the new journaling feature will probably go some way in addressing this as far as data loss is concerned(self-recovery on crash), but there may be other pitfalls that I am unaware of.
Does anyone use Mongo in a similar setting? Would you recommend on using it?
Hi, I would like to have more comments on that topic. I'm using MongoDB in our solution, and I'm pretty much happy with the solution (We have a high write rate, that would be impossible to cope with any RDBM). However we have problem with the huge files that are allocated in advance. local.x, journaling, etc, etc.. they are huge and they keep growing.
As partial solution we configured smallfiles=true and optSize (for replica) = 10 Mb and we are monitoring them. Any other tip/idea about "how to keep those extra files managable for devices where disk space does matter" ?
On Wednesday, October 3, 2012 5:16:25 PM UTC+2, Vlad wrote:
> Hi mongodb-user,
> I am currently evaluating feasibility of using MongoDB in our application. > Here's the basic outline of our use case.
> 1. My main feature of interest at this time is flexible schema/efficient > search(indexing). Our deployment model would be single-node, no > replication, no sharding. > Our transaction volume is expected to be moderate and expected collection > size average about 1 million items/per collection in likely less than 10 > collections. > High availability currently is less critical for us, but data durability > is important.
> 2. Our product offering is security appliance that runs in a headless, > unattended fashion. > Assume there will be no human intervention to perform monitoring or > execute manual recovery steps upon system crash. > Also, assume there's no inbound/outbound web traffic from 3-rd party > vendors so we can't use MMS service for monitoring. > The way I see it we would need to develop kind of stripped-down, very > basic version of MMS to perform basic monitoring/recovery for a single-node > instance.
> I am just trying to assess feasibility of such solution. > I understand the new journaling feature will probably go some way in > addressing this as far as data loss is concerned(self-recovery on crash), > but there may be other pitfalls that I am unaware of.
> Does anyone use Mongo in a similar setting? > Would you recommend on using it?
> Hi, I would like to have more comments on that topic. I'm using MongoDB in
> our solution, and I'm pretty much happy with the solution (We have a high
> write rate, that would be impossible to cope with any RDBM). However we
> have problem with the huge files that are allocated in advance. local.x,
> journaling, etc, etc.. they are huge and they keep growing.
> As partial solution we configured smallfiles=true and optSize (for
> replica) = 10 Mb and we are monitoring them. Any other tip/idea about "how
> to keep those extra files managable for devices where disk space does
> matter" ?
> thanks
> On Wednesday, October 3, 2012 5:16:25 PM UTC+2, Vlad wrote:
>> Hi mongodb-user,
>> I am currently evaluating feasibility of using MongoDB in our application.
>> Here's the basic outline of our use case.
>> 1. My main feature of interest at this time is flexible schema/efficient
>> search(indexing). Our deployment model would be single-node, no
>> replication, no sharding.
>> Our transaction volume is expected to be moderate and expected collection
>> size average about 1 million items/per collection in likely less than 10
>> collections.
>> High availability currently is less critical for us, but data durability
>> is important.
>> 2. Our product offering is security appliance that runs in a headless,
>> unattended fashion.
>> Assume there will be no human intervention to perform monitoring or
>> execute manual recovery steps upon system crash.
>> Also, assume there's no inbound/outbound web traffic from 3-rd party
>> vendors so we can't use MMS service for monitoring.
>> The way I see it we would need to develop kind of stripped-down, very
>> basic version of MMS to perform basic monitoring/recovery for a single-node
>> instance.
>> I am just trying to assess feasibility of such solution.
>> I understand the new journaling feature will probably go some way in
>> addressing this as far as data loss is concerned(self-recovery on crash),
>> but there may be other pitfalls that I am unaware of.
>> Does anyone use Mongo in a similar setting?
>> Would you recommend on using it?
>> Thanks
> --
> You received this message because you are subscribed to the Google
> Groups "mongodb-user" group.
> To post to this group, send email to mongodb-user@googlegroups.com
> To unsubscribe from this group, send email to
> mongodb-user+unsubscribe@googlegroups.com
> See also the IRC channel -- freenode.net#mongodb
> On 9 November 2012 09:00, Jose Silva <pelas...@gmail.com> wrote:
>> Hi, I would like to have more comments on that topic. I'm using MongoDB
>> in our solution, and I'm pretty much happy with the solution (We have a
>> high write rate, that would be impossible to cope with any RDBM). However
>> we have problem with the huge files that are allocated in advance.
>> local.x, journaling, etc, etc.. they are huge and they keep growing.
>> As partial solution we configured smallfiles=true and optSize (for
>> replica) = 10 Mb and we are monitoring them. Any other tip/idea about "how
>> to keep those extra files managable for devices where disk space does
>> matter" ?
>> thanks
>> On Wednesday, October 3, 2012 5:16:25 PM UTC+2, Vlad wrote:
>>> Hi mongodb-user,
>>> I am currently evaluating feasibility of using MongoDB in our
>>> application.
>>> Here's the basic outline of our use case.
>>> 1. My main feature of interest at this time is flexible schema/efficient
>>> search(indexing). Our deployment model would be single-node, no
>>> replication, no sharding.
>>> Our transaction volume is expected to be moderate and expected
>>> collection size average about 1 million items/per collection in likely less
>>> than 10 collections.
>>> High availability currently is less critical for us, but data durability
>>> is important.
>>> 2. Our product offering is security appliance that runs in a headless,
>>> unattended fashion.
>>> Assume there will be no human intervention to perform monitoring or
>>> execute manual recovery steps upon system crash.
>>> Also, assume there's no inbound/outbound web traffic from 3-rd party
>>> vendors so we can't use MMS service for monitoring.
>>> The way I see it we would need to develop kind of stripped-down, very
>>> basic version of MMS to perform basic monitoring/recovery for a single-node
>>> instance.
>>> I am just trying to assess feasibility of such solution.
>>> I understand the new journaling feature will probably go some way in
>>> addressing this as far as data loss is concerned(self-recovery on crash),
>>> but there may be other pitfalls that I am unaware of.
>>> Does anyone use Mongo in a similar setting?
>>> Would you recommend on using it?
>>> Thanks
>> --
>> You received this message because you are subscribed to the Google
>> Groups "mongodb-user" group.
>> To post to this group, send email to mongodb-user@googlegroups.com
>> To unsubscribe from this group, send email to
>> mongodb-user+unsubscribe@googlegroups.com
>> See also the IRC channel -- freenode.net#mongodb
>> On 9 November 2012 09:00, Jose Silva <pela...@gmail.com <javascript:>>wrote:
>>> Hi, I would like to have more comments on that topic. I'm using MongoDB >>> in our solution, and I'm pretty much happy with the solution (We have a >>> high write rate, that would be impossible to cope with any RDBM). However >>> we have problem with the huge files that are allocated in advance. >>> local.x, journaling, etc, etc.. they are huge and they keep growing.
>>> As partial solution we configured smallfiles=true and optSize (for >>> replica) = 10 Mb and we are monitoring them. Any other tip/idea about "how >>> to keep those extra files managable for devices where disk space does >>> matter" ?
>>> thanks
>>> On Wednesday, October 3, 2012 5:16:25 PM UTC+2, Vlad wrote:
>>>> Hi mongodb-user,
>>>> I am currently evaluating feasibility of using MongoDB in our >>>> application. >>>> Here's the basic outline of our use case.
>>>> 1. My main feature of interest at this time is flexible >>>> schema/efficient search(indexing). Our deployment model would be >>>> single-node, no replication, no sharding. >>>> Our transaction volume is expected to be moderate and expected >>>> collection size average about 1 million items/per collection in likely less >>>> than 10 collections. >>>> High availability currently is less critical for us, but data >>>> durability is important.
>>>> 2. Our product offering is security appliance that runs in a headless, >>>> unattended fashion. >>>> Assume there will be no human intervention to perform monitoring or >>>> execute manual recovery steps upon system crash. >>>> Also, assume there's no inbound/outbound web traffic from 3-rd party >>>> vendors so we can't use MMS service for monitoring. >>>> The way I see it we would need to develop kind of stripped-down, very >>>> basic version of MMS to perform basic monitoring/recovery for a single-node >>>> instance.
>>>> I am just trying to assess feasibility of such solution. >>>> I understand the new journaling feature will probably go some way in >>>> addressing this as far as data loss is concerned(self-recovery on crash), >>>> but there may be other pitfalls that I am unaware of.
>>>> Does anyone use Mongo in a similar setting? >>>> Would you recommend on using it?
>>>> Thanks
>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "mongodb-user" group. >>> To post to this group, send email to mongod...@googlegroups.com<javascript:> >>> To unsubscribe from this group, send email to >>> mongodb-user...@googlegroups.com <javascript:> >>> See also the IRC channel -- freenode.net#mongodb
