Log file Viewer

[00:09:41] <eryc> hi

[00:11:29] <eryc> perhaps i will come back early next week :)

[00:12:17] <eryc> i had to patch fts_matcher.cpp to use an included strcasestr() on solaris 10

[00:13:30] <groundup> Is there a tutorial around for putting the MaxMind GeoIP database in MongoDB? I am using PHP, so if there is one using PHP, that would be even better

[00:14:10] <Derick> groundup: I doubt it... but it's surely not that difficult to import their cvs file into MongoDB?

[00:14:28] <Derick> eryc: best to email the mongo-dev list with that

[00:14:40] <eryc> ok np, thanks

[00:15:35] <eryc> i was mostly curious how the precompiled sunos package was compiled without strcasestr.. :)

[00:15:36] <groundup> Derick: doing a lot of searching has resulted in learning that there are a lot of issues with performance because it uses a LT and GT range query.

[00:16:21] <groundup> In SQL terms, it uses "$ip BETWEEN lower AND upper" which Mongo seems to have issues with. I am *very* new to Mongo so this is news to me

[00:16:21] <eryc> i'm wondering if its included in a newer gcclib

[00:16:39] <Derick> groundup: that should work fine with mongodb... it can use an index for that

[00:17:21] <Derick> that, being, range queries

[00:21:19] <eryc> some discussion on geoip and that issue here: http://stackoverflow.com/questions/13057387/how-to-optimize-mongodb-query-with-both-gt-and-lte

[00:21:56] <eryc> commenters say mongo doesn't do double range queries well

[00:22:03] <groundup> Yeah, that is one of the things I was talking about.

[00:23:01] <groundup> I might keep a MySQL db around to do this

[00:23:16] <eryc> the OP seemed to be happy with the solution he found

[00:23:28] <groundup> Removing all indices?

[00:24:06] <Derick> ah, like that. hm

[02:25:47] <Goopyo> I keep adding a replica set from a single primary and the one I add becomes primary and the existing primary becomes a secondary. How can I prevent this?

[02:30:38] <leifw> Goopyo: set their priorities

[02:31:57] <Goopyo> leifw: anything below 1?

[02:32:31] <leifw> I think if you set the new one to have priority 0 that prevents it from ever becoming a primary

[02:32:49] <Goopyo> Well I want to to become primary in downtime

[02:32:55] <Goopyo> just not as soon as I add it

[02:48:30] <leifw> Goopyo: not sure then, sorry

[04:53:07] <angelazou> hi I'm having some problem starting mongod

[04:53:30] <angelazou> I tried using sudo and --dbpath

[04:53:57] <angelazou> I got unclean shutdown detected

[04:54:16] <angelazou> then I try mongod --shutdown and tried again and I still get the same message

[05:34:07] <heath> a general question, can someone give me an example of this? https://en.wikipedia.org/wiki/Data_access_layer

[05:35:20] <heath> i was looking at some job description, and it stated "your applications have a data layer because because you don't care for ORMs"

[05:35:35] <heath> would someone explain this?

[05:52:41] <drjeats> heath: i think the implication from that description is that you roll your own mongoengine/ActiveRecord because you are interested in being in full control of your application's entire architecture

[06:03:50] <heath> thanks drjeats

[06:06:01] <drjeats> np

[12:40:22] <marw> hello. how would you compile a query for searching documents that have categories? i.e if doc is {... 'category':['cat1', 'cat2', 'cat3']}?

[12:41:02] <marw> actually. that's category1, subcategory1, etc

[16:29:48] <atealtha_> hi, if I have an index {a:1, b:1, c:1, d:1}, is it possible to find({a:..., b:...}).sort({d:1}) where "c" is "all values for "c"?

[16:30:18] <kali> not efficiently, and not at all if the collection is big

[16:31:09] <atealtha_> kali: so it sounds like it won't use the index then?

[16:31:55] <atealtha_> I am thinking of storing all unique values of c in another collection and doing two queries so I explicitly provide values for c

[16:32:12] <kali> atealtha_: same.

[16:32:52] <kali> atealtha_: you need the index btree to be physically in the order you need to retrieve the docs

[16:33:05] <kali> add {a:1, b:1, d:1} as an index

[16:33:22] <atealtha_> d will be the only ordering that matters since it's a timestamp

[16:33:43] <heewa> I just tried that with explain and it looks like it uses the index. Maybe? Did I do it right? http://pastebin.com/NfiuHsBZ

[16:34:11] <kali> heewa: to find the right docs, yes. but "scanAndOrder" : true

[16:35:05] <kali> heewa: and the "$lt" on "b" is even more disruptive to the index order

[16:35:15] <atealtha_> kali: more often than not c will be used in the find(), sorry I should have mentioned that

[16:35:41] <heewa> Ah, I never knew to look for that. Good to know. I'm guessing that means it has to read all the entries first before starting to return them, because it can't determine order from the index? If it could use the index, the only difference is that it could scan them in order and start returning them sooner?

[16:36:07] <kali> atealtha_: {a:1, b:1, d:1, c:1} could work quite well too.

[16:37:00] <kali> heewa: yes. also, mongo will cowardly refuse to sort more than about 1k docs

[16:37:55] <heewa> Oh, that's small. Afraid to mess up its cache? Or trying to avoid writing to disk, maybe cuz it stores the results in a mmaped file?

[16:38:57] <kali> heewa: it's its way to say it wants one more index

[16:40:48] <atealtha_> looking into the a,b,d,c ordering, maybe I can work that

[16:44:38] <atealtha_> so if d is the timestamp in index {a,b,d,c}, I should be able to find({a:..., b:...}).sort({d:1}) and it assumes all c

[16:45:35] <kali> atealtha_: yes. and for find({a:..., b:..., c:... }).sort({d:1}) it will just scan the index skipping the lines with "wrong" c

[16:45:57] <kali> atealtha_: all this assumes a: and b: are strict equality criteria, of course

[16:46:40] <atealtha_> d is the only sort, everything else is equality

[16:51:24] <atealtha_> kali: I think the a,b,d,c index is the right choice for me, thanks for the help

[20:02:04] <lrocksmashtime> Hey guys, I'm currently running a Rails app using mongodb. everything is on one virtual machine hosted by Rackspace with 512 ram. I'm expecting a flood of traffic in the coming week of approximately 10-20k hits a day. I'm looking to beef up my system but am not 100% sure what is an adequate setup for those types of numbers. Any help is appreciated

[20:02:54] <lrocksmashtime> i'm reading up on sharded clusters, upgrading to mongo 2.4, replica sets

[20:02:58] <lrocksmashtime> its a lot of stuff

[20:13:57] <danderso1> How much should my mongo-using application go out of its way to avoid no-op updates?

[20:15:12] <danderso1> That is, I'm making a bunch of $set updates, most of which will end up not changing the document (syncing from an external source). Should I do read-then-update to avoid needless writes, or just blindly write my updates?

[20:15:57] <danderso1> intuitively, I'm thinking a read would end up being cheaper, so if I can use it to avoid needless writes, I should come out ahead... But I don't know enough of mongo's internals and performance caracteristics to be sure.

[20:59:25] <a__remie> if I have an array of unique ObjectIDs and want to find them all with a find({_id: $in: thingIdsArray}), what about IDs that have been deleted and no longer exist?

[22:57:47] <atealtha_> I'm testing out my indexes in queries. can someone explain why it's using the index in one and not the other here when only strings in the query array changed? http://pastebin.com/CSDHytqH

[22:58:34] <atealtha_> {$in:['foo', 'bar']} uses the index while {$in:['Draft', 'Published']} does not... I don't get it