Hacker News Reader

Comment by mtkd | Hacker News Reader

I do encourage any SQL user, who hasn't already tried MongoDB, to fire it up and try it themselves. Mongoid in Ruby is fairly fast to get started.

I've been using SQL since early 90s. For web apps and large collections I've started using MongoDB more recently. It's one of the most exciting technologies I've used in a long time.

It takes a while to stop thinking SQL, but once you pass that it's really very primitive (in a good way) - and frictionless for development. It really fits what I want to do with web apps in particular.

So far I've not needed to scale it, but I've less apprehension about that than I used to have about scaling SQL back in the day - the large denormalised tables I used to build from SQL for performance are now the default.

SQL still has a place and MongoDB is no replacement for complex models, but give it a try before buying that you can do it all with Postgres tweaks.

View on HN

Experimenting with new technologies is encouraged, especially since cross-pollination of ideas happen this way.

However I would actually advise developers to stop and think if they really need MongoDB or the latest fad, because their current relational database, such as PostgreSQL, does a mighty fine job for most of their needs.

Why? Because I have never seen angry opinions about PostgreSQL losing people's data. Or about how the modeling tools and architecture exposed by PostgreSQL are insufficient for certain problems ... not until you're operating at Google's scale, and MongoDB won't save you there ;)

     give it a try before buying that you can do it all 
     with Postgres tweaks

My main problem with most NoSQL solutions is that I have to tweak the problems I have to fit the solution, instead of the other way around. Technologies that can be tweaked simply rock.

I guess if only I "woke up" I would realise that PostgreSQL is the answer to all my problems. Guess what. PostgreSQL is just another SQL database. It's definitely one of the best ones but it still stuffers from all the same issues, limitations and frustrations. Many of which stem not from the database itself but from the relational modelling and tools to support it.

I use Java + MongoDB and life is significantly better now that I don't have to worry about the domain model so much. I can have lists, maps etc and can add classes or make changes seamlessly. It's worth the tradeoffs for me.

> Guess what. PostgreSQL is just another SQL database.

Uh... hstore says "I'm not quite sure what the bloody hell you're talking about". So does ltree.

Ahem, lists and maps seem a very easy thing to do in SQL. Where you get to the limits of the relational model is when three structure diversity is out of your hands, for instance a big bunch of parametrized messages.

Lists/Maps require extra tables which means more scripts, more migrations, more backups, more worry.

With MongoDB all I have to do is add Map<String,String> myMap to a Java class and that's it.

Actually, Postgres has had an Array data type since at least v8.0. http://www.postgresql.org/docs/8.0/static/arrays.html

But yes, you're right that maps require a join table.

> But yes, you're right that maps require a join table.

Not in postgres: http://www.postgresql.org/docs/9.1/static/hstore.html

I wouldn't call it just another SQL database. The extensible type system is actually really cool and you can do a lot with it, and the same goes for Listen/Notify. It's actually an application development platform in a box.

But I guess here's the flip side. PostgreSQL is another relational database and and that means fundamentally it operates on sets of tuples. For anything where set operations are helpful, the relational model brings something that no other models bring to the table. I doubt I will ever see a viable ERP suite written on a NoSQL system.

OTOH, there are plenty of areas where set operations are not that big of a deal. In this area, a networked, mostly reliable, multi-master replicated store of application state data is a really really cool thing. For example, imagine MongoDB as a backplane for an LDAP forest, replacing local BDB storage for something like OpenLDAP. The source data may be in a more mature data store somewhere and fed into MongoDB so if it gets lost it isn't the end of the world (just possibly some temporary business hicups). Same with, say, Root DNS root servers.

> My main problem with most NoSQL solutions is that I have to tweak the problems I have to fit the solution, instead of the other way around. Technologies that can be tweaked simply rock.

Well, I would disagree. While it's great that sql databases let you do lots of joins, I would lose imagination of my query complexity very fast (also, you can't review all sql-queries stopping people from doing joins and "where tablename.status=active" in every joined table). While MongoDB would restrict you from that, but gives you "documents". I'd say it's a lot of power of complexity-clarity (having no joins, but power-enough documents).

p.s.: and yes, I agree with you that developers are ok with postgres on most of cases. more of that, it's better to have transactions and other stuff until it's performance-urgent to disable it).

> However I would actually advise developers to stop and think if they really need MongoDB or the latest fad, because their current relational database, such as PostgreSQL, does a mighty fine job for most of their needs.

Every time I've had to use an ORM, it always became a headache sooner or later. It got to the point where I stopped even trying to perform an automatic mapping; I reverted back to using explicit SQL in my code and avoided the "abstraction" altogether.

With a document store like MongoDB, though, the mapping between object and document is almost seamless. It's actually really quite comfortable.

Can you give an example? I don't generally have these problems and would like to see if it's my way of thinking or if you're working with vastly different data to me.

