undefined | Better HN

0 pointsbradfitz5y ago0 comments

SQL is fine. We use it for some things. But not writing SQL is easier than writing SQL. Our data is small enough to fit in memory. Having all the data in memory and just accessible is easier than doing SQL + network round trips to get anything.

ORMs: consider yourself lucky. They try to make SQL easy by auto-generating terrible SQL.

Testing latency: we want to run many unit tests very quickly without high start-up cost. Launching MySQL/PostgreSQL docker containers and running tests against Real Databases is slower than we'd like.

Dependencies: Docker and those MySQL or PostgreSQL servers in containers.

0 comments

nmjohn5y ago

Can you put some numbers on how much time is too much? I've never seen anyone go this far to avoid using a database for what sounds like the only "real" reason is to avoid testing latency (a problem which has many other solutions) so I am really confused, but curious to understand!

bradfitzOP5y ago

Running all of our control server tests (including integration tests) right now takes 8 seconds, and we're not even incredibly happy with that. There's no reason it should even be half that.

So it's not really in our patience budget for adding a mysqld or postgres start up (possible docker pull, create its schema, etc).

ac2u5y ago

>right now takes 8 seconds, and we're not even incredibly happy with that

With the amount of explaining and skepticism you're having to deal with in most of the threads here (plenty of reasonable questions, some seem to approach the question with the assumption that your approach is totally wrong) I feel compelled to comment on how nice such a fast feedback loop would be just so it's known that you're not listing these benefits into an ether that doesn't appreciate them.

disgruntledphd25y ago

Yeah, I'm inspired to reduce the cost of my tests to get to a better place as a result of this.

Mind you, I build ML/statisical models, so my integration/e2e tests are definitely not going to get down to 8 seconds.

xupybd5y ago

Wow that's really quick. I can see why that would be very desirable.

It would create a nice flow to get feedback from your test suite that quickly.

viraptor5y ago

Not sure what their requirements are, but I'm using a "spin up an isolated postgres instance per test run" solution and end up with ~3s overhead to do that. (Using https://pypi.org/project/testing.postgresql/

Edit: 3s for global setup/teardown. Not per test function/suite.

irrational5y ago

Ah, we don't use Docker or any other container technology. Maybe that is why we aren't seeing the latency issues you are referring to.

bradfitzOP5y ago

Docker itself doesn't add much latency. It just makes getting MySQL and PostgreSQL easier. If anything, it helps with dependencies. The database server startup still isn't great, though.

nicoburns5y ago

If you don't use Docker, you can just leave the database server running in the background, which removes the startup latency (you can of course do this with Docker too, but Docker has a tendency to use quite a few resources when left running in the background, which a database server on it's own won't).

bradfitzOP5y ago

So then every engineer needs to install & maintain a database on their machines. (Hope they install the right version!)

I mean, that's what my old company did pre-Docker. It works, but it's tedious.

3 more replies

cpuguy835y ago

Would love to know what resources you are speaking of here.

We've definitely done some whack-a-mole with allocations in the engine, and of course there's always things getting changed/added still.

majormajor5y ago

Were you doing a lot of logic in SQL itself? Sounds like not really, but then I'm surprised you'd have so many tests hitting the DB directly, vs most feature logic living above that layer in a way that doesn't need the DB running at all.

jolux5y ago

Why are your unit tests touching a database? I’m a real stickler about keeping unit tests isolated, because once I/O gets involved, they invariably become much less reliable and as you mention, too slow.

bradfitzOP5y ago

Sorry, I should've just said tests. Our tests overall are a mix of unit tests and integration tests and all sizes in between, depending on what they want to test.

jolux5y ago

I see. That makes more sense.

j / k navigate · click thread line to collapse

0 comments

nmjohn5y ago

bradfitzOP5y ago

Running all of our control server tests (including integration tests) right now takes 8 seconds, and we're not even incredibly happy with that. There's no reason it should even be half that.

So it's not really in our patience budget for adding a mysqld or postgres start up (possible docker pull, create its schema, etc).

ac2u5y ago

>right now takes 8 seconds, and we're not even incredibly happy with that

disgruntledphd25y ago

Yeah, I'm inspired to reduce the cost of my tests to get to a better place as a result of this.

Mind you, I build ML/statisical models, so my integration/e2e tests are definitely not going to get down to 8 seconds.

xupybd5y ago

Wow that's really quick. I can see why that would be very desirable.

It would create a nice flow to get feedback from your test suite that quickly.

viraptor5y ago

Edit: 3s for global setup/teardown. Not per test function/suite.

irrational5y ago

Ah, we don't use Docker or any other container technology. Maybe that is why we aren't seeing the latency issues you are referring to.

bradfitzOP5y ago

Docker itself doesn't add much latency. It just makes getting MySQL and PostgreSQL easier. If anything, it helps with dependencies. The database server startup still isn't great, though.

nicoburns5y ago

bradfitzOP5y ago

So then every engineer needs to install & maintain a database on their machines. (Hope they install the right version!)

I mean, that's what my old company did pre-Docker. It works, but it's tedious.

3 more replies

cpuguy835y ago

Would love to know what resources you are speaking of here.

We've definitely done some whack-a-mole with allocations in the engine, and of course there's always things getting changed/added still.

majormajor5y ago

jolux5y ago

bradfitzOP5y ago

Sorry, I should've just said tests. Our tests overall are a mix of unit tests and integration tests and all sizes in between, depending on what they want to test.

jolux5y ago

I see. That makes more sense.

j / k navigate · click thread line to collapse