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

321–330 of 336 posts

Re: A database for 2022

#321

Post by samhw »

eminence32 wrote: post #58
flatiron wrote: post #42

How did they think going from a single json to either MySQL or Postgres? I know they say this isn’t April fools but I’m not sure I would put it past the engineering team. This can’t be real. “We looked at real solutions like cockroach but nobody could be bothered to rtfm”

I'm sympathetic to the idea of avoiding a database because no one on your team has experience with it. On my old team, our product supported Oracle DB (along with some other databases), but on one on the team really was an oracle expert, and we would frequently run into questions that we didn't really know how to answer. We would have dropped it if we could. It's easy to say "rtfm" but doing this doesn't make you an…

> "We've hit an error an error that the manual says nothing about, but our DB expert saw this once, 7 years ago, and remembers how to recover"

Yup, this rings true. Once worked on a large Cassandra deployment – holding people's bank accounts, so, ya know, somewhat critical – and we eventually had to get one of the authors of Cassandra onto our on-call team. Even he was stumped by some of the bugs and failure modes. (And, incidentally, the word 'anticompaction' is still enough to trigger my PTSD.)

The notion that the documentation is an accurate and exhaustive explanation of every single thing about a product is a junior engineer mistake that no one with rough ops experience would say. Nor, for that matter, anyone who's written a database that's in use (as I unfortunately have), or really any other piece of software.

And the same goes for the notion that "everyone should go with MySQL or Postgres for everything because they are Proper Databases that are scalable and won't go down". If I were being charitable, I'd say it's a 'no one got fired for buying IBM' argument; if I were being honest, I'd say it puts me in mind of 'MongoDB is webscale' (https://www.youtube.com/watch?v=b2F-DItXtZs). I don't know why bad engineers are so terrified of thinking for themselves specifically – well, generally, but especially – when it comes to databases. They aren't magical contraptions. They are just portable filesystem wrappers.

Re: A database for 2022

#322

Post by belter »

zimpenfish wrote: post #314
belter wrote: post #288

Earlier quoted context omitted.

Even easier and safer, create a signed url that expires after 5 min...Send it to the user... aws s3 presign s3://awsexamplebucket/test2.txt --expires-in 300

