CODEWITHSUNDEEP
mongodbcouchdbcloudantnosql
Justin Elkow
Justin Elkow

Reputation: 2943

App Architecture - CouchDB and MongoDB

I am developing an app with two types of data:

1) User profile - Username, Email, UserID, Access Tokens, SessionIDs, AvatarUrl, etc. For each user this data will be about 20kB and for an active user the data will be read 100 times/day and written to 5 times/day. I am thinking of using ObjectRocket (MongoDB) or Cloudant (CouchDB with Clustering) --- I like the extreme fault tolerance (master/master replication, crash only design, and Cloudant's multi-geo redundancy) of Cloudant, but I am concerned that this many document revisions will run up disk space really fast and overall won't perform as well as MongoDB. I am leaning MongoDB. Any suggestions for this data type?

2) User to user transactions - UserA sends UserB 8 points --- check UserA's point balance, if >8, debit UserA and credit UserB. Each transaction will be about 2kB and will likely never be updated nor deleted (accountants don't use erasers). For this, I am thinking of using CouchDB (Cloudant) with Map/Reduce views, where the views will keep track of User balances. This data is of course extremely important to the integrity of the app and I think Couch will allow me to sleep better at night (especially with master/master replication, crash only design, and Cloudant's multi-geo redundancy). Any other suggestions for this data type?

Overall, I would like to use one DB type for simplicity, BUT it seems that sometimes to build a house, you need a hammer and a screwdriver. Does using Mongo (ObjectRocket) for data type #1 and Couch (Cloudant) for data type #2 make good sense?

Upvotes: 2

Views: 644

Answers (2)

Will Holley
Will Holley

Reputation: 1765

1) On Cloudant you don't need to worry about the disk space from previous edits - we automatically trigger compaction to clean up old, non-conflicted revisions in the background.

2) It's possible to model this in CouchDB / Cloudant by creating a new document for each credit or debit and using a map-reduce view to generate the account balanace. There is a fully worked example of this described in the CouchDB Definitive Guide. Your application logic would be along the lines of:

  1. debit user A
  2. assert user A has sufficient credits (e.g. still has a positive balance after the debit)
  3. credit user B

If 2 or 3 fail, credit user A and notify appropriately.

Upvotes: 2

Kim Stebel
Kim Stebel

Reputation: 42047

1) You won't use much disk space in this scenario, because old revisions get deleted regularly unless there is a conflict, which seems unlikely in this case.

2) This is something where you'd need transactions and CouchDB's or Cloudant's eventual consistency is not a good fit. I'm not sure whether MongoDB provides what you need either. The safest bet here is a relational database.

Upvotes: 1

Related Questions