9 ms·
Announcing MongoDB 3.0
- davidw 12y ago> a database so powerful, flexible, and easy to manage that it can be the new DBMS standard for any team, in any industry. It's good to see they haven't sacrificed the hype while working on other features :-/
- jonesetc 12y agoI'd be worried if a major product release that is the major product for a company didn't have at least as much hype as that sentence.
- Xylakant 12y agopg release announcements tend to be fairly level headed, a quality I much enjoy.
- jimbokun 12y agoFor me, this screams "don't trust these people". I feel like I'm being sold a used car by a sketchy salesman.
- FooBarWidget 12y agoWell, I don't think you would trust them even if they don't use marketing speak.
- mrkurt 12y agoThis is sadly common in the world of database marketing. There are very few companies who are the least bit humble about what they're doing.
- draven 12y agoI like the tone of RethinkDB blog posts and announcements, it's usually more like "hey we just implemented this cool feature, check it out!" (Not affiliated with them in any way, I'm just testing rethinkdb since I have to use Mongo at work and hate it. I especially like their "stability" page: http://rethinkdb.com/stability/ http://rethinkdb.com/stability/ )
- Nelson69 12y agoI had a truly magical experience talking to an engineer at Mongo during our sales experience with them. This guy was some sort of super SE. We had a short list of things we simply could not make it do very quickly. He proceeded to tell us how no database could do those things quickly and they were fundamentally broken things to do anyways... (query where property x != y or x doesn't exist was one I can think of) PostgreSQL and Vertica did them all, radically faster than Mongo did.
- samibe29 12y agoBoth of those can be accomplished in MongoDB...maybe you should try using an index?
- stingraycharles 12y agoAs much as I agree with your sentiment, it still remains one of the most popular databases out there. All us techies can learn something from the hype they managed to create.
- engendered 12y agoI really believe that the root of MongoDB's success is how easy they made getting started: A trivial installer, no configuration, and a trivial tutorial -- boom, suddenly a million developers were on their side. It seems ridiculous, really -- developers commit to something because it saves them hours at the start, versus considering the months of work following -- but many technologies followed this curve. MySQL was a lot easier to start with than pgsql, so it won the early battle. PHP was a no-brainer to start with, etc. The lesson is that your tool should default to essentially no configuration, no security, and simple beginnings, and it tends to pay off.
- jpalomaki 12y agoJust like node.js. Simple to setup. No frameworks to learn. No need to integrate with web server. Few lines of code, run, and you have a web application responding to the requests.
- tracker1 12y agoIt's kind of funny, but MongoDB and node.js are a very natural pairing... very little disconnect. Though I really like RethinkDB, the lack of automated failover handling is about the only concern left keeping me from them. Because of the tooling around it, I'm using ElasticSearch om my next project over both of them. I've also used Cassandra in the past, which was great in some cases, harder in others. For the past couple years, I've tended to pair an SQL database with a key-value/document store depending on the needs. SQL is the canonical source, and saves are mirrored to the distributed database for wider reads. Most no-sql databases sacrifice parts of CAP/ACID in different ways, and can fit certain growth needs. When you are faced with paying a over $30-50k/month (hardware, licenses, bandwidth, redundancy) just to host your sql database on hardware big enough to handle the load, or distribute... distribution becomes an option. For a company with under a million a year in gross revenue, spending $600/year for the database alone is not an option. Even for larger companies it's probably not the best idea. There's something to be said for ease of configuration and administration in that mix.
- deleted 12y ago[deleted]
- lafar6502 12y agoBut i think it's true - really easy to set up, no maintainance, rich set of tools and idiotproof enough to prevent unexperienced from doing harm to themselves. And you don't have to know anything about databases to use it. I'd say it really sets a standard for most of startup guys.
- pkolaczk 12y agoAll is only true until you need to scale it out.
- takeda 12y agoReminds me of benchmarks between Cassandra, HBase and MongoDB[1]. The only thing it "exceeded" at was higher latency. http://www.datastax.com/wp-content/uploads/2013/02/WP-Benchmarking-Top-NoSQL-Databases.pdf http://www.datastax.com/wp-content/uploads/2013/02/WP-Benchm...
- samibe29 12y agomongo scales just fine if you know how to use it. I maintained over a 40 node cluster with 1 billion profiles in it. I believe it scales just fine. Issues is with the developers that don't understand how to use it.
- DrJosiah 12y agoI'm very happy that it worked well for you. Those with different data access patterns may not be as fortunate.
- samibe29 12y agoNot knowing anything about databases is why everyone hates MongoDB. You have people that know nothing about how to store data using mongo...then when it doesn't work they blame mongoDB. Isn't mongoDB's fault you know nothing of which you do.
- kosma 12y ago> Reduces operational overhead up to 95% And 40% more hip. Gotta love those numbers. Also, don't forget about the new WiredTiger storage engine - sounds way cooler than, say, InnoDB! Hype is strong with this one.
- lclarkmichalek 12y agoEh, Wired Tiger was built outside of Mongo (http://www.wiredtiger.com/ http://www.wiredtiger.com/), and does seem to be legitimately decent.
- hendzen 12y agoAs a funny quirk of history, Michael Cahill, the founder of WiredTiger (and now a MongoDB employee), is the primary author of "Serializable Isolation for Snapshot Databases" [0] the paper that introduced Serializable Snapshot Isolation (SSI). SSI is the concurrency control mechanism used in Postgres [1][2]. [0] - https://courses.cs.washington.edu/courses/cse444/08au/544M/READING-LIST/fekete-sigmod2008.pdf https://courses.cs.washington.edu/courses/cse444/08au/544M/R... [1] - https://wiki.postgresql.org/wiki/SSI https://wiki.postgresql.org/wiki/SSI [2] - http://drkp.net/papers/ssi-vldb12.pdf http://drkp.net/papers/ssi-vldb12.pdf
- kosma 12y ago...and their most important improvement isn't even their own. I'm not a fan of bashing any product, but after using MongoDB in several projects, in legitimate document database use cases, I just can't find any bright side.
- lclarkmichalek 12y agoOh, I can't stand Mongo. But I have nothing but respect for the Wild Tiger guys, and wouldn't want to see them slandered ;)
- mrsteveman1 12y agoThere's a solid chance the browser you're typing comments with has a JS engine called SpiderMonkey, Nitro or V8 :)
- ddorian43 12y agoYou can build a slow product and when you make it normal-speed you say 5x faster!
- mlschmitt23 12y agoI agree this announcement is dripping with hype, but all the same I'm excited to get my hands on this. Seems like they're trying to address (some) common pain points.
- jimbokun 12y ago"We will continue to push the envelope in data interaction semantics, by implementing a transaction system for the distributed document model." So...Mongo "can be the new DBMS standard for any team, in any industry", and they don't even support transactions yet?
- jraedisch 12y agoTransactions are a pain point, but since WiredTiger supports them, I hope that MongoDB will eventually implement them - better sooner than later. That said, I still fail to see, why I should not use MongoDB. For me as a not to DB savvy developer it was easy to start developing and administrating, and I haven't had any major issues on a small sized production (replicated and sharded) cluster for 3 years now. http://source.wiredtiger.com/2.4.1/transactions.html http://source.wiredtiger.com/2.4.1/transactions.html
- JonnieCache 12y ago>For me as a not to DB savvy developer it was easy to start developing and administrating This point is repeatedly made about mongo, php and so on: to me it sounds like "This gun is so easy to use, it allows me to start spraying bullets around with no training and no knowledge of how it works!" or "This car is so simple I can go 150mph on the freeway the first time I got behind the wheel!" Databases are massively powerful systems and they are used almost exclusively for business applications and matters of import. Why is "I can use it to make long-term consequential actions without any idea wtf I'm doing!" a plus point?
- lafar6502 12y agoIt's just a piece of software, a basic tool - not a war machine that requires 10 years of training, really no need to patronize. I'm really glad not only almighty Oracle admins can handle a database today
- mhd 12y agoRight, because we all know there's just a huge void between "put it in in some kind of form, we'll get it out somehow" an "let's tweak the undocumented redo log retention policy to eke out the necessary performance for our massively joined manifested view that mostly consist of analytical functions". It's "basic" as in your data being your foundation, not in rudimentary. And to be fair, most of the things that aim to replace SQL tend to be about as complicated. TANSTAAFL.
- ericingram 12y agoWe've been using TokuMX for a while and I highly recommend others take a serious look there. It already contains the benefits cited for MongoDB 3 and more. Toku also has a release candidate for the new Mongo storage engine API named TokuMXse, though it's interesting to see that TokuMX proper still outperforms it: http://www.tokutek.com/2015/01/first-tokumxse-performance-numbers/ http://www.tokutek.com/2015/01/first-tokumxse-performance-nu...
- nemo44x 12y agoProblem is where it is branched. I don't think they will be able to keep up well. Plus, the new MongoDB storage engine (wire tiger) takes care of its biggest issue which Toku addresses. Plus, I think you'll be able to just buy Toku's storage engine if you want it when they make it pluggable with the new MonogDB storage engine API.
- lesingerouge 12y agoSomebody at MongoDB must have read the early Oracle story. Start with one consumer niche (in mongo's case I think it's the common building-cms-based-websites web developer), improve the product, market ruthlessly. Granted, their product is not excellent and it has major flaws and lacks some common DB features, but they have the advantage of developer-ease-of-use and low barrier to use. I think this product is simply not yet "DONE".
- jimbokun 12y agoThe differences between mongodb.com and mongodb.org are striking. I was confused about why there was no links to documentation on the .com, until I stumbled onto the .org, which lists actual features right on the home page. Also striking: no mention of 3.0 on the .org home page at all, and on the downloads page, you have to scroll down to "Development Releases (unstable)" to find any reference to the 3.0 builds. https://www.mongodb.org/downloads https://www.mongodb.org/downloads Quite the split personality between the two sites.
- nemo44x 12y agoThe .com is the corporation behind MongoDB. .org is the open source project. Yes, they are intertwined heavily at this point (but it wasn't always this case back in the day) but I can understand why they try and keep their separation of concerns here.
- nevi-me 12y agoI'm excited to see 3.0, but from what I've seen on JIRA, there might still be some issues with WiredTiger (fair considering how they moved from RocksDB to WT in a short period). Will be interesting to see if they'll close out those issues before they drop 3.0 in March. A few months ago they closed up some of JIRA (comments and a bit epics/sprints), so some issues would be created and have no comments exposed. I thought they were working on transactions in this release (while they were still around 2.7.3 or so), but I guess that's not the case. Lastly, I wonder how this will impact TokuMX, both positively and negatively? Really whether they'll be making their crown improvements into a pluggable storage type/engine, and if users would be able to take that and plug it into Mongo without patent issues on their fractal tree indexing. Nonetheless, exciting news for some of us who are building on web-scale, MVCCABCD databases which operate at the speed of hype and web-scale :) EDIT: saw that Tokutek has created TokuMXse, only after my post
- iagooar 12y agoYou got your chance, Mongo, and you screwed it up. I tried getting the most out of you. I treated you like a princess, I indulged you, your wishes became my wishes and your thoughts were my thoughts. I stopped listening to all that criticism around you and thought of you as of a misunderstood child, even as you would refuse to do even the easiest tasks one could imagine. I gave you everything there is to give, but you broke my heart. You left me in the most critical moments. I trusted you, but you would go your own way. Tears were shed and countless sleepless nights were to follow. Remember that night you disappeared without leaving a sign? I sent you messages which got a response only after many hours. You didn't give a damn about my needs. One you told me: "it's not me, it's you". And I believed you, I truly did. It's over now. It's been some time without you, and I'm getting better. I have discovered, that not everyone is like you. Some DBs care, they really do. You can trust them, they give you their everything. I'm still struggling falling in love again, but it's getting better. Don't write me back. Goodbye.
- savanaly 12y agoI'm not up to speed on the reason for the MongoDB animosity, can anyone enlighten me?
- cordite 12y agoOne of Mongo's fatal problems is that the database has been known to say it has fulfilled its durability promises, but that's only sending a packet to the kernel, not confirmed received by others. Same with writing to disk. So a crash can lose more data than originally thought. Other things like continually pointing to each other, not figuring out a master for hours has made some people tear their hair out, despite the documentation saying it should behave in a sane way.
- tinco 12y agoMongoDB is a database with some properties that match a specific niche, but to gain popularity they marketed it as a general purpose database that anyone could use. The result is that many developers who bought into the hype train are now salty because they encountered the limitations at unexpected and unfortunate moments that might have cost them uptime or data.
- Kiro 12y agoAm I the only one using MongoDB who think it works great? I'm really happy with it.
- larsmak 12y agoYep, no problems here. 80GB dataset, indexes are around 10GB, one master, two replicas. Lots of reads, all writes are done in bulk during the night (low read throughput). We also use Cassandra and postgresql a lot - there's no silver bullet when it comes to storage systems.
- thijsc 12y agoWe're really happy with MongoDB too. Can't wait to see how these improvements will work out for us.
- 127001brewer 12y agoI have been developing with MongoDB for about the past year. (Briefly, I have developed, and continue to support, an ASP.NET MVC C# Web Application that's used by a few thousand people daily. For my personal projects that use MongoDB, I develop with PHP and Python.) Overall, I enjoy working with MongoDB, because it (generally) maps directly to your object - there is no need for an additional layer (such as an Object Relational Mapper (ORM)). However, you have to be more careful with your data structure. For example, having sub-arrays in sub-arrays is probably not a good idea. I will be happy to share more, so feel free to look up my profile.
- msandford 12y agoI ran a website and operations for a company that did over 1mm a year in revenue. Everything was done off of a single machine that was the webserver, database server and media server. Had 10k customers all of whom were active daily. Postgres and Python/Django and I never saw load averages much over 10%. Unless you have a substantial fraction of a million daily users you probably don't need mongo.
- 127001brewer 12y ago
- endijs 12y ago"MongoDB 3.0 will be generally available in March, when we finish putting it through its paces. Stay tuned for our latest release candidate, we would love it if you would try it out and give us feedback." So... no 3.0 final yet. That's disappointing. However - I'm really excited about 3.0. Initial tests show way better performance than 2.6. Plus data takes just 1/4th of disk space. That's amazing. I hope this is just beginning and each next release will add more and more features based on what WT can deliver.
- harel 12y agoOK, I'll provide a user's perspective as we are invested in Mongo as a storage system for statistical data and have been using it for a good few years now. MongoDb has been, so far, very good to us. I did not experience any of the problems people sometimes cry so very vocally about. My main concern about Mongo is actually one that is addressed by this release so I'm quite excited to try it out - data compression. Mongo is generally quite irresponsible about disk space usage. Yes disks are cheap but I rather not have a 2TB dataset if I can have half the size, thank you very much. As a side note, the hype from MongoDb the company equals the anti-hype you get on places like HN, so I guess they even out.
- functional_test 12y agoYou may also really like TokuMX. It has the same API as Mongo (even works with Mongo drivers) but way lower disk use, faster indices, and better query semantics (e.g. updates don't affect the cursor you're iterating right now). After using MongoDB for years (very happily too, I'm not one of the anti-Mongo crowd), I ended up switching and it's been great.
- harel 12y agoThanks for the tip. I'll be sure to check it out.
- jungleg 12y agoI'll add to what @harel says below. If it wasn't for MongoDB, my last company would have probably not survived. Sure, our usecase was very specific (very write-heavy app) but MongoDB delivered and still delivers without any problems. I think there can be usecases where MongoDB is not the best fit, but for wide number of applications, MongoDB is the perfect fit.
- disbelief 12y agoI'm actually surprised that MongoDB saved your write-heavy app. In my experience, it's Mongo's poor write throughput that causes the most headaches. This 3.0 release finally begins to address that with collection and document level concurrency control (locking).
- alexgaribay 12y agoCan some people who have used Mongo in production elaborate on their experiences where Mongo worked well or didn't work well? I see a lot of more hate than I do love for Mongo on HN and I'm curious why.
- disbelief 12y agoI've used Mongo in two large projects and have mixed feelings about it. Pros: It's great for building your MVP. Super easy to get up and running, super easy to work with at a superficial level (I'm talking about storing data and querying here more than ops and administration), dataset can grow to a fairly large size without you having to think about your database at all, freeing you to think about your business. Mongo was my first brush with "schemaless" and that's a big advantage particularly for early-stage projects where things are in flux. I also enjoy using JS as the query language, because I like JS, but YMMV. Also for certain use cases, particularly the single document case, it's probably one of the best solutions available. However, in my experience, this ends up being a limitation if your data doesn't fit nicely into a single document, and the types of data that do fit this use case are rare. The cons you've probably heard before: no transactions, no joins, not ACID compliant, until very recently writes locked the entire database, scaling/sharding just works until it doesn't.
- tim333 12y agoHaven't used it but you may find https://news.ycombinator.com/item?id=6712703 https://news.ycombinator.com/item?id=6712703 of interest
- weddpros 12y agoI find Mongodb works well (OLTP) when you use it as a powerful Key-Value store with secondary indices. You'll get easy replication/failover (rolling updates of the DB server are easy), ease of use (with node.js for example) and very decent performance... Good for an application where you need frequent access to a "row" except that row is complex, with subobjects, sets and arrays (in this use case, a relational model performs much worse because of joins) Not so good for an application where you need frequent access to lists of tabular data and list/details access (where relational models shine) Your mileage may vary. Some use it for logging, for analytics, for which I have no need or experience. GridFS also works very well (but I use nginx as a cache in front of it).
- fasteo 12y agoMongoDB seems to be a love/hate relation. I haven't used it myself, but I found this article[1] very useful. My conclusion is that MongoDB works, but you need to understand it and take some time to plan the deployment. [1] https://blog.serverdensity.com/does-everyone-hate-mongodb/ https://blog.serverdensity.com/does-everyone-hate-mongodb/
- james33 12y agoI feel like the vast majority of people that bash on MongoDB didn't fully understand it and what it was good for when they tried it. We've been using it in production for nearly 3 years in online games and have had nothing but good experiences with it. This 3.0 release will be yet another big step forward and we are excited to reap the continued benefits.
- nemo44x 12y agoThat's mainly correct. Or they used for it something it simply isn't suitable for. You can't just throw random data into it and expect it to work. Proper document modeling and understanding write concern solve almost all the problems people have with MongoDB. It still has a ways to go but so many of the comments here are issues from way back in v2.0. Regardless, it's still very popular and only gaining popularity. And improving.
- vkjv 12y agoAgreed. I've also been using it in production for years and the hate is often misguided. My issues are almost never with lack of features, but almost always with the cavalier attitude towards bugs, even catastrophic ones.
- gaius 12y agoBut the vendor told them it was a general purpose database...
- dcosson 12y ago> didn't fully understand it and what it was good for This is why I'm not a fan, its "sweet spot" , in my experience, is not very big and not very interesting. It requires a small data set where at least the indexes (but ideally the entire "working set") fits in memory on a single server, in which case it can get pretty good read throughput. But there are a lot of options that perform great in this use case, including just mysql or postgres. Maybe the flexibility of being schema-less is a win for some people, in which case great, I'm glad it's available as an option. But when the company claims things like it's the best database for every use case, people are bound to use it wrong, get burned, and then hate it. Where I used it it had been the exact wrong choice to make, a data set bigger than ~2x a single server's memory (and growing) and with relatively high write throughput, and it was an absolute nightmare.
- slantview 12y agoSo I heard this means it's webscale now?
- deleted 12y ago[deleted]
- astral303 12y agoComment threads like these help me learn how different the HN groupthink/prevailing thought is from the reality on the ground. In reality, MongoDB works well enough to be where they are, armed with the money they have.
- nemo44x 12y agoThat's the point so many here fail to address. Lots of businesses are using MongoDB at large scale (2PB clusters) and willing to talk about it too. MongoDB gets a bad rep, some of it their own fault for sure, but it's not as lousy as some people here make it out to be. Careful object modeling goes a long ways. Wired Tiger will be a massive improvement on their current storage engine, which is pretty awful for write-heavy loads to be sure.
- jedberg 12y agoDo they still value speed over durability? If so, thanks but no thanks. I prefer my database to be durable. If I want speed, I use RAM.
- nemo44x 12y agoYou've always been able to control this with write concern on a per-write basis. If you can handle an instance where and acknowledged write may not get replicated and possibly lost (logging use case - fast writes) then use that level of write concern. If you require extreme durability (slower writes but more durable) then use that level. In many applications you have both requirements and MongoDB lets you choose at write time the level of durability you want.
- jedberg 12y agoDoes version 3 fix the issue where the database lies to you and says the write was complete once it hits the network socket and doesn't wait for the ack? http://hackingdistributed.com/2013/01/29/mongo-ft/ http://hackingdistributed.com/2013/01/29/mongo-ft/
- nemo44x 12y agoHe was using v2.0 in that article. A version that is years old and pretty awful. The default then was that a write was fired from the client and that's it - fire and forget. A stupid default. The default since is to get an ack from the server. You can control this on each write and make it more durable (make sure it is replicated to 1, majority or all replicas) or faster (just get to the server). The default is to be written to the primary server and put into the transaction log so if it doesn't get committed to disk (possibly 60 seconds by default) it can recover. The transaction log is flushed (fsync) every 100ms by default and is configurable. You can also specify that the write is only acknowledged after the transaction log is synced. Anyways the default is it is put into the transaction log and then acknowledged.
- jedberg 12y ago
- cheald 12y agoI'm actually fairly interested in the WiredTiger integration. I switched from MongoDB to TokuMX about a year ago because of disk space and atomicity concerns, and Toku's been really good to me. Mongo 3.0 promises to catch up in many respects; if it does, then it might actually solve the vast majority of the complaints that people have historically had with it. The marketing copy still pretends that TokuMX doesn't exist, though - it's had these features and more (including transactions) for quite some time now.
- je42 12y agoAnybody knows how FoundationDB compares to MongoDB 3.0 ?
- nnain 12y agoSlightly off topic: I prepared this MongoDB Quick Reference Card last year; never put it online before. Hope it'll be useful to someone looking for a quick peek into how mongo db commands work - https://dl.dropboxusercontent.com/u/58502821/mongodb_qrc.pdf https://dl.dropboxusercontent.com/u/58502821/mongodb_qrc.pdf
- vkjv 12y agoAm I the only person that things the sheer number of people that have had scaling issues with mongo is a GOOD thing? I think it speaks to changing technology landscape and attitude towards data. Many more people are collecting and working on larger data sets than they would have ever dreamed of years ago. I credit MongoDB, in part, to allowing developers to do this and encourage them to try. Sure it has it's limitations and may not be as great in areas as other databases, but, wow have a lot of people tried and succeeded. tl;dr, If reverse survivor-ship bias is a thing, I think mongodb has it.
- tracker1 12y agoI've been pretty happy with mongodb overall for a few years now. It isn't always the best fit... but it's a very good fit for a lot of scenarios. Replication and sharding in mongodb is way easier to get started with than most databases, and the failover for replication is very good as well. Though understanding how it works is still advised. Such as not having more than X nodes voting for electing a leader in case of failover, etc. That said, there are situations I'd be more inclined to reach for ElasticSearch, Cassandra or others. As soon as RethinkDB has it's automatic failover story in place, I'd put it above MongoDB though, slightly nicer developer interface, and admin is much nicer than others. Then again, if PostgreSQL got replication with failover in the box, I'd probably use that far more.
- tankerdude 12y agoThe announcement, to me, was way over the top. There was so much noise in the announcement with very little in terms of signal. It reads almost like vaporware, even though it probably was not. Just give us facts, plain and simple. What it improves and how it improves it. When there are that many adjectives about the project, it just causes me to tune out a bit. Was this supposed to be part of a sales deck or something? (An as aside, I use mongo and know its pluses and minuses so reading all that hoopla is just unseemly.)
- vegabook 12y agoI'm writing 20000 financial ticks per second into Mongo on commodity hardware, namely a bog-standard i7 with 32 gig costing less than 2k. I don't have a big budget. I don't have a lot of time to mess with ACID. There is no way postgres will do this for under 10-20k, without twice the work. I just need to keep up with the firehose of data I get from my financial application. I'm talking about my own big-data issue and even if a few records were ever to get lost, I don't care, because that's what big data is about: statistical sampling. And that does not require 100% in 100% of cases safety of every data point. That by the way, is the truth of big data. Who cares if a few records theoretically can be lost? I just need to capture as much as possible as fast as possible. Mongo fits perfectly. Redis would work, but I'd need 512 gig of RAM..... I don't understand all the angst against this technology. If you need rollback-able transaction-guaranteed, exactly-once consistency, normalised schema with triggers left right and centre, you knew long ago that this wasn't the tech for you. Why is everyone so negative? I for one cannot wait to be able to store 4x more data on the same SSD, and using less RAM. In my view, Mongo is a massive enabling technology for startups on limited budget.