Homebrew removes MongoDB from core formulas • Hacker News Board

Re: Homebrew removes MongoDB from core formulas

#131

Post by farisjarrah » Tue, Sep 03, 2019, 1:25 AM UTC

nailer wrote: post #15

mikeryan wrote: post #9

Earlier quoted context omitted.

Over the last few Months we’ve switched over to amazons document db just to have a managed service. We don’t regret it.

DocumentDB is still really expensive as there's no pay what you use option. I stored about 2KB of data for 72 hours and got charged fifteen dollars before I realised the mistake. They really need to come up with a per mb per hour option.

Google Cloud's managed SQL seems to have an option where the instance spins down automagically when its not in use.

Re: Homebrew removes MongoDB from core formulas

#132

Post by Thorrez » Tue, Sep 03, 2019, 1:28 AM UTC

inimino wrote: post #114

Thorrez wrote: post #28

Earlier quoted context omitted.

What you do mean by the "mongoDB trap"? Are you saying companies are hurt by the license, or are you saying companies are hurt by software's behavior (e.g. consistency model)?

Why can't it be both?

I guess it could be both, but I consider them to be two completely separate issues, and referring to them together as "the mongoDB trap" without any further clarification is quite confusing to me. It could easily lead to misunderstanding, and people "answering" the question with only partial answers.

Additionally I'm curious how the license is harming companies, as I mentioned in this comment: https://news.ycombinator.com/item?id=20862996

Re: Homebrew removes MongoDB from core formulas

#133

Post by luizfelberti » Tue, Sep 03, 2019, 1:29 AM UTC

craigching wrote: post #101

A lot of people advocate PostgreSQL as a replacement. Why not elasticsearch? It’s also a document store with a good history. At a previous job I shipped Mongo as the store (under AGPL) because at the time the replication story for PGSQL was too complex compared to mongo. But I reached a point where I was going to replace Mongo with elasticsearch and get rid of Solr at the same time.

I would strongly advise against this.

For a long time, the only reason ElasticSearch was not the ugly duckling of distributed systems was because MongoDB existed. It does not have a good history at all. There was a time that Elastic even claimed that it beat the CAP theorem, which always makes me chuckle when I'm reminded of it, and historically they also have been quite vague about the distributed properties (and shortcomings) of ES.

It works fine as a secondary datastore when you would benefit from all of the implemented search functions, but I wouldn't trust it for consistency (so I guess in a way it is a replacement for mongo \s)

Not only that but having operated ES clusters before, it's a tricky thing to manage, and depending on your workload they can be very resource hungry.

PostgreSQL is very solid though, and will scale well for the majority of people. I highly recommend this over ES, not to mention it does have some search features too, you should check them out.

Re: Homebrew removes MongoDB from core formulas

#134

Post by Thorrez » Tue, Sep 03, 2019, 1:36 AM UTC

marknadal wrote: post #84

Thorrez wrote: post #28

Earlier quoted context omitted.

What you do mean by the "mongoDB trap"? Are you saying companies are hurt by the license, or are you saying companies are hurt by software's behavior (e.g. consistency model)?

