Skip to main content
Capacity Planning
Source Link
gWaldo
  • 111
  • 5

I personally prefer MongoDB for it's ease of administration, scalability, general ease-of-use. Also, unless I actually need a RDBMS, I'm going to use a no-SQL.

With that said, choose the DB that makes the most sense for your application. If you need Transactions or can't design your app without Joins (or it just plain makes more sense with them) then use a RDBMS (MySQL, PostGres, etc.)

While I personally prefer MongoDB, the idea that MySQL doesn't scale orcan't handle a high rate of transactions is purely false. The Facebook Engineering team (and the MySQL team within it) goes into great detail with it. Also check out the Etsy Ops team blog; they love MySQL as well.

Finally, I wouldn't use MongoDB for a MySQL cache; use Memcached for that.

Redis is also an in-RAM key-value store that is good for handling certain use-cases. There are some blog entries on blog.agoragames.com that describe some use-cases.

You should also check out CouchDB if you're thinking No-SQL. Just be aware that it requires regular maintbe aware that it requires regular maint to keep it's disk-utilization down. (It trades speed and convenience for Disk util...)

Finally, capacity planning is not easy to predict. You need to test in as realistic conditions as possible and be prepared to remediate based on what you see. Sadly "Computer Science" is as much Art as Science.

I personally prefer MongoDB for it's ease of administration, scalability, general ease-of-use. Also, unless I actually need a RDBMS, I'm going to use a no-SQL.

With that said, choose the DB that makes the most sense for your application. If you need Transactions or can't design your app without Joins (or it just plain makes more sense with them) then use a RDBMS (MySQL, PostGres, etc.)

While I personally prefer MongoDB, the idea that MySQL doesn't scale orcan't handle a high rate of transactions is purely false. The Facebook Engineering team (and the MySQL team within it) goes into great detail with it. Also check out the Etsy Ops team blog; they love MySQL as well.

Finally, I wouldn't use MongoDB for a MySQL cache; use Memcached for that.

Redis is also an in-RAM key-value store that is good for handling certain use-cases.

You should also check out CouchDB if you're thinking No-SQL. Just be aware that it requires regular maint to keep it's disk-utilization down. (It trades speed and convenience for Disk util...)

I personally prefer MongoDB for it's ease of administration, scalability, general ease-of-use. Also, unless I actually need a RDBMS, I'm going to use a no-SQL.

With that said, choose the DB that makes the most sense for your application. If you need Transactions or can't design your app without Joins (or it just plain makes more sense with them) then use a RDBMS (MySQL, PostGres, etc.)

While I personally prefer MongoDB, the idea that MySQL doesn't scale orcan't handle a high rate of transactions is purely false. The Facebook Engineering team (and the MySQL team within it) goes into great detail with it. Also check out the Etsy Ops team blog; they love MySQL as well.

Finally, I wouldn't use MongoDB for a MySQL cache; use Memcached for that.

Redis is also an in-RAM key-value store that is good for handling certain use-cases. There are some blog entries on blog.agoragames.com that describe some use-cases.

You should also check out CouchDB if you're thinking No-SQL. Just be aware that it requires regular maint to keep it's disk-utilization down. (It trades speed and convenience for Disk util...)

Finally, capacity planning is not easy to predict. You need to test in as realistic conditions as possible and be prepared to remediate based on what you see. Sadly "Computer Science" is as much Art as Science.

Source Link
gWaldo
  • 111
  • 5

I personally prefer MongoDB for it's ease of administration, scalability, general ease-of-use. Also, unless I actually need a RDBMS, I'm going to use a no-SQL.

With that said, choose the DB that makes the most sense for your application. If you need Transactions or can't design your app without Joins (or it just plain makes more sense with them) then use a RDBMS (MySQL, PostGres, etc.)

While I personally prefer MongoDB, the idea that MySQL doesn't scale orcan't handle a high rate of transactions is purely false. The Facebook Engineering team (and the MySQL team within it) goes into great detail with it. Also check out the Etsy Ops team blog; they love MySQL as well.

Finally, I wouldn't use MongoDB for a MySQL cache; use Memcached for that.

Redis is also an in-RAM key-value store that is good for handling certain use-cases.

You should also check out CouchDB if you're thinking No-SQL. Just be aware that it requires regular maint to keep it's disk-utilization down. (It trades speed and convenience for Disk util...)