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

91–100 of 264 posts

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

#91

Post by davidp »

attaboyjon wrote: post #78

I've come to the conclusion that the problem in tech is that all the people doing the work are in their early twenties and have no idea what they are doing. Once they get some experience they are quickly promoted to the CTO position. Rinse and repeat. What we have here is a classic dbms problem and no one at Movio seems to know how to deal with that. Instead of migrating from Mysql to something serious (Postgres) the…

I like to trot out this old gem[1] when people wonder why there's so much hate for MySQL.

Nontransactional DDL alone is sufficient to classify it as a toy DB for me. Yes, I've been personally bitten by it.

[1]: https://grimoire.ca/mysql/choose-something-else

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

#92

Post by ajcodez »

candiodari wrote: post #72
any626 wrote: post #29

Earlier quoted context omitted.

The user data is most likely in rows instead of columns. Instead of having id, name, age, gender 1213, fake, 60, female they would have property_id, user_id, value 1 (assume age), 1213, 60 2 (gender), 1213, female This gives them the freedom to add more properties to the user without always having to add a column to the users table. When querying the database you'll have to do unions or joins.

> This gives them the freedom to add more properties to the user without always having to add a column to the users table. When querying the database you'll have to do unions or joins. I think you're right. Oh ... my ... god ... I wish I could say this is the worst example of a database schema I've ever seen, but it isn't. Technology cycle: X gets invented -> idiots abuse it -> X "is bad" -> Y (strictly worse than X)…

It makes sense if each client gets to add their own fields.

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

#93

Post by attaboyjon »

peburrows wrote: post #89
attaboyjon wrote: post #78

I've come to the conclusion that the problem in tech is that all the people doing the work are in their early twenties and have no idea what they are doing. Once they get some experience they are quickly promoted to the CTO position. Rinse and repeat. What we have here is a classic dbms problem and no one at Movio seems to know how to deal with that. Instead of migrating from Mysql to something serious (Postgres) the…

Overall, I agree with the sentiment of your comment, but the assertion that MySQL isn’t a serious database is just flat out wrong.

You're right. I started using mysql in 2000 when it was still a toy. It's an outdated bias :) I was more flabergastered they would choose 'InifiniDB' when there are so many other great options out there.

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

#94

Post by icebraining »

matte_black wrote: post #77
nstart wrote: post #69

Earlier quoted context omitted.

Oh gosh this pattern. The first time I encountered it was in my first job where we used Magento. Super flexible. Also super slow. Does anyone have any advice how to make a db design like this work faster? Generally I thought when data is arranged like this it might be a prime candidate for document based storage. But I'm no dba so I have no idea if that would be correct.

If you are using Postgres, the JSONB datatype will let you do exactly this while still using the full power of SQL. Simply create a column where you keep a JSON object full of random user properties, if flexibility is what you want. You can even index properties.

The question is whether it can be stored like this while allowing for fast queries. For example, unless it changed recently, Postgres doesn't calculate statistics to help the query planner on jsonb fields.

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

#95

Post by cdubzzz »

davidp wrote: post #91
attaboyjon wrote: post #78

I've come to the conclusion that the problem in tech is that all the people doing the work are in their early twenties and have no idea what they are doing. Once they get some experience they are quickly promoted to the CTO position. Rinse and repeat. What we have here is a classic dbms problem and no one at Movio seems to know how to deal with that. Instead of migrating from Mysql to something serious (Postgres) the…

I like to trot out this old gem[1] when people wonder why there's so much hate for MySQL. Nontransactional DDL alone is sufficient to classify it as a toy DB for me. Yes, I've been personally bitten by it. [1]: https://grimoire.ca/mysql/choose-something-else

This talks a lot about 5.5 and mentions that 5.6 is “due out soon”. The current release series is 5.7. How much of this is outdated and how much has stayed the same?

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

#96

Post by attaboyjon »

quest88 wrote: post #87
attaboyjon wrote: post #78

I've come to the conclusion that the problem in tech is that all the people doing the work are in their early twenties and have no idea what they are doing. Once they get some experience they are quickly promoted to the CTO position. Rinse and repeat. What we have here is a classic dbms problem and no one at Movio seems to know how to deal with that. Instead of migrating from Mysql to something serious (Postgres) the…

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

