21–30 of 53 posts
Disappointing. I want to like MongoDB, but if this is the best a MongoDB apologist can come up with, I'll stick to SQL with a decent O-R mapping.
I guess I am old-school but you are listing a bunch of reasons why MongoDB is not evil, yet each and every one of these reasons turns out to be extremely risky business. All of which simply do not apply with relational datastores. The thing I took away from your post is that had you used a 20-year-old relational datastore you would have 0 of your issues anyway. > The advantages of schemaless documents are priceless.…
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.
The "no migrations" claim is a lie. Migrations still exist, they just happen at the time of reading: def parseMongoRow(jsonBlob): x = None if jsonBlob['date'] For expiring fields in a redis database, this isn't a big deal. Your code stinks between [time of migration, time of migration + ttl]. For a permanent datastore, ouch. I also do not understand why they are using MongoDB for this. They describe a schema involvin…
Mongo also stores the same column/attribute names with every single row. 50000 inserts? 50000 (usually identical) sets of attribute names stored (compared to once for SQL). And to my knowledge they are stored uncompressed. For a Big Data database, it doesn't seem very good at efficiently storing big data.
> Mongodb expects that your working set fits into RAM along with the indexes for your database. 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.
The "no migrations" claim is a lie. Migrations still exist, they just happen at the time of reading: def parseMongoRow(jsonBlob): x = None if jsonBlob['date'] For expiring fields in a redis database, this isn't a big deal. Your code stinks between [time of migration, time of migration + ttl]. For a permanent datastore, ouch. I also do not understand why they are using MongoDB for this. They describe a schema involvin…
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"
I guess I am old-school but you are listing a bunch of reasons why MongoDB is not evil, yet each and every one of these reasons turns out to be extremely risky business. All of which simply do not apply with relational datastores. The thing I took away from your post is that had you used a 20-year-old relational datastore you would have 0 of your issues anyway. > The advantages of schemaless documents are priceless.…
> 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 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…
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.
I guess I am old-school but you are listing a bunch of reasons why MongoDB is not evil, yet each and every one of these reasons turns out to be extremely risky business. All of which simply do not apply with relational datastores. The thing I took away from your post is that had you used a 20-year-old relational datastore you would have 0 of your issues anyway. > The advantages of schemaless documents are priceless.…
Not if your application is still on development.
100k+ rows? Not complicated. Try with 23M rows.
Nobody would risk migrating that table.
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 "no migrations" claim is a lie. Migrations still exist, they just happen at the time of reading: def parseMongoRow(jsonBlob): x = None if jsonBlob['date'] For expiring fields in a redis database, this isn't a big deal. Your code stinks between [time of migration, time of migration + ttl]. For a permanent datastore, ouch. I also do not understand why they are using MongoDB for this. They describe a schema involvin…
Condescending much? 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…
'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.)
I guess I am old-school but you are listing a bunch of reasons why MongoDB is not evil, yet each and every one of these reasons turns out to be extremely risky business. All of which simply do not apply with relational datastores. The thing I took away from your post is that had you used a 20-year-old relational datastore you would have 0 of your issues anyway. > The advantages of schemaless documents are priceless.…
"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." Not if your application is still on development. 100k+ rows? Not complicated. Try with 23M rows. Nobody would risk migrating that table.