MongoDB 2.4 addresses search concerns
March 19, 2013 —
(Page 1 of 2)
Related Search Term(s): Big Data, MongoDB, NoSQL
NoSQL database MongoDB got a major update from 10gen, its creator, today. Version 2.4 of the database includes new tools to help with the scaling process, as well as better default settings that should help prevent data loss for users unfamiliar with the system.
Kelly Stirman, director of product marketing at 10gen, said that version 2.4 was built to address many of the concerns MongoDB users have expressed in the community. Specifically, he said that the community had long been asking for full text search to be embedded in the database.
“It's been one of the most frequently requested features since the launch of the project,” he said. “If you have a MongoDB application, in the past, you've needed to integrate with Solr, Lucene or ElasticSearch, or a commercial technology. It's no surprise a lot of developers just wanted this to be part of the database.”
Stirman said that the search capabilities added to MongoDB 2.4 are not a panacea. It does not have “everything you could ever need in search, but we think that for a lot of people, the feature will be good enough. There will still be users who have more sophisticated needs for search, and they will integrate with a separate search technology,” he said.
Version 2.4 also includes new tools designed to help administrators and developers better scale MongoDB. One of the sticking points for scaling MongoDB was around trying to determine which data should be stored in RAM and which should live on the disk.
“[MongoDB] didn't always know what your working set was,” said Stirman. “People would say, 'What's my working set?' There are ways to triangulate it. Now, we have a feature in 2.4 that helps you understand what the working set is. That will help with capacity planning.”
In addition to performance enhancements, new hash-space sharding capabilities, and the introduction of a new Enterprise edition, the big “gotcha” for new users has also been addressed, said Stirman.
That gotcha has been the database's default level of write concern. “Historically, we have supported different levels of write concern. If you want to write data for MongoDB, one end of the spectrum is 'I don't care if I lose this,' and the other end is 'Under no circumstances should this be lost.' Our drivers allowed the developer to specify the level of concern on write. The default for drivers was relatively low. We've changed the defaults in Mongo client,” said Stirman.