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

121–130 of 165 posts

Re: MongoDB 3.4.0-rc3

#121

Post by hendzen »

geocar wrote: post #106
radicalbyte wrote: post #98

Earlier quoted context omitted.

It depends. Given a small cluster of reliable nodes on a reliable network, these errors will occur extremely rarely. So rarely, in fact, that they'll be written off as "user error" by support. If you're a startup building a system which has to quickly and reliably scale from 3 > 3000 nodes in a year then the whole thing is likely to explode in your face. Twitter style. Now, if MongoDB was so superior that it was trul…

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 10 TB or less) numerical time series data. It would be a horrible choice for the backing store of a high throughput CRUD application...

What is it with KDB zealots thinking that KDB is the best database for every task? I swear, KDB is the Scientology of databases.

Re: MongoDB 3.4.0-rc3

#122

Post by vacri »

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…

> I'd seriously question the judgement of any senior engineer who picks it for a new project over rethinkdb or Postgres.

... you mean RethinkDB, whose future is still uncertain? Regardless of technical merits, the currently unstable future of RethinkDB means a senior engineer should be extremely cautious about selecting it for a significant project.

Re: MongoDB 3.4.0-rc3

#123

Post by cies »

Kiro wrote: post #104
always_good wrote: post #91

Earlier quoted context omitted.

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

Some of us are already using MongoDB and are not so keen on replacing it.

If you read back the discussion was scoped to "new projects". By jospehg:

> I'd seriously question the judgement of any senior engineer who picks it for a new project over rethinkdb or Postgres.

Re: MongoDB 3.4.0-rc3

#124

Post by mabn »

digitalzombie wrote: post #43
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…

> Can you give an example of another option you are referring to? That depends on the data. What type of data you have and what you want to do with it. MongoDB isn't data specific and it claim to fame is flexible data structure. If you want fast write and look up with very little relation Cassandra is good. If you want searchable text document then anything that is base on Lucene is good (ES, Solr, Raven). If you wan…

What if I want filtering by several criteria (on a table with 1k columns) and simple aggregations, but I don't need full-text search* ? I'm still looking :(

* I only want starts-with and contains on strings.

Re: MongoDB 3.4.0-rc3

#125

Post by vacri »

k33n wrote: post #78
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?

> 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 going to blow your socks off, but one where saying "OMG I hate it!" somehow signals membership to some cool clique of connoisseurs.

Re: MongoDB 3.4.0-rc3

#126

Post by ClayFerguson »

squeaky-clean wrote: post #105
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…

> Also think of the power that would be available if there were some relational table capability (true real MySQL ACID) right inside MongoDB whenever it was needed, if they were the 'same animal', rather than having to use two totally and completely separate DBs Just use Postgres (or several other options) then? It has all that built right in if it's what you need. But... > if you need NoSQL and also ACID in an app,…

I don't know Postgres, and I just consider MySQL to be the leading best-in-class open source DB engine available. I realize that's debatable. But personally my mind is made up on that.

I think relational-type queries are so common that any significant app will need them. For my own side project (meta64.com) I'm using JCR-SQL2, on Apache Oak jackrabbit, so I get to do lookups fairly easily, but it sure would be nice to have a full-blown ACID RDBMS engine sitting right there to use also, in the same engine.

Re: MongoDB 3.4.0-rc3

#127

Post by zzzcpan »

vacri wrote: post #122
josephg wrote: post #56

Earlier quoted context omitted.

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…

> I'd seriously question the judgement of any senior engineer who picks it for a new project over rethinkdb or Postgres. ... you mean RethinkDB, whose future is still uncertain? Regardless of technical merits, the currently unstable future of RethinkDB means a senior engineer should be extremely cautious about selecting it for a significant project.

To be fair, choosing a scalable database even for a senior engineer still requires quite a bit of very specialized knowledge in distributed systems that most simply don't have. So they have to rely on what "feels right" anyway, rather than making an engineering decision, and are very susceptible to all the marketing and PR and authoritative opinions. There are no right choices for them. Although if in doubt everyone should probably default to a dynamo-style db, as it forces you to think about and organize your data in a certain future-proof way, which actually excludes all of the mentioned databases.

Re: MongoDB 3.4.0-rc3

#128

Post by ClayFerguson »

aphyr wrote: post #102
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…

What does MongoDB bring that couldn't have 'built on top' of MySQL codebase, and used MySQL transational layer as it's underpinnings. There are two challenges here. One is that MongoDB has a different data model than MySQL: hierarchical, schema-less documents instead of uniformly-typed flat tables. It's possible to map one to the other--look at Postgres' support for JSON datatypes. That involves extensions to both th…

The point is that MongoDB writes/reads directly to File system. It could have been (and still could be retro-fitted) to ride on top of an RDBMS for all it's actual IO, and create a hybrid. I'm aware of all the orthogonal points you raised which have nothing to do with ruling out RDBMS as I/O

Re: MongoDB 3.4.0-rc3

#129

Post by bborud »

tbrock wrote: post #12

MongoDB receives a fair amount of criticism here but the company is a fantastic place to work. I'm proud that I was able to learn and grow as a developer alongside all of those who have been trying (and succeeding) to make a great database. The team at MongoDB really cares a lot about making the best database product possible. I knew it when I was there and still think so after I've left.

Too bad that care didn't make it into the product.

Re: MongoDB 3.4.0-rc3

#130

Post by x0x0 »

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…

Well, I'm a member of the MongoDB is worth quitting over club. I replaced it at a former employer with postgres. Eng waved bye to an endless stream of operational issues, and customers saw better uptimes and much much faster responses.
Post reply on HN