Home/ Questions/Q 6615695
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-25T20:29:40+00:00

I have been reading and learning about NoSQL and MongoDB, CouchDB, etc, for the

  • 0

I have been reading and learning about NoSQL and MongoDB, CouchDB, etc, for the last two days, but I still can’t tell if this is the right kind of storage for me.

What worries me is the eventual consistency thing. Does that type of consistency only kick in when using clusters? (I’m hosting my sites in a single dedicated server, so I don’t know if I can benefit from NoSQL) For which kind of applications is OK to have eventual consistency (instead of ACID), and for which ones it isn’t? Can you give me some examples? What’s the worst thing that can happen in an application for which is OK to have eventual consistency?

Another thing that I read is that MongoDB keeps a lot of things in memory. In the docs it says something about 32-bit systems having a 2gb limit of data. Is that because of the ram limitation for 32-bit systems?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team
    • I have been reading and learning about NoSQL and MongoDB, CouchDB, etc, for the last two days, but I still can’t tell if this is the right kind of storage for me.

    NoSQL databases solve a set of problems, that are hard(er) to solve with traditional RDMS. NoSQL can be the right storage for you if any of your problems are in that set.

    • Does eventual consistency only kick in when using clusters?

    Eventual consistency “kicks in” when you might read back different/previous version of data from the one that was just persisted. For example:

    You persist the same piece of data into MORE THAN ONE location, let’s say A and B. Depending on the configuration, a persist operation may return after only persisting to A ( and not to B just yet ). Right after that you read that data from B, which is not yet there. Eventually it will be there, but unfortunately not when you read it back

    • For which kind of applications it is OK to have eventual consistency (instead of ACID), and for which ones it isn’t?

    NOT OK => You have a family bank account which has a $100 available. Now you and your spouse try to buy something at the same time (at different stores) for $100. If the bank had this implemented with “eventual consistency” model, over more than one node for example, your spouse could have spent $100 a couple of milliseconds after you already spent all of it. Would not be exactly a good day for the bank.

    OK => You have 10000 followers on Twitter. You tweeted “Hey who wants to do some hacking tonight?”. 100% consistency would mean that ALL those 10000 would receive your invitation at the same time. But nothing bad would really happen, if John saw your tweet 2 seconds after Mary did.

    • What’s the worst thing that can happen in an application for which is OK to have eventual consistency?

    A huge latency between e.g. when node A gets the data, and node B gets the same data [they are in sync]. If NoSQL solution is any solid, that would be the worse thing that can happen.

    • Another thing that I read is that MongoDB keeps a lot of things in memory. In the docs it says something about 32-bit systems having a 2gb limit of data. Is that because of the ram limitation for 32-bit systems?

    from MongoDB docs:

    “MongoDB is a server process that runs on Linux, Windows and OS X. It can be run both as a 32 or 64-bit application. We recommend running in 64-bit mode, since Mongo is limited to a total data size of about 2GB for all databases in 32-bit mode.“

    • 0