8 ms·
What MongoDB got right (2015)
- retox 9y ago(2015)
- mankash666 9y agoMongo is one of the few NoSqls to offer "unique" keys. While common in SQL, this is a big differentiator from other NoSqls and allows many use cases that would have otherwise ended up in the SQL world
- digitalzombie 9y agoWhat? Are you talking about like primary key? Cassandra have this, any hash database should have some sort of unique concept or key, and IIRC graph database all node should be unique. I didn't realize this was a rare thing in NoSQL world.
- deleted 9y ago[deleted]
- jakozaur 9y agoThe biggest thing MongoDB got right was putting developer first, optimize for initial experience and development speed. Most database systems came from relation theory background and optimize for performance, operations, data safety, but often developer convenience was sacrificed. Did anybody liked writing data migration? Try explaining value of table migration to some Product Manager of early startup :-). You can argue if that's were the right tradeoffs, but that's how MongoDB get a lot of steam.
- matthewmacleod 9y agoI wouldn’t say this is something it got right - actually something it got wrong! I have never worked with a company that was sunk by the cost of migrating data between schemas. I have, however, worked with companies where the bugs that come with a schemaless database have almost sunk it. YMMV of course but I think it’s a false trade-off. I would say that the developer experience was good in the sense that it was very easy to replicate Mongo databases - but that’s more of a system administration thing. I honestly don’t think that schemaless databases add any real value.
- dfcowell 9y agoWe're going through hell right now because the system I inherited uses Mongo for order/transaction/inventory data which benefits HUGELY from being stored in an ACID-compliant database, even when you ignore the fact that the data is highly relational and perfectly suited to a "boring" SQL DB. Mongo has its place, but its place isn't in most line-of-business applications for SMEs. "Pick the right tool for the job" has been the biggest casualty in the midst of the schemaless hype we're going through right now.
- bonesss 9y ago> "Pick the right tool for the job" has been the biggest casualty in the midst of the schemaless hype we're going through right now. Even getting to the point of realizing that most domains where NoSQL or schemaless solutions thrive are also domains where you need to be thinking in suites of persistence technology, ie where trying to choose a single data persistence technology is crazy, would be a big step. A beast like Reddit (for example), has clear areas where a document centered schemaless approach would yield big wins, but that doesn't mean it's ideal for handling their advertising billing or their master data. "The job" is quite often many smaller jobs, each of which needs it's own tool. Sometimes it's a lot easier to put on slippers than to carpet the whole world.
- GenericsMotors 9y ago> Querying SQL data involves constructing strings, and then – if you want to avoid SQL injection – successfully lining up placeholders between your pile of strings and your programming language. If you want to insert data, you’ll probably end up constructing the string (?,?,?,?,?,?,?,?) and counting arguments very carefully. Uhm what? At least in .NET+SQL Server land you can give your SQL queries named parameters. If there's a mismatch you'll get an exception saying so... Perhaps this is a problem in some other stack (PHP?)
- lkuty 9y agoBTW we can use stored procedures in SQL which provides many benefits. It is often forgotten.
- knocte 9y agoHaha, no please, no business logic in the DB in this decade.
- Xylakant 9y agoInstead write a micro service on top of it that holds all the domain knowledge about how the data is structured in the storage layer? Stored procedures are not necessarily business logic, they can be an abstraction layer over the underlying structure, so yes, that can quite well make sense to place it in the DB.
- knocte 9y agolol, go back to your cave
- dotancohen 9y agoHow do you version control that? EDIT: To those mentioning migrations, note that reviewing migrations are like reviewing patches. Sometimes you want to not review a specific patch but rather look at the whole method, and `blame` a specific line or three to get an idea of what the previous developer's intention was. You can't get that type of overview from reviewing each patch or migration.
- lima 9y ago> SQL is a great language for ad-hoc exploration of data or for building aggregates over data sets. It’s an absolutely miserable language for programmatically accessing data. Disagreed. SQL is great for programmatically accessing data, especially with a good client library like SQLAlchemy. I have a much easier time understanding and, most importantly, debugging SQL than MongoDB's query language. It did not solve the injection issue either, MongoDB injections are a thing[1] and they're much harder to reason about than SQL injections. [1]: https://www.owasp.org/index.php/Testing_for_NoSQL_injection https://www.owasp.org/index.php/Testing_for_NoSQL_injection
- TruffleMuffin 9y agoI believe the authors point is that you have to use SQLAlchemy for that experience. Natively, the experience is much harder and that's why ORMs (like SQLALchemy) have been built. In MongoDB, the driver matches the command line interface 1-1, there is no need for a higher level wrapper so that you can use your database.
- dullgiulio 9y agoThat's actually a myth. One thing is Object Mapping, which is repetitive, but whenever there is a layer of indirection to "hide SQL from the developer", then there will be developer pain and waste of developer time. SQL is just a language and needs to be learned. It's not hard and being declarative it also teaches to think differently than imperative programming. Want to query in Javascript? Sure go ahead, but don't say SQL is harder.
- camus2 9y ago> The situation is sufficiently untenable that it’s rare to write apps without making use of an ORM or some similar library, creating additional cognitive overhead to using a SQL database, and creating painful impedance mismatches. That's only true if you're using PHP,Python,Javascript or dynamically typed language. Mongo documents don't automatically map to classes in C++ or Java, the impedance mismatch still exists and a data mapper library is still required, just like with RDBMS.
- Nican 9y agoTalking about an easy experience for failover, and horizontally scaling, I recommend taking a look at MemSQL or NuoDB. I think MemSQL did a really nice job in creating a fast bare-bone SQL solution, with an easy to use management interface. https://docs.memsql.com/operational-manual/v6.0/managing-high-availability/ https://docs.memsql.com/operational-manual/v6.0/managing-hig...
- api 9y agoMost widely mocked, most successful, first open source IPO in a long time.
- sempron64 9y agoNot sure why you were downvoted. It is at least a little exciting to see a successful IPO of a business built on an open-source database, even if it's not the best one. It proves the model is viable, and is a healthy thing for open source in enterprise.
- xchaotic 9y agoSorry for the obvious plug, but if one wants solid replication, ACID compliance and a few other 'enterprisey' features, you should try MarkLogic: https://developer.marklogic.com/products https://developer.marklogic.com/products I feel like we got a lot more things right ;) Other than price it would be good to hear, if people agree and what's missing still.
- ceronman 9y agoI'm not convinced about the point of structured operation format. I agree that manually building SQL strings can be cumbersome. But in practice you can use libraries that allow you to easily create them programmatically. The JSON queries of MongoDB on the other hand, while they are simple to use programmatically, they are a pain to use outside of your program, for example for running ad-hoc queries, or generating a report from your data. And there is no library to fix this.
- igor_filippov 9y agoSlightly off-topic, but once ActiveRecord(Rails) - always ActiveRecord. After years of developers complaining about SQL DBs being "difficult" and MongoDB allowing to "easily prototype", I still don't get what's hard about working with PostgreSQL if you use something like Rails.
- majidazimi 9y agoSQL is most sophisticated language ever built by mankind. It is centuries ahead of the second most productive language. Mix Window Functions, Common Table Expressions, Qube/RollUp, Materialized Views, ... and holy smoke... You should try really hard to be unproductive with SQL and any relational system.
- jrs95 9y agoWait, why isn't this a blank page?
- hardwaresofton 9y agoMarketing. Marketing is what MongoDB got right, along with a small helping of being early to market. It's not even the best or most convenient document store, doesn't have the most features, isn't the most secure, doesn't handle high availability the best, they basically got everything just "good enough" (and sometimes not), along with stellar marketing. They marketed their asses off while they iterated to build a document store that was worth the praise they got people to heap on to it. IIRC the acquisition of the wired tiger engine was basically a rewrite, because the previous implementation was just bad. So if the database engine wasn't good, and distribution wasn't good (until later), and schema management wasn't good, and the query language wasn't all that great, what did mongo really get right? Marketing and being early to market/new and shiny at the right time (when everyone was deciding that writing the frontend and the backend in the same language, javascript, was an awesome thing -- which I don't necessarily disagree with). If someone needs a database these days, I always just suggest postgres. if it's good enoguh for reddit (https://github.com/reddit/reddit/wiki/Architecture-Overview#reddit-the-software https://github.com/reddit/reddit/wiki/Architecture-Overview#...), it's good enough for the next facebook for dogs (unless your problem is completely different then of course you should explore whatever database paradigm fits your problem the best).
- oneweekwonder 9y ago> suggest postgres. and if you have projects in maintenance using mongo, mysql. etc. try fdw[0]. It will allow you to query old systems using pgsql/plpython to integrate more easily into your new design or developments. [0]: https://wiki.postgresql.org/wiki/Foreign_data_wrappers https://wiki.postgresql.org/wiki/Foreign_data_wrappers
- hitchhiker999 9y agoOur community began being filled with relatively inexperienced types who treated engineering problems and solutions like a popularity contest. It was suddenly 'smart' to mock it, so they did, barely understanding the basics. In essence a desperate attempt to fill the gaps in their CV. Meh. If you find yourself mocking, you're probably doing something wrong somewhere
- themtutty 9y agoDoesn't Postgres do everything that MongoDB does? I still see MongoDB's popularity coming primarily from ignorance about what PG can do.
- kuharich 9y agoPrior discussion: https://news.ycombinator.com/item?id=10554391 https://news.ycombinator.com/item?id=10554391
- combatentropy 9y agoThe appeal and the pitfall of JSON is just that it's less broken down than tables. Suppose you built a "contact database," but all it was was the scanned images of people's business cards. You could flip through pages of them, but you can't do searches. But the input is so easy, just scan and save. And the output is likewise easy, just embed the images in a web page. 1. Running optical character recognition would be the first step in breaking down these cards into parsable information. 2. Converting the text into JSON and storing it in MongoDB would be taking it to the next level. 3. Breaking down the JSON into a set of tables would turn it into the most flexible and useful form --- but it's also the most work. You don't have to take all your data all the way to tables. For example, I leave my website log files as text. Grep and awk are usually all I need. I don't usually import them into tables --- although I have a few times for easier analysis! Although you don't have to turn everything into tables, I would say there are several applications out there where the developer should have gone all the way and not stopped at JSON.
- ChicagoDave 9y agoA couple of notes: MongoDB is excellent for design-first rapid agile development when domains are still maturing. This is common in large system redesigns and start-ups. Comparing MongoDB to SQL or relational is pointless. They are tools. Given the right circumstances, both serve a purpose. Relational databases are still necessary for analytics and reporting. (Try using any reporting tool on a schemaless database or a schema that’s a moving target) I would argue that MongoDB is best used for R&D, but once your domains have matured, quickly moving to a relational data store will provide more sustainability. I’ve also started incorporating graph databases into my architecture thinking. You should too.
- pdimitar 9y agoWould you please give a practical example for your last point (graph databases)?
- ChicagoDave 9y agoSecurity. Instead of using tables "Roles, Users, UserRoles, Actions, RoleActions" or whatever model you've come up with in the past, think in terms of graphs: Person P [IS IN] Role R Action A [IS IN] Role R Now you can match a person to actions and using a query language like Cypher (Neo4J), it's very easy. I've found this to be vastly more efficient than using a relational or document database. I have an implementation of Identity Server 3 with the back end store in Neo4J and it's so much easier than managing a SQL back end.
- ZECTBynmo 9y agoI highly recommend ArangoDB as an alternative to Mongo - similar noSQL setup backed by RocksDB (as of 3.2) and includes graph database abilities.