Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MongoDB 3.4.0-rc3

jepsen.io

Post reply on HN
Print view View original

131–140 of 165 posts

Re: MongoDB 3.4.0-rc3

#131

Post by ClayFerguson »

hmottestad wrote: post #101
ClayFerguson wrote: post #99

These 'from the ground up' totally all-new-code approaches to DBs are just a scary proposition. Think of the thousands of man-years of effort that went into building MySQL, testing its codebase, and perfecting it's robustness (fail-proof-ness). What does MongoDB bring that couldn't have 'built on top' of MySQL codebase, and used MySQL transational layer as it's underpinnings. Sure, MongoDB gets all its performance ga…

Probably because there has been a lot of development in distributed databases in the last few years. Raft is fairly new, for one. Taking really old code and trying to make it do new things is very very hard. After you've invested all that time and effort making mysql better, it's still a database owned by oracle. Think how Java would have turned out if Sun made it to be cross compiled to C rather than run in a VM.

I haven't seen the codebase of MySQL, but it's open source and not "owned" by Oracle. The only reason anyone should want to start over is if that codebase itself was crappy code. I bet it isn't. Implementations of a robust RDBMS takes decades. MySQL is very mature. That doesn't act against it, it acts in favor of it. The better analogy is Linux. I'd be more likely to say "Linux is bad because of age" long before I'd ever say "MySQL is bad only due to age."

There are plenty of examples in the Language world also: Go, Rust, etc. All those new languages SHOULD have built on top of Java, for the same reason Mongo should have built on top of MySQL. BTW, Java DID leverage C++. The Java compiler IS written in C. Mongo didn't use any part of MySQL, but Java uses EVERY part of C.

Re: MongoDB 3.4.0-rc3

#132

Post by bogomipz »

josephg wrote: post #56
BillFinchDba wrote: post #36

Earlier quoted context omitted.

I think if you look back objectively, there are very few database platforms that were absolutely "fit for public consumption" right out of the box. Look at all the SQL Server shops out there (mine included) that won't even roll out a new version of SQL Server until it hits SP 1 at a minimum... For MongoDB, If you look forward based on what they are doing now rather than at how early adopters may have had a sub-optima…

Right out of the box? Mongodb has been trying to get it right for 10 years now. Kyle says the storage engine they've used for most of that lifetime is fundamentally flawed, and they've only now, a decade on, managed to write something without known bugs to replace it. And maybe this time it's ok. Maybe this time there aren't any more layers of buggy crap in mongo yet to be found and fixed. Maybe. But you'd have lost…

>"Kyle says the storage engine they've used for most of that lifetime is fundamentally flawed, and they've only now, a decade on, managed to write something without known bugs to replace it"

Didn't WiredTiger Inc write the new WiredTiger storage engine before they were acquired by MongoDB Inc?

https://gigaom.com/2014/12/16/mongodb-snaps-up-wiredtiger-as...

Re: MongoDB 3.4.0-rc3

#133

Post by davidbanham »

ClayFerguson wrote: post #131
hmottestad wrote: post #101

Earlier quoted context omitted.

Probably because there has been a lot of development in distributed databases in the last few years. Raft is fairly new, for one. Taking really old code and trying to make it do new things is very very hard. After you've invested all that time and effort making mysql better, it's still a database owned by oracle. Think how Java would have turned out if Sun made it to be cross compiled to C rather than run in a VM.

I haven't seen the codebase of MySQL, but it's open source and not "owned" by Oracle. The only reason anyone should want to start over is if that codebase itself was crappy code. I bet it isn't. Implementations of a robust RDBMS takes decades. MySQL is very mature. That doesn't act against it, it acts in favor of it. The better analogy is Linux. I'd be more likely to say "Linux is bad because of age" long before I'd…

Build Rust on top of the JVM? Buddy, you're a long way out to sea on that one.

Re: MongoDB 3.4.0-rc3

#134

Post by jgord »

vacri wrote: post #125
k33n wrote: post #78

Earlier quoted context omitted.

> Its not like competent teams were using it in production. Right? I've heard that about 1000 times a day for 6 years. Usually the person stating it is snickering as if they are clued into some unknown secret. Mongo does work in production at many shops, and in many forms. Sometimes it's used as the main database, sometimes it's used to house specific slices of data, etc.

As a sysadmin, I got tired of the devs constantly ragging on Mongodb (the same folks that selected it before I was hired). I eventually got fed up and said: "why do we use it if you all hate it so much. Let's replace it. What do you want to use instead, it's easy for me to set up something new". Cue everyone going "ah, it's not so bad, really..." MongoDB is the Nickelback of databases: a reasonable act that's not goi…

alternative anecdota : I rewrote a backend that was using mongo, moved it to postgresql+postgis. Solved an ever-expanding RAM issue and is still blindingly fast [ on SSD hosting ]

The main win was not server stability, it was having general tools to manage data .. including the inbuilt geo-algorithms that come with postGIS. eg. I could make our data set 9x smaller by smoothing map paths.

