replica sets

2 results

Post+Beam's MongoDB-powered innovation factory

When your business is innovation, throttling creativity with rigid, upfront schema design is a recipe for frustration. It’s therefore not surprising that Post+Beam , an innovation and communications “factory,” turned to MongoDB to enable rapid development. Part startup incubator, part branding and communication agency, part development firm, Post+Beam takes ideas and turns them into products. Post+Beam’s first MongoDB-based product is Linea, a cross-platform photo browsing application that extends from web to mobile and enables users to create and share stories through photos, focusing on the photos and the collaboration around them, not photo storage. In talking with lead engineer Jeff Chao, he mentioned MongoDB’s dynamic schema as a primary reason for using the NoSQL database: The most important reason for using MongoDB from the start is rapid development. We wanted to spend just enough development time in spec’ing out a schema so we could get started on writing the application. We were then able to incrementally adjust the schema depending on various technical and non-technical requirements. Another reason for choosing MongoDB is because of its default data representation. We were able to build out an API to allow iOS clients to interact with our web service via JSON. This is particularly interesting given that Post+Beam’s development team has extensive relational database technology. According to Chao, MongoDB’s documentation and community support” made it easy to get up-to-speed. The initial set-up consists of a three-node replica set (for automatic fail-over), all running in one cluster on Amazon EC2. While the team continues to use Postgres for some transactional components of the Linea app, it needed MongoDB’s flexible data model to support its business model, which demands continuous iteration Which, of course, is how innovation happens. Chao noted that Post+Beam plans to expand its use of MongoDB, particularly for those applications that “require a relatively short delivery time combined with requirements that might not be fully matured at the time of the [client] request.” This sounds like most applications, most of the time, in most enterprises. Indeed, this is one of the primary reasons we see for MongoDB’s mass adoption. As our friends at MongoLab say , “It’s a data model thing.” Tagged with: data model, Post+Beam, case study, Linea, innovation, flexibility, replica sets, ease of use

February 19, 2013

MongoDB at Turntable.fm

Online music distribution has continually been a hotbed of innovation. But last year, when giants like Spotify were making their entry into the US market, a small startup in New York City took over the desktop music scene. Turntable.fm , a listening party for the web, powered by MongoDB, was an overnight success, and captured the screens and headsets of the New York City tech scene. A year later, we sat down with Billy Chasen to discuss his team’s decision to use MongoDB in their stack and get some advice on best practices for MongoDB. What is Turntable.fm? Turntable is a way to listen to music with other people online, at the same time. It tries to recreate the idea of hanging out together and taking turns playing music, except online. Can you describe your technology stack? Our backend uses mongodb, memcache, along with python and python frameworks, like tornado and cherrypy . Our frontend is pretty much entirely javascript. How are you using MongoDB at Turntable.fm? Aside from holding all important information (such as user data and room names), we use mongo to also handle the current room state for all our rooms and users online. Turntable.fm was an overnight success. What have you learned about MongoDB from growing so rapidly? Mongo can take a lot of abuse and allowed us to move fast. The trick was optimizing our inefficient queries and other operations while we were quickly growing. At the New York MongoDB User Group last summer, you talked about some MongoDB “gotchas” that you experienced. What changes have you made (if any!) since then to address some of the issues you encountered? All of those mongo gotchas were basically things we had to find and then fix. The gotchas are now of larger scale (write lock issues, scaling with replica sets, etc…) What advice do you have for startups just getting started with MongoDB? -Try to stay on top of what queries your actually making and what indexes you will need. If you’re aware of that from the beginning, it’ll save some headaches later on. But don’t try to scale everything from day one. The first step is making sure people like your product. -Just make sure the indexes you are making are being properly used (sometimes you may even have to send mongo hints if you have several indexes). Using explain() and verifying what you think is happening is actually happening. -Make sure you understand how composite indexes and how to properly create them based on your data. -Monitor your mongo server with something like munin and/or nagios to make sure the cpu isn’t spiking (a clear indicator that you may be missing an index) Tagged with: turntable.fm, startup, music, replica sets, queries, tornado, cherrypy, MongoDB, Mongo, NoSQL, Polyglot persistence, 10gen

May 30, 2012