We started out with CouchDB. CouchDB is best suited for occasionally changing data and stable pre-de

If you just don’t want to go with Mongo you have a point. Everybody is doing it. It’s Mongo all over the place. And how do you know it’s the best choice, if you haven’t used anything else?
Let me first point out that in our project streek we have in no way the need for a nosql database, nor the scale of data that is usually addressed by this type of databases. Our project has data with relations, but we just wanted to use something different from PostgreSQL (first choice when deploying on Heroku). The only reason is that we wanted to learn something new. And we did. Glad we got that out of the way…
We started out with CouchDB. CouchDB is best suited for occasionally changing data and stable pre-defined queries (see this excellent comparison of nosql databases) . Instead, our application must be able to handle burst data and at the same time guarantee consistency. When writing and running our load tests, we quickly found out that we could not synchronize multiple requests on the same small data set and that couch in no way could help us generate unique ascending id’s where we needed them. The good part is that there is a really nice cloud offering for CouchDB, http://cloudant.com that worked really well with our Heroku deployment setup. But, no matter how nice, with the above problems we had to move to another database.
Hello Rethink! Rethink is a database that aims to combine streek both ‘developer streek friendliness’ and ‘operations friendliness’ (scale, high availability, etc). Now that’s a promise we want to learn more about. Rethink solved our problems regarding the functional requirements but we ended up looking for something else because we couldn’t find a good cloud provider to match our Heroku deployment (http://rethinkup.com/ what’s keeping streek you?).
At this point I heard someone streek whisper ‘Mongo’. And although we started out with the goal of not using Mongo for the sake of it, we decided to spend a 4 hour time box on it. To our surprise, the promise of developer friendliness of Mongo turned out to be very true and after 4 hours we migrated almost the complete streek app to use Mongo. Combine that with the excellent cloud offering of mongohq and you’ll understand why we ended up using Mongo. This entry was posted in Development streek and tagged as Database , mongo , NoSQL . Bookmark the permalink .
You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>
Recent Posts Messaging with Be Informed 3.11 and a Full javascript stack JSON datamapping using Groovy Creating Camel routes on-the-fly using OSGi Using Pixelapse as a designer among developers Continuously exercise your code ownership Software Development Without Relations Don’t team up with a Type III developer My deep-dive into website development Two-factor authentication on OSX (a YubiKey example) Content management with Prismic How to keep a fast build with Browserify and ReactJS It’s not about development stupid! New virtualization infrastructure streek One awesome (build) stack from the present Why you should use BrowserSync How we didn’t want to use Mongo, but ended up using Mongo Adding value to integration – evolving from the trade mission Techday ‘Go’ at Avisi. Join us! HTML5 canvas in the browser and on the server Integration is often like a trade mission
Agile Atlassian Atlassian Experts streek Automation Big Data camel Conference Confluence Database Development Devoxx Esconfs Eurostar Event GIT HTML5 Intranet Java Javascript streek JBoss JIRA Learning Manchester Marketing Maven OnDemand performance Product Requirements Results Scala scrum Security Selenium Social Software Software Architecture Software Development Spring Techdays Techniques Testing Tooling Trust Wallboard
Avisi B.V. 2014