I still love the Mongo api, but I just cant risk it with data on projects that people are paying for, or that I need to support.

[ I think the real sweet spot will be deep integration of javascript and json into postgres - so I can write stored procs in js, get db events in js, wrangle json fluidly.. all of which is improving. ]

Re: MongoDB 3.4.0-rc3

#135

Post by ClayFerguson »

davidbanham wrote: post #133
ClayFerguson wrote: post #131

Earlier quoted context omitted.

I haven't seen the codebase of MySQL, but it's open source and not "owned" by Oracle. The only reason anyone should want to start over is if that codebase itself was crappy code. I bet it isn't. Implementations of a robust RDBMS takes decades. MySQL is very mature. That doesn't act against it, it acts in favor of it. The better analogy is Linux. I'd be more likely to say "Linux is bad because of age" long before I'd…

Build Rust on top of the JVM? Buddy, you're a long way out to sea on that one.

Yeah, you are taking that sentence too literally. What I mean is we don't need a new language created every week. Java is already perfectly fine, and IF somebody finds something Java can't do, they shouldn't start from scratch and create a new language, but instead build and improve on what already exists: Java. It's like you can either stand on the shoulders of giants or you can start out at dirt level. I don't like starting back in the dirt. Not to mention the fact that every time somebody reinvents an already existing wheel, they just fragment the industry, because half the script-kiddies out there (not knowing any better) will simply jump on the bandwagon of whatever language most recently went viral. The Sisyphus approach to technological advancement.

Re: MongoDB 3.4.0-rc3

#136

Post by keithnz »

hendzen wrote: post #51
ralfn wrote: post #46

Earlier quoted context omitted.

Not the OP, but RethinkDB is superior in many ways including stability, integrity and the feature set for pretty much every use case you would consider using MongoDB. But with Jespen tests MongoDB can finally be considered a contender. Its not like competent teams were using it in production. Right?

Do you not consider Stripe to be a competent team? Please, name some F500 companies using RethinkDB to power critical infrastructure. There are many using MongoDB. While Rethink is widely renowned among the HN set it is nonexistent in comparison when looking at actual deployments. The reigning HN view of MongoDB being a buggy mess is outdated. Yes, they overmarketed a buggy project in 2009. It didn't matter, because…

as an aside, Stripe are putting money in to support RethinkDB

Re: MongoDB 3.4.0-rc3

#137

Post by vacri »

jgord wrote: post #134
vacri wrote: post #125

Earlier quoted context omitted.

As a sysadmin, I got tired of the devs constantly ragging on Mongodb (the same folks that selected it before I was hired). I eventually got fed up and said: "why do we use it if you all hate it so much. Let's replace it. What do you want to use instead, it's easy for me to set up something new". Cue everyone going "ah, it's not so bad, really..." MongoDB is the Nickelback of databases: a reasonable act that's not goi…

alternative anecdota : I rewrote a backend that was using mongo, moved it to postgresql+postgis. Solved an ever-expanding RAM issue and is still blindingly fast [ on SSD hosting ] The main win was not server stability, it was having general tools to manage data .. including the inbuilt geo-algorithms that come with postGIS. eg. I could make our data set 9x smaller by smoothing map paths. I still love the Mongo api, b…

One day postgres will be everywhere :)

Re: MongoDB 3.4.0-rc3

#138

Post by gd1 »

hendzen wrote: post #121
geocar wrote: post #106

Earlier quoted context omitted.

Fantastic market strategy, but it's still snake oil they're selling. When you talk about growing, the biggest value in Open Source has been that you can start with something free but shit, and then as you make money then you can spend it on customizing that Open Source in a way that benefits you. However there exist commercial offerings that are (and were) faster and better at MongoDB than MongoDB was: KDB could've h…

I have some actual experience with KDB and MongoDB so I'm going to have to call bullshit. How does KDB handle replication and failover? Or even high insert/update rates to datasets that exceed the size of memory? How do you shard KDB? KDB doesn't support unicode text. Do you plan to only have English speaking users? Yes, KDB excels at its relatively well defined niche of transforming and aggregating "smallish" (say 1…

>KDB doesn't support unicode text.

Unicode (from 2011):

http://code.kx.com/wiki/Cookbook/Unicode

Re: MongoDB 3.4.0-rc3

#139

Post by laichzeit0 »

always_good wrote: post #91
laichzeit0 wrote: post #73

Earlier quoted context omitted.

Do you think MongoDB is a good choice (given how easy it is to use) when you only care that 99.999% of your data that you insert should end up in the database? That's my use case. Best-effort integrity. I mostly just want a DB can insert and query fast for documents and am not really concerned if I lose a few documents here and there.

Why wouldn't you just use anything else that can manage to insert/read data without losing it? I don't really understand the angle of "can I get away with it anyways, tho?"

It's about making tradeoffs. If MongoDB works for you (I actually enjoy using it tremendously) then I have to ask myself am I ok with its non-perfect integrity. For my use cases this isn't a problem. I'm not working with customer data or anything where losing a few records would make any difference at all.
Post reply on HN