How (and why) Sillicon Alley Insider uses MongoDB

http://www.businessinsider.com/how-we-use-mongodb-2009-11

by DXL • 17 years ago

44 11 17 years ago

cx013• 17 years ago

Most of the things the article talks about are actually possible in a SQL database. You can easily store JSON data in table rows if you want; foreign keys and joins are just further options that SQL offers you and MongoDB doesn't. I also don't understand the argument for a schema-less database. After all, you always have a schema; in a SQL database it is explicit, whereas in MongoDB it is implicit. Seems similar to the argument between proponents of dynamic and static typing.

Overall I think the only reason for going with MongoDB is performance.

nuggien• 17 years ago

> Overall I think the only reason for going with MongoDB is performance.

Isn't that reason for almost all decisions regarding which db to use? Going with the db that performs the best while suiting your specific needs?

cx013• 17 years ago

I agree with your statement. I'm just unhappy that the article gives arguments in favor of Mongo that equally well apply to any SQL database. I would have liked more insights into the actual performance differences.

ibwhite• 17 years ago

Hey there -- article author here. Thanks for reading.

Storing JSON data in a SQL database is possible but not practical. For one thing, it's very difficult to query the individual fields within that JSON data. You also can't retrieve a portion of the data, or do atomic updates to individual fields, etc. It's something I've done before and it's just not pleasant.

The schemaless thing is to some degree a matter of taste, yes. What's not a matter of taste, as I mentioned in the article, is when you have to run an alter statement on your huge SQL dataset that takes down your site for hours.

But I don't believe that one size fits all. Some websites will be better off with a RDMS. Mongo's better for us. Again, thanks for reading and commenting.

cx013• 17 years ago

> For one thing, it's very difficult to query the individual fields within that JSON data. You also can't retrieve a portion of the data, or do atomic updates to individual fields

I think this may be possible to some degree using the scripting capabilites of the RDBMS, but I don't know for sure. Even then, I have to agree that in Mongo it is much easier to do because it's built-in.

> when you have to run an alter statement on your huge SQL dataset that takes down your site for hours.

That's indeed a problem. I wonder if there's a SQL database that allows instant schema changes; I can't see a reason why it shouldn't be possible technically.

jhancock• 17 years ago

Performance is only one reason I've chosen MongoDB for my new app. I actually don't see the performance factor yet as I'm still developing and would see good enough performance on any number of DB choices.

The benefit I am seeing right now is development agility. I'm writing my app in ruby/merb. I created a simple lib for mongodb's ruby driver to give me simple first class object wrappers for my JSON data structures. I do not need to declare schema stuff anywhere. I can also write ruby scripts outside the merb server proc easily without going through an ORM framework.

As I have another in-production app also using merb using postgres through datamapper, I have a clear comparison to believe I'm realizing productivity gains with mongodb.

buro9• 17 years ago

Just storing JSON in a database is not good enough, you need to be able to aggregate and index that data.

I find XML an easier example of why it's important that the database treats a semi-stuctured store as a first class entity, let's compare Oracle and SQL Server: SQL Server: http://msdn.microsoft.com/en-us/library/ms189887%28SQL.105%2...

Oracle: http://download.oracle.com/docs/cd/B19306_01/appdev.102/b142...

MS SQL Server:

"Note the following general limitations that apply to the xml data type:

    * The stored representation of xml data type instances cannot exceed 2 GB.
    * It cannot be used as a subtype of a sql_variant instance.
    * It does not support casting or converting to either text or ntext. Use varchar(max) or nvarchar(max) instead.
    * It cannot be compared or sorted. This means an xml data type cannot be used in a GROUP BY statement.
    * It cannot be used as a parameter to any scalar, built-in functions other than ISNULL, COALESCE, and DATALENGTH.
    * It cannot be used as a key column in an index. However, it can be included as data in a clustered index or explicitly added to a nonclustered index by using the INCLUDE keyword when the nonclustered index is created."

Ok, so that's a pretty constraining set of restrictions. Just look at the lack of grouping, sorting, built-in function support.

And Oracle? Well it does all of that and allows for partial updates (update one Xml node or attribute and not the whole document). Oh, and Oracle fully implements XQuery too.

The difference between just storing something in a database and having the database understand and treat that something as a first class entity is massive.

I've used Xml as an example because it's well documented and understood, but the example extends to JSON/BSON easily enough.

chrischen• 17 years ago

I'm using LNMP (pronounced "lamp")

Linux nginx mongodb php

zaphar• 17 years ago

    it doesn't have any built-in revisioning like CouchDB

This is probably one of the most mis-understood features of CouchDB. It's not a revision per-se. It's a feature to support MVCC. It's not meant to show the history of the document over time and it's not guaranteed to be there for all time. If you compact the database the past revisions will be deleted. Referring to the revisions as a feature is somewhat of a misnomer. They are there to enable a feature(MVCC and as a per document consistency check on writes) but aren't really a feature in and of themselves.

bhseo• 17 years ago

"But overall, MongoDB is probably well-suited for a lot of web applications -- maybe as many as 50%."

Found this at the end of the article, made me chuckle.

How (and why) Sillicon Alley Insider uses MongoDB

Related Stories