Edit Question - KnowledgeHub

Title Body

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

Tags (comma-separated) Cancel