Does this offer absolutely anything new ? No.
Is this person objective and well respected ? No.
Does this person understand why MongoDB/MySQL is popular ? No.
Is anyone going to gain anything from this ? No.
Is this person objective and well respected ? No.
Does this person understand why MongoDB/MySQL is popular ? No.
Is anyone going to gain anything from this ? No.
Well, if it stops someone from using MongoDB without really thinking about whether they ought to, maybe it'll save someone some grief in the future.
You realise that they are using default kernel implementation? Awful indeed. :)
If you are so anti-MongoDB, would you care to offer an alternative? It must support: - document-like storage (I already have schema on application layer), - simple use / administration, - hot backup, - single node operation.
While this list is mostly outlining why MongoDB is a great DB for my current use case, I am also genuinly interested in better solutions (for that case). So, fire away... :)
Sure, but by that argument I don't need SQL either. I am not sure what your point is?
Anyway, the selling point (for me) is that I don't need to find some fancy ways to translate my schema to relational schema. For instance, let's say I have some text content in two languages; in relational DB the texts should probably go to a separate table and I should reference the main record by some foreign key. In document-oriented DBs I can just put both of the texts inside the record... To me that makes much more sense.
But yeah, if you are a hardcore SQL user who is used to normalizing the data until it hurts (as someone else commented) it is difficult to break out of the habit.
And after you eliminate SQL as an alternative (in my case) there are not many options left. At least I couldn't find (m)any.
You can achieve this in the same table with the JSON storage type:
http://www.postgresql.org/docs/devel/static/datatype-json.ht...
Really though, a decent ORM will take care of all the foreign key implementation, and a hashmap is well served by a 2nd table called 'texts' with 3 columns. I can see why you would be opposed to this, because of the extra join but given the right indexes it won't be slow at all.
First of all, using the kernel's paging algorithm for a database is awful. It has way less information about your access patterns than the database, so it's going to make a lot of bad decisions, and a bunch of MongoDB's problems with fragmentation and performance cliffs come from using mmap. It's quick and dirty.
Here's the alternative, and it supports the exact same document storage as MongoDB, the same administration interface, actually the same protocol everywhere, hot backup, and however many nodes you want: TokuMX[1]. It does all those things because it's actually mostly MongoDB, just with the storage engine replaced with an engine that works faster, compresses your data, and has more mature things like document-level locking for writers and better multi-document isolation semantics on a single node. Give it a whirl and let us know if you like it.
Having evaluated nearly every database for my own startup I find it extraordinary that there such angst towards a technology. Sure MongoDB has its faults but so does everything and surely competition is good to keep everyone honest. I mean would PostgreSQL really have had HSTORE if MongoDB never existed ?
At least stop rehashing the same tired arguments for everyone's sake.
first commit for hstore http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;...
Wikipedia states the first release of mongodb for 2009
HSTORE as most people know it is the JSON/V8 implementation.
So depending on your use-case and the type of documents and queries you are dealing with, neither the current HSTORE implementation nor the current JSON implementation will work for you, while MongoDB's model might.
But the reverse is true too: Some use-cases are highly relational and it would be really painful to do that with MongoDB due to the lack of easy joins (you have to do them in your application logic which means a lot more work as your requirements change).
Pick the right tool for the job.
Me personally, I prefer the immense flexibility for querying a relational data set over the flexibility of not having to deal with schemas. The reason is that it's much easier to change or add an SQL query than it is to re-format and re-duplicate all of my data followed by more or less manually implementing as good query plan in application code whenever the requirements change.
But this is a pure matter of taste.
Yes. The hstore extension was added to postgres in 2006 (commit 642194ba0cdc0aada9c99bf7712fcae5f3ac86d1), though it predates that date by quite a bit.
The first commit to MongoDB was in 2007
But that doesn't really matter. The reason I dislike MongoDB is that it shipped with unsafe defaults for years and caused people to lose data because of that.
For me, the one must-have feature of a database is that it will always allow me to read the data I've written to it (minus hardware defects). A database which can't fulfill that one feature doesn't qualify as a database in my book.
MySQL has issues there (it allows invalid data to be written and then "corrects" it and I've seen it corrupt table and index data multiple times without any evidence of hardware issues) and so does MongoDB (unless you changed the default config).
This has nothing to do with NoSQL vs. SQL (though, personally, I really like the flexibility for querying offered by the relational model) and everything with data integrity.
Lamest argument ever... Are you suggesting that the majority of postgres (say) installs are running default config with no changes? Or even better, Oracle?
Also, the default config of most databases is very conservative: You won't get speed, but you will get safety and it'll run on whatever hardware you throw at it.
Mongo on the other hand came with unsafe defaults and no obvious warning for people to change it. Additionally, after fixing the configuration, you would lose a lot of performance to the point of it being impractical to run mongo in a safe configuration.
Larger installs, which probably do account for the bulk of transactions, are more likely to have been tuned for speed, although probably keeping all of the safety settings at (or above) their defaults. But part of the point here is that in a safe configuration Mongo makes things slower than default.
Surely when using any sort of new technology, you'd do some basic research about write concerns, durability, etc. first? If you just lazily adopt a new technology without reading the documentation, that seems like a bit if a recipe for disaster to me...
It's a cultural problem. When you go to a web dev meetup you inevitably meet a programmer in their early 20s who thinks SQL is obsolete and Mongo will be everywhere.
The problem is that it's really nothing new -- it's an XML Database using JSON. There are well understood advantages and disadvantages.
It's just frustrating to constantly encounter people who are convinced that it's a silver bullet.
But anything old is not worth doing to some people (luckily reproduction is the oldest human endeavour ever, so hopefully they won't multiply :)
There is a reason that RDBMs with SQL is still alive almost four decades after its inception... it was a quantum leap forward (and still is)
The point is data quality, data durability and flexibility... and performance...
Remember, those who are ignorant of history are doomed to repeat it...
Btw. as others pointed out, HSTORE actually predates MongoDB, but I give you that some of the fire under HSTORE is due to MongoDB's "threat"... As a very happy PostgreSQL user I thank MongoDB for that at least :)