You are right. It is a solid DB. I was more pointing out that if you have to move off Mysql, there are excellent options other than adopting a new columnar datastore.

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

#97

Post by DCoder »

tengbretson wrote: post #80
any626 wrote: post #29

Earlier quoted context omitted.

The user data is most likely in rows instead of columns. Instead of having id, name, age, gender 1213, fake, 60, female they would have property_id, user_id, value 1 (assume age), 1213, 60 2 (gender), 1213, female This gives them the freedom to add more properties to the user without always having to add a column to the users table. When querying the database you'll have to do unions or joins.

Christ do people do this??

This is a pretty popular pattern known as Entity-Attribute-Value [0]. It's used by many products where a) data model needs to be very flexible and allow new attributes without schema changes, or b) a typical entity has a large number of possible attributes that may or may not be set for all entities ("sparse" attributes). WordPress uses this to store post metadata, Magento uses this to store product attributes and most of other data, Drupal uses a variation of this to store all the posts and other content you create… I have too much experience with this model to be surprised.

[0]: https://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80...

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

#98

Post by candiodari »

ajcodez wrote: post #92
candiodari wrote: post #72

Earlier quoted context omitted.

> This gives them the freedom to add more properties to the user without always having to add a column to the users table. When querying the database you'll have to do unions or joins. I think you're right. Oh ... my ... god ... I wish I could say this is the worst example of a database schema I've ever seen, but it isn't. Technology cycle: X gets invented -> idiots abuse it -> X "is bad" -> Y (strictly worse than X)…

It makes sense if each client gets to add their own fields.

Using the builtin type for that purpose is going to work way better. This depends on the DB you're using but is generally referred to as a "JSON" field (why ? Because they're a response to MongoDB, which calls is that). Oracle and SQL server have very similar things.

In Mysql, it is JSON data type [1], in Postgres JSON/JSONB [2].

Creating indexes across them is doable, through a workaround (involving what is generally referred to as "VIEWS", but can be called calculated columns or something like that).

And, frankly, in the worst case for indexing, these databases still perform comparable to key-value stores in speed (especially SQLite).

[1] https://dev.mysql.com/doc/refman/5.7/en/json.html#json-paths

[2] https://www.postgresql.org/docs/9.4/static/datatype-json.htm...

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

#99

Post by icebraining »

candiodari wrote: post #72
any626 wrote: post #29

Earlier quoted context omitted.

The user data is most likely in rows instead of columns. Instead of having id, name, age, gender 1213, fake, 60, female they would have property_id, user_id, value 1 (assume age), 1213, 60 2 (gender), 1213, female This gives them the freedom to add more properties to the user without always having to add a column to the users table. When querying the database you'll have to do unions or joins.

> This gives them the freedom to add more properties to the user without always having to add a column to the users table. When querying the database you'll have to do unions or joins. I think you're right. Oh ... my ... god ... I wish I could say this is the worst example of a database schema I've ever seen, but it isn't. Technology cycle: X gets invented -> idiots abuse it -> X "is bad" -> Y (strictly worse than X)…

EVA is a valid pattern if the keys are dynamic. For example, in a CRM, the user might want to store properties of their clients that you haven't thought of. In our platform, we use different schemas for each company, so we can actually do a ADD COLUMN ..., but you don't want to do that if you have a multi-tenant DB :)

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

#100

Post by dsp1234 »

cdubzzz wrote: post #95
davidp wrote: post #91

Earlier quoted context omitted.

I like to trot out this old gem[1] when people wonder why there's so much hate for MySQL. Nontransactional DDL alone is sufficient to classify it as a toy DB for me. Yes, I've been personally bitten by it. [1]: https://grimoire.ca/mysql/choose-something-else

This talks a lot about 5.5 and mentions that 5.6 is “due out soon”. The current release series is 5.7. How much of this is outdated and how much has stayed the same?

"Some statements cannot be rolled back. In general, these include data definition language (DDL) statements, such as those that create or drop databases, those that create, drop, or alter tables or stored routines." [0]

[0] - https://dev.mysql.com/doc/refman/5.7/en/cannot-roll-back.htm...

Post reply on HN