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

An Unlikely Database Migration

tailscale.com

Post reply on HN
Print view View original

31–40 of 190 posts

Re: An Unlikely Database Migration

#31

Post by mrkstu »

jeff-davis wrote: post #7

This post illustrates the difference between persistence and a database. If you are expecting to simply persist one instance of one application's state across different runs and failures, a database can be frustrating. But if you want to manage your data across different versions of an app, different apps accessing the same data, or concurrent access, then a database will save you a lot of headaches. The trick is kno…

Maybe also part of the success of Rails? Similarly an easy to engineer veneer atop a database.

Re: An Unlikely Database Migration

#32

Post by bradfitz »

hankchinaski wrote: post #27

seems like the reason for not going the MySQL/PSQL/DMBS route is lack of good Go libraries to handle relational databases (ORM/migration/testing)? from the story it seems more like a solution in search for a problem

I thought we adequately addressed all those points in the article? Search for ORM and dockertest.

Re: An Unlikely Database Migration

#33

Post by [deleted] »

npiit wrote: post #2

Unfortunately this company is known for its shady agressive marketing on hacker news. The upvotes count is really suspicious and this is not the first time. EDIT: Why is the downvoting? the post was given like 9 upvotes in the first 5 minutes. I frequently go to "new" and this is a highly suspicious behaviur.

[deleted]

Re: An Unlikely Database Migration

#34

Post by irrational »

bradfitz wrote: post #24
malisper wrote: post #22

The post touches upon it, but I didn't really understand the point. Why doesn't synchronous replication in Postgres work for this use case? With synchronous replication you have a primary and secondary. Your queries go to the primary and the secondary is guaranteed to be at least as up to date as the primary. That way if the primary goes down, you can query the secondary instead and not lose any data.

We could've done that. We could've also used DRBD, etc. But then we still have the SQL/ORM/testing latency/dependency problems.

Can you go into more about what these problems are? I've always used databases (about 15 years on Oracle and about 5 years on Postgres) and I'm not sure if I know what problems you are referring to. Maybe I have experienced them, but have thought of them by a different name.

SQL - I'm not sure what the problems are with SQL. But it is like a second language to me so maybe I experienced these problems long ago and have forgotten about them.

ORM - I never use an ORM, so I have no idea what the problems might be.

testing latency - I don't know what this refers to.

dependency - ditto

Re: An Unlikely Database Migration

#35

Post by bradfitz »

judofyr wrote: post #30

Interesting choice of technology, but you didn't completely convince me to why this is better than just using SQLite or PostgreSQL with a lagging replica. (You could probably start with either one and easily migrate to the other one if needed.) In particular you've designed a very complicated system: Operationally you need an etcd cluster and a tailetc cluster. Code-wise you now have to maintain your own transaction-…

> and a tailetc cluster

What do you mean by this part? tailetc is a library used by the client of etcd.

Running an etcd cluster is much easier than running an HA PostgreSQL or MySQL config. (I previously made LiveJournal and ran its massively sharded HA MySQL setup)

Re: An Unlikely Database Migration

#36

Post by npiit »

lima wrote: post #29
npiit wrote: post #9

Earlier quoted context omitted.

I understand. But given the product features compared to the rest of the industry, Tailscale brings no real value compared to Zero-tier hen it comes to meshes, it's not zerotrust like Cloudflare, Twingate, and many others, it claims to be open source while only the client is and it cannot be used without their closed source control plane where most of the feature are behind paywall, it's way more expensive than reput…

It's more zerotrust-y than Cloudflare et al since it's entirely P2P, with only the control plane running in the cloud. Compared to ZeroTier, the Tailscale client has a permissive license, the mesh is fully routed (vs. a L2 network with unencrypted broadcasts), is written in a memory-safe programming language, integrates with company SSO, and uses the Wireguard protocol (i.e. sane, audited crypto instead of a DIY prot…

zerotrust has nothing to do with p2p, zero-trust is about making sure that this user is authorized to access that application at the resource level not using some decades old segmentation/network level policies. Zerotier also claims to be zerotrust but it's technically not. Cloudflare, Citrix, PulseSecure have zerotrust offerings, but many others sadly just claim to be either by ignorance or dishonesty.

Re: An Unlikely Database Migration

#37

Post by bradfitz »

irrational wrote: post #34
bradfitz wrote: post #24

Earlier quoted context omitted.

We could've done that. We could've also used DRBD, etc. But then we still have the SQL/ORM/testing latency/dependency problems.

Can you go into more about what these problems are? I've always used databases (about 15 years on Oracle and about 5 years on Postgres) and I'm not sure if I know what problems you are referring to. Maybe I have experienced them, but have thought of them by a different name. SQL - I'm not sure what the problems are with SQL. But it is like a second language to me so maybe I experienced these problems long ago and hav…

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.

Re: An Unlikely Database Migration

#38

Post by judofyr »

bradfitz wrote: post #35
judofyr wrote: post #30

Interesting choice of technology, but you didn't completely convince me to why this is better than just using SQLite or PostgreSQL with a lagging replica. (You could probably start with either one and easily migrate to the other one if needed.) In particular you've designed a very complicated system: Operationally you need an etcd cluster and a tailetc cluster. Code-wise you now have to maintain your own transaction-…

> and a tailetc cluster What do you mean by this part? tailetc is a library used by the client of etcd. Running an etcd cluster is much easier than running an HA PostgreSQL or MySQL config. (I previously made LiveJournal and ran its massively sharded HA MySQL setup)

> What do you mean by this part? tailetc is a library used by the client of etcd.

Oh. Since they have a full cache of the database I thought it was intended to be used as a separate set of servers layered in front of etcd to lessen the read load. But you're actually using it directly? Interesting. What's the impact on memory usage and scalability? Are you not worried that this will not scale over time since all clients need to have all the data?

Re: An Unlikely Database Migration

#39

Post by irrational »

bradfitz wrote: post #37
irrational wrote: post #34

Earlier quoted context omitted.

Can you go into more about what these problems are? I've always used databases (about 15 years on Oracle and about 5 years on Postgres) and I'm not sure if I know what problems you are referring to. Maybe I have experienced them, but have thought of them by a different name. SQL - I'm not sure what the problems are with SQL. But it is like a second language to me so maybe I experienced these problems long ago and hav…

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 co…

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.

Re: An Unlikely Database Migration

#40

Post by bradfitz »

judofyr wrote: post #38
bradfitz wrote: post #35

Earlier quoted context omitted.

> and a tailetc cluster What do you mean by this part? tailetc is a library used by the client of etcd. Running an etcd cluster is much easier than running an HA PostgreSQL or MySQL config. (I previously made LiveJournal and ran its massively sharded HA MySQL setup)

> What do you mean by this part? tailetc is a library used by the client of etcd. Oh. Since they have a full cache of the database I thought it was intended to be used as a separate set of servers layered in front of etcd to lessen the read load. But you're actually using it directly? Interesting. What's the impact on memory usage and scalability? Are you not worried that this will not scale over time since all clien…

Well, we have exactly 1 client (our 1 control server process).

So architecturally it's:

3 or 5 etcd (forget what we last deployed) 1 control process every Tailscale client in the world

The "Future" section is about bumping "1 control process" to "N control processes" where N will be like 2 or max 5 perhaps.

The memory overhead isn't bad, as the "database" isn't big. Modern computers have tons of RAM.

Post reply on HN