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

A database for 2022

tailscale.com

Post reply on HN
Print view View original

301–310 of 336 posts

Re: A database for 2022

#301

Post by yawaramin »

VWWHFSfQ wrote: post #36
musjleman wrote: post #16

So to recap their timeline: * Instead of an actual database use a JSON file. * Write a blog post about how that didn't scale. * Instead of an actual database hand-roll something else. * Write a blog post about how that didn't scale. * Instead of a database with built-in replication which is tailor built for key-value storage use SQLite with a single table containing key-value pairs and some fresh glue to make it repl…

It seems like they're _really_ struggling with is. It's kind of entertaining to watch though edit: also don't forget these blog posts are content marketing for their product. that's really the point anyway

If from your perspective, a super-successful VPN product is 'really struggling', you must have incredibly high standards! We all hope to hear more about your successes, I'm sure.

Re: A database for 2022

#302

Post by VWWHFSfQ »

yawaramin wrote: post #301
VWWHFSfQ wrote: post #36

Earlier quoted context omitted.

It seems like they're _really_ struggling with is. It's kind of entertaining to watch though edit: also don't forget these blog posts are content marketing for their product. that's really the point anyway

If from your perspective, a super-successful VPN product is 'really struggling', you must have incredibly high standards! We all hope to hear more about your successes, I'm sure.

do you want to hear about my successes?

they're not going to be about shoe-horning a JSON file or a SQLite database file into my enterprise product.

Re: A database for 2022

#303

Post by sgbeal »

pooper wrote: post #202
Operyl wrote: post #186

Earlier quoted context omitted.

This comment trivializing Dropbox: https://news.ycombinator.com/item?id=9224

I for one do not think the comments trivialized anything. I see these as inevitable questions that a leader like Drew Houston should be prepared to answer at some point. Think of it this way, would you disqualify me if you were hiring and I asked a similar question at the interview? I think the underlying actual question for Dropbox to ponder (but perhaps not answer publicly) was "what is your moat?" without the busi…

> One activity question for HN: why do you think Dropbox continues to exist today while copycats like Barracuda Copy have failed?

FWIW, i've been using Dropbox since practically the day they went online, and have been a subscriber for all but the first few months of that time. They've never once failed me, never been offline when i needed them, never lost anything, they created a Linux sync client out of the box (whereas Google first claimed the would make GDrive for Linux but never did), and it's easy to manage via multiple interfaces (mainly their own web UI and https://rclone.org, which can proxy your dropbox behind an add-hoc FTP server running in your LAN).

They're extremely pricey compared to the same storage in GDrive, but Dropbox has never let me down so i'm in no hurry to drop them.

Re: A database for 2022

#304

Post by hparadiz »

ransom1538 wrote: post #234
hparadiz wrote: post #130

Earlier quoted context omitted.

+1 on good design and programming. My go to language of choice is PHP/MySQL. I've never not been able to scale a project. At one point while working at Comcast I prototyped a system for every error code from every cable set top box (150 million) in the country on a MySQL server instance running on a MacBook Pro pulling data from Splunk in real time. All so I could generate some png charts and embed them in Slack. I k…

"know there are limits to MySQL" I have gone past mysql limits a few times. Will you go beyond its capability is a simple measure. Can your hardware write fast enough to keep up? If your hardware maxes out writing to disk 200 megs per second, welp mysql maxes out at 200 megs per second. If you need 400 megs per second of writing, well you need two instances that can write independently. That is when you are fucked. A…

That's what I mean though. I've never hit those limits. These days it's easy to put together a raid 5 with NVMe disks and you'll quickly reach gigabyte per second write speeds.

Re: A database for 2022

#305

Post by klysm »

unfocussed_mike wrote: post #284
klysm wrote: post #264

Earlier quoted context omitted.

I strongly dislike the combination of php and MySQL, from the (recent) experiences I’ve had with it. I don’t see a good reason to pick that as a greenfield stack, but I could be convinced otherwise.

MySQL + PHP (Laravel + Composer + Lighthouse + Spatie MediaLibrary) is very productive.

I agree it's _initially_ productive, but the it becomes very difficult to maintain.

Re: A database for 2022

#306

Post by throwdbaaway »

tptacek wrote: post #255
throwdbaaway wrote: post #240

Earlier quoted context omitted.

Sounds like postgres listen/notify could be viable for your high-read-low-write use case? Or it is not scalable enough for the fleet size?

That's still all your infrastructure components calling out to an external service on every read --- and for what advantage? This isn't an app server; it's an infrastructure component, running (I don't know about Tailscale here, but we use SQLite in similar uses cases) on potentially hundreds or thousands of machines.

