We are looking at a document db storage solution with fail over clustering, for some read/write intensive application.

We will be having an average of 40K concurrent writes per second written to the db (with peak can go up to 70,000 during) - and may have around almost similiar number of reads happening.

We also need a mechanism for the db to notify about the newly written records (some kind of trigger at db level).

What will be a good option in terms of a proper choice of document db and related capacity planning?

Updated

More details on the expectation.

  • On an average, we are expecting 40,000 (40K) Number of inserts (new documents) per second across 3-4 databases/document collections.
  • The peak may go up to 120,000 (120K) Inserts
  • The Inserts should be readable right away - almost realtime
  • Along with this, we expect around 5000 updates or deletes per second
  • Along with this, we also expect 500-600 concurrent queries accessing data. These queries and execution plans are somewhat known, though this might have to be updated, like say, once in a week or so.
  • The system should support failover clustering on the storage side
mongodb couchdb ravendb document-database nosql
Edit
Report