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

We saved $50k/year with a Go microservice coded in a hackathon

movio.co

Post reply on HN
Print view View original

241–250 of 264 posts

Re: We saved $50k/year with a Go microservice coded in a hackathon

#241

Post by paulryanrogers »

Thaxll wrote: post #210
dijit wrote: post #122

Earlier quoted context omitted.

I disagree with your assertion that MySQL /is/ a serious database. The questions I usually ask myself when evaluating database solutions is: * Does it accept invalid data? * Does it change data on error? * Does the query planner change drastically between minor versions? * How strong is transaction isolation? can I create constraints, columns or tables in a transaction? * Does it scale vertically above 40~ CPU thread…

All this list is fud. You should provide examples to those claims because right now you sound like someone that never use MySQL.

Not the OP but one example of accepting invalid data is Mysql defaulting values to null/0/0000-00-00 when no value assigned and no default on column. Unless one is in strict mode.

Re: We saved $50k/year with a Go microservice coded in a hackathon

#242

Post by paulryanrogers »

e12e wrote: post #240
dijit wrote: post #229

Earlier quoted context omitted.

I appreciate that it might sound like that to someone who hasn't used MySQL in production for 10+ years. To start with, this is still true today: https://vimeo.com/43536445 Despite being 6 years old, strict mode is still required. Anything prior to MySQL 5.7 will accept "0000-00-00 00:00:00" as a valid date, 5.7 will not (which is sane) however this means migrating from 5.6 -> 5.7 just got a little harder. In fact it…

> will accept "0000-00-00 00:00:00" Isn't it? I thought that today()-(2018 years, 4 months and 10 days) would be approximately that date? Maybe you prefer +0000 vs just 0000? 'ISO 8601 prescribes, as a minimum, a four-digit year [YYYY] to avoid the year 2000 problem. It therefore represents years from 0000 to 9999, year 0000 being equal to 1 BC and all others AD. However, years prior to 1583 are not automatically all…

Technically true but still 0 is not yet a month or day of the month, so 0000-00-00 is still bad data

Re: We saved $50k/year with a Go microservice coded in a hackathon

#243

Post by hippich »

rbranson wrote: post #65
hippich wrote: post #14

What else it shows - how expensive AWS hardware vs hosting own hardware. I guess you have to consider how often you have to scale, but hetzner offers dedicated servers with 64Gb and NVMe drives starting from 54 euros per month - https://www.hetzner.com/dedicated-rootserver?country=us - compare that to $580 per month these guys were paying for i3.2xlarge instance..

... and then you have to clone all the AWS services yourself. If you just need a few boxes, there are definitely cheaper options than AWS.

Well.. It depends on what you are doing. If indeed you are using majority of AWS services, then yeah, getting off these will be hard to impossible.

But if all you use is RDS, EC2 and S3 - it is quite easy to move to dedicated hardware once your service is up and running on AWS. Unless your load is not jumping around 10x all the time of course (then you will need dynamic scaling which is not quite possible with dedicated hardware)

Re: We saved $50k/year with a Go microservice coded in a hackathon

#244

Post by dijit »

otterley wrote: post #237
dijit wrote: post #230

Earlier quoted context omitted.

If it costs development time because they need to be extra careful about not sending queries that ERROR and 'wipe' data. If it silently corrupts data over years and gets discovered much later. (As was the case with my previous company, an e-commerce retailer that lost large chunks of order history)

Are those problems still unresolved in MySQL today? How do you know that similar or worse problems did not exist in alternative solutions at the time it was implemented?

MySQL is making strides to fix these kinds of issues ever since the Oracle acquisition for sure.

> How do you know that similar or worse problems did not exist in alternative solutions at the time it was implemented?

Because I've been working on database solutions for over 10 years, there are problems in other software but I consider data loss to be worse than any of them. For example the autovacuum in postgresql 8.3 and before was mostly garbage which ended up bloating highly transactional databases. But deleting data when you fail a constraint is worse.

Re: We saved $50k/year with a Go microservice coded in a hackathon

#245

Post by dijit »

e12e wrote: post #240
dijit wrote: post #229

Earlier quoted context omitted.

I appreciate that it might sound like that to someone who hasn't used MySQL in production for 10+ years. To start with, this is still true today: https://vimeo.com/43536445 Despite being 6 years old, strict mode is still required. Anything prior to MySQL 5.7 will accept "0000-00-00 00:00:00" as a valid date, 5.7 will not (which is sane) however this means migrating from 5.6 -> 5.7 just got a little harder. In fact it…

> will accept "0000-00-00 00:00:00" Isn't it? I thought that today()-(2018 years, 4 months and 10 days) would be approximately that date? Maybe you prefer +0000 vs just 0000? 'ISO 8601 prescribes, as a minimum, a four-digit year [YYYY] to avoid the year 2000 problem. It therefore represents years from 0000 to 9999, year 0000 being equal to 1 BC and all others AD. However, years prior to 1583 are not automatically all…

MSSQL/Oracle/PostgreSQL/firebird all accept 0000-01-01 which is a valid date.

Re: We saved $50k/year with a Go microservice coded in a hackathon

#246

Post by eeZah7Ux »

zimpenfish wrote: post #166
quest88 wrote: post #87

Earlier quoted context omitted.

Why isn't MySQL serious? It has powered many popular sites.

> Why isn't MySQL serious? It has powered many popular sites. As has PHP. "popularity" isn't really evidence for it being a "serious" tool, is it?

Why the downvotes? Popularity != quality.

Re: We saved $50k/year with a Go microservice coded in a hackathon

#248

Post by dbrgn »

stu432 wrote: post #151
dbrgn wrote: post #117

Earlier quoted context omitted.

Sounds like a great case for Postgres hstore (like OpenStreetMap does it)?

I mean, not really, theres no magic in Postgres' implementation of the pattern. They even spell it out for you: "can be useful in various scenarios, such as rows with many attributes that are rarely examined" They are querying these quite heavily, they aren't just random attributes they need to retrieve.

You're right, I think most OSM databases extract the most commonly used keys into dedicated, potentially indexed columns.

Re: We saved $50k/year with a Go microservice coded in a hackathon

#249

Post by maddiez »

colde wrote: post #141
indigochill wrote: post #125

Earlier quoted context omitted.

Well, a problem in tech certainly. An alternative possibility (and another problem in tech) could be some mid-level developer could have figured out the problem at the start but because of artificial time pressure to deliver they didn't have the time to, so went with the first bad idea that popped into their head without taking the necessary time to evaluate it. The fact this had to happen in a hackathon suggests a t…

It is worth noting that on their website, their management team doesn't include a CTO, even though their main product is basically a software solution. They have a few sales people represented though, so management might not be great techwise.

CTO has moved to another company with not so shiny tech stack, as far as I know they were the main adopter of Go and other solutions to replace Java and then Scala. Perhaps Movio did not yet find the best fit for the company.
Post reply on HN