I used to build drivers for MongoDB because it was so easy. MongoDB had a good run, I enjoyed it before migrating away. This license definitely hurts companies. What to? I built my own Open Source solution (MIT/Zlib/Apache2). Around same time Firebase was getting popular, and Graph databases were the way forward. Combined them all together, now have Internet Archive and HackerNoon running it ( https://github.com/amar…

So you're saying MongoDB is good software, but not quite as good as yours. And you're saying the license is bad. Did you migrate away before or after the license change?

Could you elaborate on how companies are hurt by the license?

Re: Homebrew removes MongoDB from core formulas

#135

Post by pseudalopex » Tue, Sep 03, 2019, 1:44 AM UTC

chrisseaton wrote: post #80

gwd wrote: post #72

Earlier quoted context omitted.

While ESR's link establishes precedence, it doesn't actually tell me what it means in an intelligence context. From Wikipedia [1]: > Open-source intelligence (OSINT) is data collected from publicly available sources to be used in an intelligence context. IOW, the "source" in "open-source context" isn't actually talking about "source" as in "source code", but "source" as in "source of information". Not really related.…

> IOW, the "source" in "open-source context" isn't actually talking about "source" as in "source code", but "source" as in "source of information". Not really related. ESR says specifically that it's related - he says the relation is a 'feature' of the name, even.

Some features start as happy accidents.

ESR was the president of the OSI when it published the Open Source Definition and applied for the trademark. Justifying a weaker definition can’t be why he called it a feature.

Re: Homebrew removes MongoDB from core formulas

#136

Post by mbreese » Tue, Sep 03, 2019, 1:46 AM UTC

nevi-me wrote: post #118

threeseed wrote: post #98

Earlier quoted context omitted.

I work in the enterprise and we spend tens of millions a year with AWS. Our Security, Cloud Engineering and Finance teams understand VPC, IAM, Costs etc back to front and so when you add a new AWS product they know how to manage, secure, finance and support it. And of course there is no Procurement process with adding a new AWS product. With a managed MongoDB (even though it's on AWS) you need to get buy in from doze…

This still doesn't sound like a good reason to pay AWS instead of MongoDB. Didn't your Security, Cloud Engineering and Finance teams have no understanding of AWS at some point? Why can't they start to 'understand' how a managed MongoDB works, and give buy-in? There's a common saying we have in our consulting circles, that "Processes should support business, but business decisions shouldn't be made because of lack of…

If your choice is between (1) get MongoDB support from AWS and (2) get MongoDB support direct from MongoDB, the fact that Security, Cloud engineering and Finance know AWS and how to work in their environment seems to be the obvious choice. The difference between (1) and (2) is probably minimal enough to make the existing relationship with AWS meaningful. I don’t know enough about the costs of the two, but it’s possible that the incremental cost for adding it to AWS was cheaper.

Re: Homebrew removes MongoDB from core formulas

#137

Post by nevi-me » Tue, Sep 03, 2019, 1:48 AM UTC

mbreese wrote: post #136

nevi-me wrote: post #118

Earlier quoted context omitted.

This still doesn't sound like a good reason to pay AWS instead of MongoDB. Didn't your Security, Cloud Engineering and Finance teams have no understanding of AWS at some point? Why can't they start to 'understand' how a managed MongoDB works, and give buy-in? There's a common saying we have in our consulting circles, that "Processes should support business, but business decisions shouldn't be made because of lack of…

If your choice is between (1) get MongoDB support from AWS and (2) get MongoDB support direct from MongoDB, the fact that Security, Cloud engineering and Finance know AWS and how to work in their environment seems to be the obvious choice. The difference between (1) and (2) is probably minimal enough to make the existing relationship with AWS meaningful. I don’t know enough about the costs of the two, but it’s possib…

My point is that those support functions' lack of understanding of realms outside of AWS shouldn't be the sole motivator for not using a technology.

What happens if a company that uses Software A has good motivation to use B, but their support functions don't understand B? Aren't the support functions supposed to improve by seeking to understand B, even at the initial inconvenience of time and resources?

Re: Homebrew removes MongoDB from core formulas

#138

Post by jaequery » Tue, Sep 03, 2019, 1:52 AM UTC

scarface74 wrote: post #125

eloff wrote: post #121

Earlier quoted context omitted.

I worked on a project with similar requirements. I just serialized the data with protobufs, encrypted it, and stashed it in S3. It was sensitive data so this also had the advantage of being easy to secure and audit. No point using a relational db for that kind of thing.

And then when you need to do reports on the data and query it?

Why not just use Postgres, set a field as jsonb, done?

Re: Homebrew removes MongoDB from core formulas

#139

Post by craigching » Tue, Sep 03, 2019, 2:02 AM UTC

luizfelberti wrote: post #133

craigching wrote: post #101

A lot of people advocate PostgreSQL as a replacement. Why not elasticsearch? It’s also a document store with a good history. At a previous job I shipped Mongo as the store (under AGPL) because at the time the replication story for PGSQL was too complex compared to mongo. But I reached a point where I was going to replace Mongo with elasticsearch and get rid of Solr at the same time.

I would strongly advise against this. For a long time, the only reason ElasticSearch was not the ugly duckling of distributed systems was because MongoDB existed. It does not have a good history at all. There was a time that Elastic even claimed that it beat the CAP theorem, which always makes me chuckle when I'm reminded of it, and historically they also have been quite vague about the distributed properties (and sh…

Depends on the version of elasticsearch you’re running and the use-case. If you’re running a single index with a well-defined schema, I think elasticsearch works very well. If you need many indices and can’t have a defined scheme, then it can be tough.

I work on a team at Target that provides a log aggregation product and we’re finding that a single index with a well-defined schema used to troubleshoot applications via logs is very easy to manage and scale. We support some legacy patterns like “index per application” that are a pain in the ass to manage.

Just to provide some context, we manage about 40 clusters that range from a few data nodes to about 160 data nodes with the majority falling in the 16-60 node ballpark. We don’t have a problem with data loss due to elasticsearch, generally speaking.

Re: Homebrew removes MongoDB from core formulas

#140

Post by mbreese » Tue, Sep 03, 2019, 2:03 AM UTC

nevi-me wrote: post #137

mbreese wrote: post #136

Earlier quoted context omitted.

If your choice is between (1) get MongoDB support from AWS and (2) get MongoDB support direct from MongoDB, the fact that Security, Cloud engineering and Finance know AWS and how to work in their environment seems to be the obvious choice. The difference between (1) and (2) is probably minimal enough to make the existing relationship with AWS meaningful. I don’t know enough about the costs of the two, but it’s possib…

My point is that those support functions' lack of understanding of realms outside of AWS shouldn't be the sole motivator for not using a technology. What happens if a company that uses Software A has good motivation to use B, but their support functions don't understand B? Aren't the support functions supposed to improve by seeking to understand B, even at the initial inconvenience of time and resources?

I certainly don’t disagree with you on principle. It’s just a bad example in this specific case because A is roughly equivalent to B in this case.

Also, Amazon doesn’t have the same reputation as Google for killing products, so it’s a pretty safe bet. And AWS will be around for quite a long time. The financial stability of MongoDB (the company) isn’t as guaranteed.

Maybe the parent’s company’s processes did work in this case.