2

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?

Community
  • 1
  • 1
Justin Elkow
  • 2,833
  • 6
  • 28
  • 60
  • 1
    2) transactions aren't supported on either DB you've selected. Windows Azure SQL database for example supports non-distributed transactions. – WiredPrairie Jul 19 '13 at 11:14

2 Answers2

2

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.

Will Holley
  • 1,745
  • 10
  • 11
1

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.

Kim Stebel
  • 41,826
  • 12
  • 125
  • 142
  • Because MongoDB has a master-slave setup, then if the write succeeds, it will be immediately readable, so transactions like what's described in [2] will work in Mongo but might be wonky in CouchDB / Cloudant because of eventual consistency. AKA Mongo is strongly consistent: http://stackoverflow.com/questions/11292215/where-does-mongodb-stand-in-the-cap-theorem That said, master-slave setups scale poorly, and Mongo's write lock will stall reads and writes until a write succeeds. Other concerns to ponder. – garbados Jul 19 '13 at 20:20