21–30 of 118 posts
I feel the best thing to come out of MongoDB is that Postgres now handles JSON.
And Postgres can do JSON with vastly more performance than Mongo:
https://www.enterprisedb.com/postgres-plus-edb-blog/marc-lin...
Earlier quoted context omitted.
The hype is the real issue. Even today, the CTO appears to claim that 90% of apps aren't relational enough to need Mongo. I did a startup in 2011/2012 where we bought into the hype and used MongoDB & Node + Mongoose. It was horrific. Your app is relational, full stop. You would know if it wasn't. Do you have users? Do those users need to log in? Well, you now have access tokens related to users. Do those users need t…
>Do you have users? Do those users need to log in? Well, you now have access tokens related to users. Aren't those tokens supposed to be stored client side anyway? Aren't those tokens supposed to contain encoded information about the user that you decode server side? Why would you store the users token to begin with?
> By far the most consistent mistake was choosing a non-relational database, when your data was strongly relational. Mongoose's ODM made this mistake surprisingly easy to make, which led to issues down the line. This mirrors my experiences with Mongo as well. The vast majority of data is relational. Mongoose allows people to make the mistake of structuring their data relationally. But all you are doing is pushing all…
If data needs to be processed, an option would be to use MongoDB for collecting the data in bulk and later decide how you need to structure it for your needs. When it comes to "read" the data, you read it only from processed database that can be anything. Since you can do your processing completely independently of your web server, your are not necessarily pushing your computational load from the DB to the web server…
I'm a long-time MongoDB user and largely a fan of it because I believe the interface is superior to some text-based SQL statements. But whatever DB you like, if you move the state of your application to another application (i.e, a database) you better make sure you really understand how it works. For SQL databases, many people think they know how they work, but misconceptions seem widespread. Essentially, many beginn…
What do you have in mind there? Systems that process SQL statements interpret these statements, validate them for correctness against a schema and then provide an auditable plan. Just because SQL bears some resemblance to spoken/written English (a property that vanishes pretty quick when you get past simple use cases) doesn't mean it isn't rigorously analyzed by database systems; SELECT isn't some alternative form of 'grep.'
Perhaps you're thinking of SQL injection attacks that plague that the LAMP stack? If so then you should know that NoSQL isn't immune to injection attacks. Here[1] is an OWASP page on testing for NoSQL injection vulnerabilities; the same sloppy coding patterns that allow attackers to synthesize SQL statements are also manifest in NoSQL applications.
[1] https://www.owasp.org/index.php/Testing_for_NoSQL_injection
Today in 2017, there is no real reason to use MongoDB other than in prototyping. I am happily waiting until the final nail is put on the coffin of this overhyped, flawed document store.
I'm a long-time MongoDB user and largely a fan of it because I believe the interface is superior to some text-based SQL statements. But whatever DB you like, if you move the state of your application to another application (i.e, a database) you better make sure you really understand how it works. For SQL databases, many people think they know how they work, but misconceptions seem widespread. Essentially, many beginn…
Couple of points: 1. ORMs I'm not sure why you dismiss ORMs. Have you ever used a good ORM? There are a lot of high-quality ORMs out there, that do the heavy lifting, provide type safety, and take care of the boilerplate. There is no reason to write text-based SQL anymore. 2. Relations: Foreign keys are incredibly useful. They're the biggest feature I miss out in relational databases. They help keep your data in a sa…
I am a happy user and can recommend the following ORMs:
for Java, Hibernate (a classic)
for C# in .NET, how about... NHibernate?
for Python... SQLAlchemy.
Really good software. WARNING: they require you to read the manual.
> By far the most consistent mistake was choosing a non-relational database, when your data was strongly relational. Mongoose's ODM made this mistake surprisingly easy to make, which led to issues down the line. This mirrors my experiences with Mongo as well. The vast majority of data is relational. Mongoose allows people to make the mistake of structuring their data relationally. But all you are doing is pushing all…
If data needs to be processed, an option would be to use MongoDB for collecting the data in bulk and later decide how you need to structure it for your needs. When it comes to "read" the data, you read it only from processed database that can be anything. Since you can do your processing completely independently of your web server, your are not necessarily pushing your computational load from the DB to the web server…
OR, i can open a file stream, serialize my data to JSON, entity by entity, and dump all to a file.
The good old file.
(I’m the author of this series) Eliot Horowitz (HN: @ehwizard), MongoDB’s current and founding CTO, reached out after my last post - and spent two hours providing feedback last week in Palo Alto. It was an expansive discussion, and Eliot was reflective and eager to understand the perspectives I had heard. He noted how much it mattered to him what HN thought. I left with tremendous empathy for the challenges of buildi…
This does seem like a sticky situation, but a potential solution springs to mind. Maybe there's a reason this would have been infeasible, but why not introduce a "MongoDB Legacy" product line which would be a fork with unsafe defaults, secondary to the main product/branch with safer defaults? That way the old customers would have a clear upgrade path every release, just like the customers on the safe product, at the small expense of 10gen having to cut 2 releases each time and mind the diffs around options and defaults. Maybe this would have been more expedient than waiting until version 2.6 of MongoDB?
"MongoDB's CTO disagrees with this statement arguing that nearly 90% of database installations today would benefit from being replaced with MongoDB."
I used to attend "office hours" at MongoDB's office where guests ask MongoDB employees for help. Most of my questions involved very complex aggregation queries (that would have been trivial in SQL) that even MongoDB employees could not solve.
While I waited to be helped I would listen to other people ask the same questions over and over and over: "How do I join these two collections? How can I and ensure both writes succeed/fail?"
Rather than say "MongoDB doesn't offer this functionality" and maybe advise them that this database isn't what they needed for the specific project, the engineers spent a majority of these office hours explaining they don't need schemas, transactions, relations and advised them how to hack together something that worked.
I don't think MongoDB is appropriate for 90% of the database installations out there. I don't know the number, but it isn't 90%, it isn't a majority, and doubt it's a significant number.
MongoDB really needs to explain what it does exceedingly well versus the other distinct offerings in databases (RDBMS, Key Value stores, MPP/warehouses, HDFS, etc) and market that.
What they do right now is somewhere between disingenuous and down right negligent.
Of course its the responsibility of a company and its staff to choose the right tool for the job, but these postmortems are becoming tiring.
Earlier quoted context omitted.
If data needs to be processed, an option would be to use MongoDB for collecting the data in bulk and later decide how you need to structure it for your needs. When it comes to "read" the data, you read it only from processed database that can be anything. Since you can do your processing completely independently of your web server, your are not necessarily pushing your computational load from the DB to the web server…
It that point it's harder for me to understand why I'm not just writing out JSON files or something.