Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <blockquote> <p>By "loads" I mean ~5,000 queries per second.</p> </blockquote> <p>Ah that's not so much, even SQL can handle that. So you are already easily within the limits of what most modern DBs can handle. However they can only handle this with the right:</p> <ul> <li>Indexes</li> <li>Queries</li> <li>Server Hardware</li> <li>Splitting of large data (you might require a large amount of shards with relatively low data each, dependant here so I said "might")</li> </ul> <blockquote> <p>That would be ~100,000 objects to read per second.</p> </blockquote> <p>Now that's more of a high load scenario. Must you read these in such a fragmented manner? If so then (as I said) you may require to look into spreading the load across replicated shards.</p> <blockquote> <p>Storage is not something I would be worried about as the objects will be really tiny.</p> </blockquote> <p>Mongo is aggresive with disk allocation so even with small objects it will still pre-allocate a lot of space, this is something to bare in mind.</p> <blockquote> <p>So... $5424 per month.</p> </blockquote> <p>Oh yea the billing thrills of Amazon <code>:\</code>.</p> <blockquote> <p>I would consider other options but I am worried about maintenance issues, costs etc. I have never worked with such setups before so your advice would be really valuable.</p> </blockquote> <p>Now you hit the snag of it all. You can setup your own cluster but then you might end up paying that much in money and time (or way more) for the servers, people, admins and your own mantenance time. This is one reason why DynamoDB really shines here. For large setups who are looking to take the load and pain and stress of server management (trust me it is really painful, if your a Dev you might as well change your job title to server admin from now on) off of the company.</p> <p>Considering to setup this yourself you would need:</p> <ul> <li>A considerable amount of EC instances (dependant upon data and index size but I would say close to maybe 30?)</li> <li>A server admin (maybe 2, maybe freelance?)</li> </ul> <p>Both of which could set you back 100's of thousands of pounds a year, I would personally bet for the managed approach if it fits your needs and budget. When your need grows beyond what managed Amazon DB can give you then move to your infrastructure.</p> <h2>Edit</h2> <p>I should amend that the cost effectiveness was done with quite a few black holes for example:</p> <ul> <li>I am unsure of the amount of data you have</li> <li>I am unsure of writes</li> </ul> <p>Both of these contribute me to place a scenario of:</p> <ul> <li>Massive writes (about as much as your reading)</li> <li>Massive data (lots)</li> </ul>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload