MongoDB Is Cocoafish Best Friend
Cocoafish’s[1] story of going NoSQL started based on this analysis:
When designing our fundamental architecture we needed to find a database that could deal with millions of users across thousands of apps that will use Cocoafish. I knew that we would need replication, sharding, read slaves, etc. Using the default SQL solution (MySQL) was out of the question since the administrative model for these kind of scaling features is difficult. Plus I found anecdotal evidence that performance hits a wall once you get to some millions of rows in a table.
They chose MongoDB, even if at that time (2010), it didn’t really support sharding or read slaves. But they had another good reason for using it:
On top of that we wanted to handle flexible app data without predefining schemas or running database migrations from our Ruby on Rails stack. […] We’re constantly expanding our data models, and MongoDB makes it totally easy to do that.
This is just a good example of a scenario where a NoSQL database was used not for its scaling promises, but rather for the flexible data model.
-
Cocoafish is backend mobile application development made quick and easy. We’re a platform service that lets developers build top network features into mobile apps without writing any server code. ↩
Original title and link: MongoDB Is Cocoafish Best Friend (©myNoSQL)
via: http://blog.cocoafish.com/post/7992797174/mongodb-is-our-best-friend