Since the relational model is very set-oriented, it has always had a particularly hard time dealing with ordered lists. But that's really a minor thing, and is actually something an ORM can do well to abstract.

My real headache with ORM has always been to get it to perform efficiently. For example, say I want to iterate through the GPA's of all the students. To do so, the ORM usually pulls in the full object model for each student - multiplying the cost of the desired operation by 10x or 100x. Now, each ORM tool usually has some tweaky knob or special declaration you can use to have it limit the fields queried, but by the time you figure out the right incantation you may as well have written the SQL yourself.

But wait! The ORM tool often saves you from this sort of overhead by caching the object model in memory. Alas, therein lies my biggest headache with ORM. "There are only two hard things in Computer Science: cache invalidation, naming things, and off-by-one errors."

I should acknowledge that these issues apply just as much to a document store as to a relational database. However, you tend to interact with a document store differently, since there is no need for a mapping abstraction. You often just use the database primitives provided, instead of going through a 3rd party. It's akin to manually using SQL in your code, where the database naturally knows what you're asking for.

I've used ORM tools such as the one in Django, Active::Record and DBIx::Class.

I do not have the issues you mentioned ... I always remember the API calls I need to make and performance has not been an issue (granted, I'm fairly familiar with all issues that can come up, so I know when or where to optimize in general).

    the ORM usually pulls in the full object model for each student

Here's how to do it in Django (and note this is off the top of my head):

    for row in Student.objects.values_list("gpa"):
        print row[0]

You're really talking about shitty ORMs or APIs you haven't had the patience to become familiar with.

    by the time you figure out the right
    incantation you may as well have written the 
    SQL yourself

That's not true. On complex filtering, you often want to add or subtract filters based on certain conditions. With plain SQL you end up doing really ugly string concatenations, whereas with a good ORM the queries are composable.

> http://www.postgresql.org/docs/9.1/static/hstore.html

A clearer version would probably be:

    for student in Student.objects.only('gpa'):
        print student.gpa

I agree: Mongoid is great.

I haven't done this in a few years, but Datamapper had the nice capability to map a singe model classes to multiple backends (e.g., use PostgreSQL for some attributes, MongoDB for others).

PostgreSQL and MongoDB cover most of my data store requirements and are a pleasure to use.

I use datamapper pretty extensively to join mysql tables with mongodb collections, but I've always used associations between several models to do this. Do you have any links talking about this capability?

> SQL still has a place and MongoDB is no replacement Let's flip this: NoSQL is finding it's place in the database ecosystem.

SQL is the name of a database query language, NoSQL is a term that identifies a set of new, ostensibly non-relational, data storage engines that so implement an SQL parser despite SQL being the Standard Query Language, with twenty years of history behind it.

My opinion - They decided to call it NoSQL, not because SQL requires a relation database, but because writing a smart query optimizer is hard task. Much harder than writing the storage engine itself.

I'd much rather access data from Mongo, Riak, Redis, and Couch using the SELECT, INSERT, UPDATE and DELETE statements that I have known since 1988, instead of having to learn four new database APIs.

"I'd much rather access data from Mongo, Riak, Redis, and Couch using the SELECT, INSERT, UPDATE and DELETE statements that I have known since 1988, instead of having to learn four new database APIs."

Doesn't work because those are set operations which are meaningless outside the relational world. If you want to use set operations, use a relational database.

I'm going to disagree. A partial implementation of SQL would go a long way to clearing the stigma of "You old RDBMS users don't know what you're doing" that NoSQL engenders.

They are database operations, originally implemented against database management systems that attempt to map relational algebra (set operations) onto data stores. There is nothing in the SQL grammar that prevents its implementation outside RDBMS.

> "Doesn't work because those are set operations which are meaningless outside the relational world. If you want to use set operations, use a relational database."

I don't want to do set operations, I want to retrieve data.

SELECT * FROM user_collection WHERE city = 'Bronx' expresses a desire for data, not a desire to perform a bunch of set operations, and should be functionality that is provided but the database vendor since we've had SQL since the 1980s and "everybody" knows SQL.

Take a look at this page form MongoDB's web site: http://www.mongodb.org/display/DOCS/Mongo+Query+Language

It is telling that they explain API examples in terms of SQL SELECT statements. I infer that if they wanted to do the work they could provide a SQL processor, and extrapolate to every other API-only datastore.

I really wish I could agree with you, but in my experience, ActiveRecord is just way easier to deal with than Mongoid.

Here's a quick an easy way to deploy both Mongo and Postgres, and start comparing them:

    git clone http://github.com/shykes/sqlwars
    cd sqlwars
    pip install dotcloud
    dotcloud create sqlwars
    dotcloud push sqlwars
    
    # Open mongo shell
    dotcloud run sqlwars.mongo mongo

    # Open postgres shell
    dotcloud run sqlwars.postgres psql

Happy hacking!

Reply on news.ycombinator.com