What MongoDB got right (2015)

89 点作者 wheresvic3超过 7 年前

19 条评论

Marketing. 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 (<a href="https://github.com/reddit/reddit/wiki/Architecture-Overview#reddit-the-software" rel="nofollow">https://github.com/reddit/reddit/wiki/Architecture-Overview#...</a>), 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).

评论 #15798817 未加载

jakozaur超过 7 年前

The 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.

评论 #15795765 未加载

评论 #15795701 未加载

评论 #15796296 未加载

评论 #15795974 未加载

评论 #15795665 未加载

评论 #15796089 未加载

评论 #15795694 未加载

评论 #15796087 未加载

评论 #15796864 未加载

评论 #15796026 未加载

评论 #15795704 未加载

lima超过 7 年前

> 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]: <a href="https://www.owasp.org/index.php/Testing_for_NoSQL_injection" rel="nofollow">https://www.owasp.org/index.php/Testing_for_NoSQL_injection</a>

评论 #15797679 未加载

评论 #15795743 未加载

ChicagoDave超过 7 年前

A 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.

评论 #15804287 未加载

majidazimi超过 7 年前

SQL 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.

GenericsMotors超过 7 年前

> 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?)

评论 #15795577 未加载

评论 #15795609 未加载

评论 #15798126 未加载

ceronman超过 7 年前

I'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.

combatentropy超过 7 年前

The 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.

igor_filippov超过 7 年前

Slightly 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.

mankash666超过 7 年前

Mongo 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

评论 #15795680 未加载

camus2超过 7 年前

> 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超过 7 年前

Talking 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. <a href="https://docs.memsql.com/operational-manual/v6.0/managing-high-availability/" rel="nofollow">https://docs.memsql.com/operational-manual/v6.0/managing-hig...</a>

kuharich超过 7 年前

Prior discussion: <a href="https://news.ycombinator.com/item?id=10554391" rel="nofollow">https://news.ycombinator.com/item?id=10554391</a>

hitchhiker999超过 7 年前

Our 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超过 7 年前

Doesn't Postgres do everything that MongoDB does? I still see MongoDB's popularity coming primarily from ignorance about what PG can do.

ZECTBynmo超过 7 年前

I highly recommend ArangoDB as an alternative to Mongo - similar noSQL setup backed by RocksDB (as of 3.2) and includes graph database abilities.

xchaotic超过 7 年前

Sorry for the obvious plug, but if one wants solid replication, ACID compliance and a few other 'enterprisey' features, you should try MarkLogic: <a href="https://developer.marklogic.com/products" rel="nofollow">https://developer.marklogic.com/products</a> 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.

retox超过 7 年前

(2015)

api超过 7 年前

Most widely mocked, most successful, first open source IPO in a long time.

评论 #15803297 未加载