101–110 of 119 posts
Earlier quoted context omitted.
Really? Have you ever tried to search for specific content in structured documents on a filesystem?
I have, and found what I was looking for. What am I doing wrong?
Essentially you say something akin to "Death metal is just pulsating air-waves, like jazz, so what's the big difference?".
Earlier quoted context omitted.
For me the really irritating thing is the observation that when I want to enjoy flame wars about Mongo, I seem to see a lot of their 'try TokuMX' everywhere. Last time I checked they are on the 2.2 codebase, unless that recently changed. Mongo 2.4 was a significant upgrade, and assuming I'm correct above, I feel like the Tokutek team disregard that. I get that it's good marketing to suggest an alternative, but going…
Last time you checked was a while ago, it's 2.4 compatible now (except geo and full-text) and has been since TokuMX 1.3. We generally don't criticize indiscriminately. MongoDB has a lot of good sides and we embrace and extend those, and where it has faults we try to work around or replace them. Our core strength is fast, reliable, compressed storage and MVCC semantics, so obviously we talk about that a lot, but we al…
Earlier quoted context omitted.
Really? Have you ever tried to search for specific content in structured documents on a filesystem?
You are referring to using an index, correct? Because grep is absolutely, madly efficient for a doing a full search. The index portion of a file system are called files and directories. Several file names can refer to the same data. Those are called hard links. So with hard links, I can refer to a Foo by their related Bar. /foo/foo1 /foo/foo2 /foo/by_bar/bar1 /foo/by_bar/bar2 /foo/by_bar/bar3 /bar/bar1 /bar/bar2 /bar…
I'm not sure why you imply that a full search is incompatible with an index.
Perhaps you meant "full scan", that is reading everything while searching, instead of "full search" (searching everything). The first is not a prerequisite for the second.
In any case, grep is a very inefficient way of doing a full search. An index is so much faster it's not even funny.
>The index portion of a file system are called files and directories.
Those are just indexes for the names of the files and folders, and a few other select metadata. Nothing like a full-text search index, or even actual indexes on metadata.
(Some filesystems allow those too, e.g. in BeOS, but nowhere as comprehensive and flexible as using a dedicated tool for this, be it MongoDB or something else).
>Several file names can refer to the same data. Those are called hard links. So with hard links, I can refer to a Foo by their related Bar.
Sounds like a convoluted and inefficient way of building something somewhat like a "document database" with 1/10 the features (if that).
>I'm not a Mongo expert because no one could convince me otherwise to date, somebody correct me?
I'm far from a fan of Mongo, but you seem like you have already made up your mind, and nothing will change it.
Plus, if a filesystem is enough of a document database for you (with no cheating, e.g piling up tons of hacks and add-ons like external full-text scanning tools), then be all means, us one.
Earlier quoted context omitted.
if you are looking for a nosql dbms as a service which consumes json and supports SQL and search, you could try amisaserver
have you seen the pricing? it's insane
$700/year for enterprise-level solutions is generally regarded as suspiciously inexpensive.
Earlier quoted context omitted.
have you seen the pricing? it's insane
If $700/year is insane pricing for your needs, you're definitely not in their target market... $700/year for enterprise-level solutions is generally regarded as suspiciously inexpensive.
Earlier quoted context omitted.
Yes, and an important limitation stems from this as well. For a tool like Redis, it's fairly easy for me to accept the limitation that my data size can't exceed available RAM. But for an indexed document store with full-text query capabilities, it's a lot harder to for me to accept that limitation.
Are you implying that a performant Mongo DB must keep all data in RAM? That's not true. We've got almost 1TB in a Mongo DB, and we sure don't have that much RAM. You do have to be able to keep your indexes in RAM, but that's much less limiting.
So i've been trying to find an the ideal case for mongodb, because I have to teach a nosql database to some people I am mentoring. I'm leaning heavily towards couchdb though. http://daemon.co.za/2014/04/when-is-mongodb-the-right-tool
Be sure to check out RethinkDB as well, which is pretty much mongo with a MUCH nicer query interface and saner locking. http://rethinkdb.com/ http://rethinkdb.com/docs/comparison-tables/
Not saying MongoDB is bad (I've used Mongodb and like it), but much of their API-design is quirky/bad, locking is an issue and mmap feels weird too.
Earlier quoted context omitted.
IMO unless you desperately need one of the new features I would hold off a few weeks. With a release this big I'd expect there will be some bugs and wouldn't be surprised to see 2.6.1 shortly.
This is always best practice for anything important unless you find your life is dull and bereft of emergency.