No, you don't need to make any network call on every read with listen/notify. It will essentially be a local cache, working the same way as etcd watcher, using one postgres connection per machine.

Re: A database for 2022

#307

Post by jeffffff »

tptacek wrote: post #293
jeffffff wrote: post #290

Earlier quoted context omitted.

it's also kinda weird to write a blog post about a database being used for what is apparently a very specific use case without mentioning what that use case is. the burden of proof is on tailscale to explain why they need to deviate from industry norm here and clearly from the entire comment thread of people wondering the same thing as me they haven't done that. this blog post might actually be valuable if they inclu…

This is one of several comments you've written where you've acknowledged you don't know what the use case is. But you've stridently insisted that they should have used Aurora Postgres or Aurora MySQL. You get how strange this take is, right? One thing that would have helped your writing on this thread: a lot more question marks. It's OK not to understand something! Asking questions helps everybody.

at no point in the blog post or this thread has anyone actually explained what their super special use case is that makes doing what almost everyone else does a bad choice and this replicated sqlite thing a good choice. it's pretty clear you're an investor in this company or have some other vested interest in shilling for them, good luck with that.

Re: A database for 2022

#308

Post by mwcampbell »

tptacek wrote: post #261
jeffffff wrote: post #259

Earlier quoted context omitted.

or they could have used mysql or postgres hosted by aws, gcp, azure, etc? i would put money on this not being the last time they change databases

Again: this is an infrastructure component, running on many machines internally. It's not a Rails app. We use SQLite in very similar circumstances across hundreds of machines. Having all those machines schlepping all their reads back to RDS would not only be untenably slow, but it would also make the whole system less stable. I don't think you've really thought through the design at all, and you should before making…

Unless I'm misunderstanding something, it seems to me that Tailscale's controller, discussed in the previous blog post [1], is like a typical CRUD API server, currently only running on one machine (they're not using Litestream's work-in-progress live read replicas), not something widely distributed like Fly's service discovery infrastructure.

I'm not joining the "just use RDS" crowd, but it looks to me like using a managed DB service like RDS would have been a reasonable decision for this application.

[1]: https://tailscale.com/blog/an-unlikely-database-migration/

Re: A database for 2022

#309

Post by unfocussed_mike »

klysm wrote: post #305
unfocussed_mike wrote: post #284

Earlier quoted context omitted.

MySQL + PHP (Laravel + Composer + Lighthouse + Spatie MediaLibrary) is very productive.

I agree it's _initially_ productive, but the it becomes very difficult to maintain.

Why/where, particularly in Laravel?

Laravel has an excellent ORM, a great query builder (I write almost no SQL), an effective database migrations system, a solid class hierarchy (no include statements anywhere), a really useful job queuing system, and it is built around Composer (one of the best package managers anywhere).

Lighthouse is really a first-class, schema-first GraphQL binding with a very logical code interface.

I don't see any code maintenance problems in Laravel that can't be mitigated by the same discipline you need anywhere else.

Re: A database for 2022

#310

Post by tored »

pphysch wrote: post #271
klysm wrote: post #264

Earlier quoted context omitted.

I strongly dislike the combination of php and MySQL, from the (recent) experiences I’ve had with it. I don’t see a good reason to pick that as a greenfield stack, but I could be convinced otherwise.

For me it's not necessarily the tech themselves, but the lack of any framework to guide development for the next guy. All the PHP+MySQL I've worked with has been horribly bespoke and brittle. Want to significantly change a URL? Need to refactor every path in the .PHP file, because it's importing something from ../.. Or get in the spaghetti business with path aliasing on the webserver. Want to refactor the database sc…

All of these problems are created by the developers.

I have created many on-the-fly mini-PHP frameworks to use within existing legacy code bases to avoid all of this.

Easiest way to avoid manually requiring files is to use classes with the auto loader. Done.

The second easiest solution is to have different constants that has the full path to a directory and then just you use the correct constant when doing a require. No relative paths required.

You can even have one require constant per file if that is your game.

Raw sql is fine, just don’t scatter it in every file, instead put sql in specific repositories, e.g ArticleRepository, and do all article queries in there. Now it is easy.

An ORM actually creates more problems when refactoring because entities are spread out everywhere.

If you use something like Phpstorm IDE it can help refactor raw sql too.

Problem is that many developers doesn’t think this thru and even worse they accept the situation and don’t do anything about even if they can. Instead they go to forums and complain. I’m sorry but I have zero tolerance for that.

Post reply on HN