Mongodb – not evil, just misunderstood(siddharth-ravichandran.com) |
Mongodb – not evil, just misunderstood(siddharth-ravichandran.com) |
def parseMongoRow(jsonBlob):
x = None
if jsonBlob['date'] < 2012/12/02:
x = jsonBlob['foo']['bar']
else if jsonBlob['date'] < 2013/06/01:
x = mergeFields(jsonBlob['bar'], jsonBlob['baz'])
else:
x = jsonBlob['x']
...
I also do not understand why they are using MongoDB for this. They describe a schema involving shipments, shippoints and orders, and one of these things does not occur without the other (an attempt at justifying the document based data model?). I.e., something like this:
CREATE TABLE orders (...)
CREATE TABLE shipments (
order_id BIGINT REFERENCES orders(id) NOT NULL,
ship_from_id BIGINT REFERENCES shippoints(id) NOT NULL,
ship_to_id BIGINT REFERENCES shippoints(id) NOT NULL
)
They have several hundred shipments/day, and lets be generous and assume there are 100 updates/notes to a shipment. We are talking maybe 50,000 inserts/day (omfg big data, invest in a 1TB hard disk!) and it sounds like data that's considerably more important than an ad impressions or pageviews. (Well actually it fits in ram, so maybe the 1TB hard disk on a dedicated server is overkill.)
Also, consider the daily aggregate generator in 3 lines of SQL rather than 236 lines of javascript:
SELECT date, carrier, zone, COUNT(id), SUM(price)
FROM shipments
GROUP BY date, carrier, zone;
This is particularly bad if these changes are small and incremental as each one in isolation looks reasonable but the cumulative effect over a few years can be a complete nightmare.
Yes, migration happen at read time (translating on the fly may be a possibility without rewriting old documents as well)
Of course doing this is easier than adding manually columns every time you need to change something. PGSQL fans love to say how this works wonderfully in theory but in practice it's not as pretty as it looks like.
"SELECT date, carrier, zone, COUNT(id), SUM(price) FROM shipments GROUP BY date, carrier, zone;"
Nice try, but no.
This select doesn't even match your proposed CREATE TABLE above. It's at least missing a JOIN.
And the 236 lines of JS, well, there's a lot of specifying fields, (22 of them), so, if you do that on SQL you'll end up with lots of lines as well or at least an ugly to read line.
"I don't get it. How is mongodb even remotely the right tool for this job?"
Of course, it's hard to find someone who uses MongoDB respecting its limitations and using it appropriately, most MongoDB hating posts are similar to "I'm trying to attach a trailer to my motorbike and it doesn't work, I also tried taking it onto a lake and it broke, this sucks"
'zone_2': 0,
'zone_3': 0,
...
SELECT date, carrier, zone, shipment_type, COUNT(id), SUM(price)
FROM shipments GROUP BY date, carrier, zone, shipment_type;
Those fields would need to be on the create table. The simplified create table I wrote was simply to illustrate the fact that SQL also handles the issue of "We rarely used most of these entities without the other". Or maybe you would join against them, in which case my 3 line solution becomes 4-5 lines.
It's not for nothing that people like to build SQL on top of Hadoop (see Hive, Impala). SQL queries are nearly always a lot simpler than comparable MapReduce code. (I find these efforts misguided, but separate issue.)
-Yes you can make aggregate results using map reduce (In javascript with a single core, idempotent) and you can store the aggregates as separate documents. I do not see what is so magical about this.
-It is true that you do not have a set schema thus no migrations, but you do have to have a schema in mind for nearly everything as something has to make sense of that field.
If you add fields to a document and you already have documents in there, you are going to have to add that data to them unless you want them to be nil. If you rename a field you have to iterate all documents and add rename it. If you remove a field you have to remove it from all existing documents if you do not want to have that data around anymore. Certainly you do not HAVE to do any of this but if you are fetching meaningful data from a field you need to.
And you need to index on whatever you want to search on or the performance is terrible as Mongo is not very good on the disk so you have to keep that in mind too. I think most people were attracted to Mongo due to "no migrations" and schema but when you work with it almost any use case you find yourself using an unenforced schema and doing script based "migrations" The recent Mongo criticism is that it markets itself as a all purpose DB but in reality document stores are not that.
Yes, we should bring unacknowledged writes as a default back.
(Often a technology's greatest detractors are its own fans, they are digging its grave without even realizing).
The current stable official node driver silently wraps all exceptions, including in unrelated code launched from DB callbacks. This is acknowledged by MongoDB inc.
https://groups.google.com/forum/#!topic/node-mongodb-native/...
The author states the only downside of fire and forget is that data may not be available on subsequent queries. While this may be true, this should not be what you are worrying about. The downside is that when your primary crashes, or becomes overloaded to the point where your slaves all are lagging significantly and you need to switch primaries, the data is inconsistent and you will lose that acknowledged write.
It was a high-profile representative of the NoSQL trend and that trend is experiencing a backlash. Since it has a relatively easy learning curve and a JavaScript-centric interface (JS also beng trendy), it got a lot more uptake by startups and inexperienced developers wanting to learn about NoSQL (or move away from the supposedly moribund relational model).
The ad-hoc querying makes it tempting to build object mappers around Mongo and write the kind of code you would with an ORM. A lot of NoSQL refugees did exactly that. You can get pretty far doing that before the caveats with that approach kick in. It's much harder to fall into that trap with something like Riak.
And then MongoDB itself has had some poorly chosen defaults and design decisions. These wouldn't be so high-profile if it wasn't for the other issues.
Was the first sign that this person doesn't know what he is talking about...
Of course you still have to migrate. Either your DB or your code, because you can't handle a change in how you store stuff without one or the other.
"No migrations" is true only for the most trivial of changes, and only if you're willing to handle special cases in your code.
Honestly, I think the difference between schemaless and SQL corresponds very closely to the differences between static and dynamic-typed languages. The schemaless approach provides faster iterations and the ability to simply express things that require elaborate language features in a static-typed language. The difference is that in a DB, you have to support the data created by all your previous versions, so a DB requires far more discipline than the application code.
I can see the appeal, but I'm not sure that it's worth it.
IMO MongoDB is currently in the trough of disillusionment
> The advantages of schemaless documents are priceless. Not having to migrate is just one of the perks. Our schemas were largely in the form of Orders (having many) Shipments (going_from) ShipPoint (to) ShipPoint
You say priceless. I don't think it means what you think it means. A migration is costly but also pretty rare. I migrate PostgreSQL with 100k+ rows as a matter of routine, it's over before you know it. The schema you are using (orders have many shipments going from point to point) are easily expressed in a relational schema and once defined would hardly ever need to change, if at all during the lifetime of the application. So what if I need to add a column here or there. It won't matter at all. Do you have more than 100 million documents in MongoDB? I guess you don't. Even if you do, relational has that covered too.
> This doesn’t always have to be the case, though it significantly contributes to Mongodb’s fast writes.
What you are saying is that I need to change MongoDB in order to make it safe. Relational database are safe out of the box, no change necessary.
> We add a lot of Notes to each shipment [...] it doesn’t critically affect the business workflows of the application.
Say what?
You're fine with data, even notes, being lost? That is completely acceptable to you? I guess this is what shocks me most. You kids think it's normal to lose data, and consider storing a note to be optional or something. It baffles me. If a note is optional, why have it in the first place?
> They do but since most of the stuff is memory mapped
Translates to: you need to have your data in RAM. This does not scale at all. It doesn't even begin to scale to the level where MySQL was. TEN years ago.
> Here is a simplified snapshot
What follows is a class that is 236 lines long. Two hundred and thirty-six lines long. Dear sir, if this is your simplified code I fear what your actual production code looks like. If you committed that to one of my repos we would have a very serious talk. Also you would do this exactly once during your career at my company.
> I haven’t even touched upon the replication and sharding features that Mongodb offers which I will reserve for another post.
Which every relational store also offers.
> To summarise I feel Mongodb is awesome
Why is it awesome? You have only shown me why it is horrible. I have seen nothing that is awesome. Optional data persistence, needs huge amounts of RAM, complex application level code to deal with reports, this is all stuff that you can do better, faster and more reliable with a relational solution.
MongoDB is a tool, understand it's strengths and limitations and it will serve you well. We achieves great performance for our use-case by correct schema-design / partitioning of data, and sane use of indexes - which are excellent in MongoDB. If you need to scale large, you need to store the data in such a way that it does not require much resources to fetch them, i.e. you must store the data according to your read-requirements. This is even more true in "key-value" systems like Cassandra, which is more limited in how you can store data. MongoDB is very flexible, so it's a lot easier to shoot yourself in the foot.
10gen were good at marketing, but businesses require results, not marketing.
MongoDB solves little problems.
"MongoDB Gotchas and How To Avoid Them: Don't use MongoDB"
It doesn't inspire much confidence in reliability to be honest...
I ended up figuring out a workaround but it left a bad taste in my mouth. My workaround was to create a temporary collection and insert all the previous records, with their Category attribute updated, in a single .insert call.
I am more than sure that an SQL UPDATE query using a subselect for the COUNT(*) would have probably executed in less than a couple seconds. That's what's so sad about MongoDB. And I even had everything indexed, it made almost no difference. The write/read locks are _murder_.
houses.db.eval(function(){
const tmp = db[Math.random().toString(36).slice(2)];
tmp.insert(
db.houses.find().map(function(e){
e.Block = db.houses.count({
Street: e.Street,
Sector: {$lte: e.Sector},
Quadrant: 1
});
return e;
})
);
tmp.renameCollection("houses", true);
}, {nolock: true}, function(err){
dbCallback(err);
console.log("Done!");
process.exit();
});
I don't really get this. Surely any database system is going to be faster if all frequently updated/accessed pages fit into ram...what makes mongo special in this regard? Why does it degrade so badly when it has to access disk (beyond the obvious)?
But yes, this is a problem on any DB. The moment it hits disk, performance is terrible.
This is an over-simplification for any mature database unless all you care about are massive, completely random read workloads[1]. RAM will obviously be faster but there's a difference between terrible and performing at the level of the underlying disk subsystem. With a decent system, commits per second should track the underlying storage array's IOPS, large read / write traffic should be capable of approaching disk bandwidth, etc.
Where things do get bad is when the database is doing more random I/O than required by the workload – if storage is fragmented, it's playing sim-MySQL and creating lots of temporary tables, etc. you will see performance which is pathologically worse. This is a bug and should be fixed.
1. If writes aren't disk I/O limited, you should expect data loss because it's lying about durability.
I think the main issue is that people want something to be simple, and now that I'm dealing with the somewhat esoteric and opaquely documented postgres, I can understand that feeling. Native replication and auto-failover (via pgpool) is a bit of a black box on postgres, but under MongoDB it was fairly simple.
The problem is, it's complicated for a reason, and that reason is scale. What took me over 100 masters in MongoDB will only need two postgres boxes, so it's worth dealing with the Oracle of Open Source to make it happen.
Relational databases are safe out of the box, but it is not their unique capability. Most other NoSQL stores are safe out of the box, too, being at the same time faster and easier to scale than RDBMSes. It is only Mongo which did it differently, so please don't extrapolate that bad experience to all NoSQL.
A back of the envelope calculation. Assume each shipment brings in $0.10 in profit to his company. Suppose at some point he needs to scale up to 100,000 shipments/day. His revenue is now $10,000/day.
A "Performance One" Rackspace server costs $1250/month and Rackspace isn't known for being cheap. A Hetzner box with all the things added (12TB HD, 2.4TB SSD HD, 384GB RAM) costs 831 Euro/Month.
Not if your application is still on development.
100k+ rows? Not complicated. Try with 23M rows.
Nobody would risk migrating that table.
This has been happening for decades in the RDBMS world – even the ultra-conservative Oracle admins I've worked with were willing to come of out in-place retirement long enough to do something like that.
People migrate tables a lot bigger than 23M rows all the time. On MySQL, even, though it's an offline task there.
How many DBs do you have? Testing (usually local), staging, production? For how many sites?
It works the same, if row['new_field'] do_something() else do_something_else()
You have unit tests to make sure it works.
And if it was so safer and easy to do it PostgreSQL wouldn't have added the json field.
In your experience, perhaps, but that's reversed in many other places.
As for everything else your point is only accurate if you assume that migrations are done by hand. If use a migration library it's impossible to forget to apply a migration to a database so there's no problem working with copies or even forks of databases.
> And if it was so safer and easy to do it PostgreSQL wouldn't have added the json field.
You're implying causation incorrectly: hstore and JSON are useful for cases where you explicitly do not want schema enforcement or can't afford the performance impact of normalization. This is not saying that migrations are hard, merely that not all problems have the same best solution.
(Of course, not only migration issues, but any code issues as well)