But now you have to know which bucket the file is in, have the AWS CLI tools installed, use Terminal, copy the URL to messages / email, etc. How is this easier than "right-click, pick a menu option"? (If I want an expiring Dropbox link, it's there under 'link settings' in the pop-up. Admittedly only has date granularity but still there as an option.)

Example from the console: "Setting up an Amazon S3 bucket to share files"

https://gist.github.com/pjkelly/be2cd3881e766620a411

Re: A database for 2022

#323

Post by dastbe »

vaughandroid wrote: post #213
tptacek wrote: post #87

This thread has (at least at the moment) serious Bob Martin Sudoku Solver energy to it. Tailscale has solved an infamously complicated problem using, for the most part, simple tools. They're not just successful; they're remarkably successful, spookily successful, upsettingly successful. Consider whether the secret sauce here might not be au courant database choices, but rather something much harder for random teams t…

Please could someone explain the "Bob Martin Sudoku Solver energy" reference?

my interpretation is that there is a certain class of people who think "if i just apply the process then i will get a satisfactory result", as bob martin does with using TDD to implement a sudoku solver instead of just thinking through the problem and designing a solution up front. i don't think its a particularly great analogy because the bob martin example is about trying to use a "mindless" process to achieve a desired design, not picking an overkill option.

Re: A database for 2022

#324

Post by redwood »

vinay_ys wrote: post #235
rsp1984 wrote: post #220

Earlier quoted context omitted.

> I watched with dread how the MongoDB fiasco played out a decade ago. Could you elaborate on this? MongoDB as a company is worth $30B, so it looks like they did at least some things right.

Their paid managed service works well for enterprise SaaS companies who need It also works well for early stage Consumer Internet startups that haven't yet achieved huge growth but care a lot about developer productivity while churning features at high velocity. But it gets blamed for reliability issues suffered by highly successful Consumer Internet companies that have achieved scale and have DAU, MAU in > 10M and h…

Grossly misinformed post. 4TB (compressed) per shard may be what you're thinking of?

Re: A database for 2022

#325

Post by yawaramin »

VWWHFSfQ wrote: post #302
yawaramin wrote: post #301

Earlier quoted context omitted.

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.

Just waiting with bated breath to find out!

Re: A database for 2022

#326

Post by IshKebab »

vvern wrote: post #256
IshKebab wrote: post #191

Earlier quoted context omitted.

Very interesting. I'd never heard of it but apparently MariaDB uses it too. TL;DR is the source is available but you can't use it in production without paying a fee. However versions older than 4 years become truly open source, so you can use old versions for free. Interesting compromise. Might be better than "open core".

That’s not quite right. You can very much use the bsl code in production without a license and many, many companies do. The BSL contains a space for additional use grants. In crdb’s license, you can use the product for anything except building a hosted database as a service product. The definition of what that is is a little bit vague but it more or less means that the users of the product you sell shouldn’t be able…

You absolutely cannot use the BSL code in production without a commercial license. That's literally the first thing it says:

> The Licensor hereby grants you the right to copy, modify, create derivative works, redistribute, and make non-production use of the Licensed Work. The Licensor may make an Additional Use Grant, above, permitting limited production use.

Maybe specific software modifies that as you say, but the base BSL doesn't. I agree it's super vaguely worded ("production" isn't defined at all). Also it turns out MariaDB itself isn't BSL licensed - it's GPL, just some extra projects around it.

Re: A database for 2022

#327

Post by zimpenfish »

belter wrote: post #322
zimpenfish wrote: post #314

Earlier quoted context omitted.

But now you have to know which bucket the file is in, have the AWS CLI tools installed, use Terminal, copy the URL to messages / email, etc. How is this easier than "right-click, pick a menu option"? (If I want an expiring Dropbox link, it's there under 'link settings' in the pop-up. Admittedly only has date granularity but still there as an option.)

Example from the console: "Setting up an Amazon S3 bucket to share files" https://gist.github.com/pjkelly/be2cd3881e766620a411

Again, how is this easier than a single right-click in Finder? Also don't those files need to be public to create a link? You can't create a link to a non-public file which grants access either directly via the link or with a password?

Re: A database for 2022

#328

Post by CRConrad »

dave78 wrote: post #71
Aeolun wrote: post #44

Earlier quoted context omitted.

> why would an engineer want to join a company that is making these decisions? Hmm, I can’t quite articulate why, but I would. Something about having the courage to be different.

I would actually love to work at a company like that. I've been a professional developer for over 20 years now and at least in my experience, too much unneeded complexity has been the root cause of so many defects and product failures. I'm constantly fighting battles to keep things simple. All the young devs on my team want to use every fancy new technology that passes by, but I just want things to work for my custom…

> I'm constantly fighting battles to keep things simple. All the young devs on my team want to use every fancy new technology that passes by...

For me, it's not so much my fellow developers -- half my age, but quite bright enough to realise the benefits of simplicity -- but that the vendors of the tools our corporation has decided to use have in turn decided to implement them not just as a spaghetti-reinforced mudball, but as a spaghetti-reinforced mudball of spaghetti-reinforced mudballs.

(That these SRMB^2s are then just part of a larger spaghetti-reinforced mudball of SRMB^2s, i.e a spaghetti-reinforced mudball cubed, is of course not the vendors' fault but corporate. But then, aren't corporate systems always SRMBs? So if at least the components were simple, the end result would be only an SRM to the power of one, not three... Sigh.)

Re: A database for 2022

#329

Post by CRConrad »

AnimalMuppet wrote: post #161
billywhizz wrote: post #150

Earlier quoted context omitted.

oh boy. is nobody allowed to make a little joke anymore. you should take yourself a lot less seriously my dude.

First: I am not "my dude" to you. And, completely apart from the database, it's a really valid point - not a joke at all. When someone says, "It's 2022. Why are we still arguing about X?" or some such, it means that they haven't been able to persuade the rest of the world about X on the merits of their argument, and so they want to short-circuit the argument by appearing "modern" or "up to date" or "on the right side…

> First: I am not "my dude" to you.

Well, calling yourself "AnimalMuppet" you kind of set yourself up for dude-dom.

Re: A database for 2022

#330

Post by pphysch »

tored wrote: post #310
pphysch wrote: post #271

Earlier quoted context omitted.

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

A decent ORM framework provides all those things out of the box, and I disagree that the ORM creates more problems than its worth. It is a fine tool to accelerate development.
Post reply on HN