I see the "32-bit vs. 64-bit" issue appear in many rants about MongoDB. There are two types of people that fall off the 2GB cliff.
a) People who say "what just happened... oh, I get it... 32-bits, memmapped files... I'll switch to 64-bit"
b) People who say "WTF.. #MongoHate.. going to blog about how @#$#%! a DB this is"
Some people understand the tools they work with. Some people know just barely enough to throw things together and don't tolerate it when something doesn't work out of the box. Worst of all, this second group tends to be very vocal on the interwebs.
I'd almost like to see 10gen not publish the 32-bit package at all. Source is still there. If you want 32-bit, cool, compile it. But forcing the user to compile the 32-bit version assures at least a minimum bound of technical proficiency (an "I understand what I'm doing, why it's not the default and what the limitations are").
It's interesting, because from my observation a lot of the crowd who popularised systems like mongo were those people who weren't willing to think* . Learning the relational data model + tooling was too complicated. Now Mongo has a big ol' list of caveats you ought to understand before you can start chucking data into it too.
I'm a total RDBMS nerd, and it's amazing to me how few people truly care about their data storage. They just want it to work - and, I suppose, it's hard to blame them for that.
*Not that I mean to say that this is the only reason to use a NoSQL DB - it doesn't seem an uncommon one, though.
It seems to be a pretty common senario; people thinking X new technology that Y large site used will solve all of their problems magically. Comparing MongoDB to others; it's similar with Redis and from experience less so with Cassandra (probably the steeper barrier to entry) / Riak (lack of commonality with a standard DB is way more obvious) / Hbase, etc...
I have to admit that a lot of the joy I get from using MongoDB is during dev.
While you still have to think about your schema, it does mean that you're not constantly writing and removing migrations (rails), while an application is still evolving.
In Symfony2 (php) migrations are created by comparing the new schema with the old one. Is that not the case for Rails? What do you mean 'constantly writing migrations'?
Rails does not specify the mapping of models to database schema, so it requires specification of migrations instead to document changes to the database that go along with any code changes. So migrations are explicit commands (in a pretty simple dsl) to add columns etc. spread out over many files as the application evolves. This means each schema change requires adding a migration file with those changes in it, rather than modifying a master schema or mapping. There is a schema.rb file but it is created/modified automatically.
There are trade-offs to each approach but it is probably one of the areas that Rails could still improve by looking at other ORMs - I'd prefer to see the schema specified along with constraints etc for each field at the top of each model to make it explicit and self-documenting, and perhaps doing away with migrations altogether.
Comments
I see the "32-bit vs. 64-bit" issue appear in many rants about MongoDB. There are two types of people that fall off the 2GB cliff. a) People who say "what just happened... oh, I get it... 32-bits, memmapped files... I'll switch to 64-bit" b) People who say "WTF.. #MongoHate.. going to blog about how @#$#%! a DB this is"
Some people understand the tools they work with. Some people know just barely enough to throw things together and don't tolerate it when something doesn't work out of the box. Worst of all, this second group tends to be very vocal on the interwebs.
I'd almost like to see 10gen not publish the 32-bit package at all. Source is still there. If you want 32-bit, cool, compile it. But forcing the user to compile the 32-bit version assures at least a minimum bound of technical proficiency (an "I understand what I'm doing, why it's not the default and what the limitations are").
It's interesting, because from my observation a lot of the crowd who popularised systems like mongo were those people who weren't willing to think* . Learning the relational data model + tooling was too complicated. Now Mongo has a big ol' list of caveats you ought to understand before you can start chucking data into it too.
I'm a total RDBMS nerd, and it's amazing to me how few people truly care about their data storage. They just want it to work - and, I suppose, it's hard to blame them for that.
*Not that I mean to say that this is the only reason to use a NoSQL DB - it doesn't seem an uncommon one, though.
It seems to be a pretty common senario; people thinking X new technology that Y large site used will solve all of their problems magically. Comparing MongoDB to others; it's similar with Redis and from experience less so with Cassandra (probably the steeper barrier to entry) / Riak (lack of commonality with a standard DB is way more obvious) / Hbase, etc...
I have to admit that a lot of the joy I get from using MongoDB is during dev.
While you still have to think about your schema, it does mean that you're not constantly writing and removing migrations (rails), while an application is still evolving.
In Symfony2 (php) migrations are created by comparing the new schema with the old one. Is that not the case for Rails? What do you mean 'constantly writing migrations'?
Rails does not specify the mapping of models to database schema, so it requires specification of migrations instead to document changes to the database that go along with any code changes. So migrations are explicit commands (in a pretty simple dsl) to add columns etc. spread out over many files as the application evolves. This means each schema change requires adding a migration file with those changes in it, rather than modifying a master schema or mapping. There is a schema.rb file but it is created/modified automatically.
There are trade-offs to each approach but it is probably one of the areas that Rails could still improve by looking at other ORMs - I'd prefer to see the schema specified along with constraints etc for each field at the top of each model to make it explicit and self-documenting, and perhaps doing away with migrations altogether.