[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 738
  • Last Modified:

MongoDB question

When I want to sort by multiple keys on mongodb , I got some problem , And can I fix it ??

db.test.a.count()

78150

db.test.a.ensureIndex({a:1,b:1,c:1,d:1});

db.test.a.find().sort({a:1,b:1,c:1,d:1});

error: { "$err" : "too much data for sort() with no index. add an index or speci fy a smaller limit", "code" : 10128 }
0
wsyy
Asked:
wsyy
  • 2
1 Solution
 
tbsgadiCommented:
0
 
wsyyAuthor Commented:
Hi Gary, sorry for late response. Quite busy recently.

Could you please check the link? Can't access to it.
0
 
tbsgadiCommented:
Tuesday, February 15, 2011
Always index columns that you want to sort on in Mongo
I'm using Mongo as a non-relational database for a few projects. In general it's working out great. MySQL would work too but I like not having to explicitly create a database or run migrations. Plus I figure you can't really understand the strengths and weaknesses of a technology unless you build a real application with it.

I work in Ruby and use the MongoMapper and Mongoid Object Data Mappers to talk to Mongo.

One issue that I do not like is the requirement that you explicitly create an index for every column that you think you will want to sort on. If you don't then all the data gets loaded into memory for the sort and you get an error like this:


?12 [...]/gems/mongo-1.2.1/lib/mongo/cursor.rb:86:in `next_document': too much data for sort() with no index (Mongo::OperationFailure)


And if you want to sort on two columns then you need an index on the combination of the two.

You can add indexes at any point - it takes some action but it's not that big a deal. But it doesn't 'just work'... in MySQL it does - an index might give you better performance but it doesn't blow up without one.

You'll hear people claim that the NoSQL databases are schema-free, giving you a lot of flexibility. I don't really buy that argument - in most applications you want a clear schema.

Where I do see the benefit is that, with NoSQL databases, your schema resides your Model - not in the DB itself - and that is where it belongs. When you want to change the schema you just change the Model - no database migrations - very flexible.

But, with Mongo at least, if you have to define indexes ahead of time in order to sort even relatively small numbers of objects then that nullifies some of that benefit.


 
Posted by Robert Jones at 2:30 PM   Labels: ruby mongo mongoid mongomapper mysql
0

Featured Post

Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now