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

Spending $5k to learn how database indexes work

briananglin.me

Post reply on HN
Print view View original

161–170 of 209 posts

Re: Spending $5k to learn how database indexes work

#161

Post by nrmitchi »

cassonmars wrote: post #156
nrmitchi wrote: post #74

As the author touches on, the main problem here isn't learning about indexes. It's about "infinity scaling" working too well for people who do not understand the consequences. In no sane version of the world should "not adding a db index" lead to getting a 50x bill at the end of the month without knowing. I am a strong believer that services that are based on "scale infinitly" really need hard budget controls, and sl…

The question that follows would be: how do you know what was intended to be less performant versus optimized on-demand? The intentions can be easily inferred when the query at hand was a simple join, and to no surprise, many cloud database offerings _do_ provide optimization automation (Azure SQL will for example even automatically add obvious indexes if you let it). But what if the query did need to scan all the row…

> The question that follows would be: how do you know what was intended to be less performant versus optimized on-demand?

I'm saying that the cloud provider shouldn't try to make assumption either way, and I'm definitely not saying that it should try to manage indexes for you.

If you are typically using X ops/s, and begin using 50X ops/s, the default should not be "this customer probably wants to spend 50x their previous spend". It should maybe scale up some percentage of previous usage, but definitely not into a range that would be considered anomalous.

> The choice of infinity scale tools comes with infinity scale costs, and so there’s a responsibility that engineers using these tools need to understand what they’re accepting with that choice.

Sure, but I have never once seen one of these providers make clear that using them comes with the risk of being charged "infinity money".

Re: Spending $5k to learn how database indexes work

#162

Post by nrmitchi »

ashleyn wrote: post #141
nrmitchi wrote: post #74

As the author touches on, the main problem here isn't learning about indexes. It's about "infinity scaling" working too well for people who do not understand the consequences. In no sane version of the world should "not adding a db index" lead to getting a 50x bill at the end of the month without knowing. I am a strong believer that services that are based on "scale infinitly" really need hard budget controls, and sl…

There's no free lunch. Cloud services trade performance woes for budget surprises. This may be preferable in some cases but the tradeoff should be recognised.

Disagree; cloud services trade reduced operation work for higher prices. There is nothing inherent to "cloud services" that requires budget surprises.

Re: Spending $5k to learn how database indexes work

#163

Post by nrmitchi »

Buttons840 wrote: post #59
Nextgrid wrote: post #42

Earlier quoted context omitted.

I have no problems with a developer doing a 5k oopsie with things like card processing or an area that has a legitimate potential for direct monetary losses (such as payment processing where a bug could allow customers to order goods without actually paying). I have a problem with whoever looked at and said "nah, let's go with a cloud-based solution that charges per-query and gives us an essentially infinite financia…

It's not so clear cut. What's the cost of losing the entire on-prem database? Do you trust a company who hired a developer who didn't know about indexes to hire a rock solid DBA? And how much does that DBA cost?

There are also many options in between "cloud-based infinity scale" and "on-prem". You can use cloud services that abstract many day-to-day operational tasks of db management, but are still bound price-wise to your monthly instance costs.

Re: Spending $5k to learn how database indexes work

#164

Post by richardw »

ashleyn wrote: post #141
nrmitchi wrote: post #74

As the author touches on, the main problem here isn't learning about indexes. It's about "infinity scaling" working too well for people who do not understand the consequences. In no sane version of the world should "not adding a db index" lead to getting a 50x bill at the end of the month without knowing. I am a strong believer that services that are based on "scale infinitly" really need hard budget controls, and sl…

There's no free lunch. Cloud services trade performance woes for budget surprises. This may be preferable in some cases but the tradeoff should be recognised.

Our internal monitoring alerts for performance anomalies. Quite possible to scale and warn you.

Re: Spending $5k to learn how database indexes work

#165

Post by perl4ever »

nrmitchi wrote: post #74

As the author touches on, the main problem here isn't learning about indexes. It's about "infinity scaling" working too well for people who do not understand the consequences. In no sane version of the world should "not adding a db index" lead to getting a 50x bill at the end of the month without knowing. I am a strong believer that services that are based on "scale infinitly" really need hard budget controls, and sl…

>I don't expect a service to seemingly-magically detect my poor code, increase my bill by a couple orders-of-magnitude

When you put it like that, it sounds like an awfully good business to be in.

Re: Spending $5k to learn how database indexes work

#166

Post by coding123 »

nrmitchi wrote: post #74

As the author touches on, the main problem here isn't learning about indexes. It's about "infinity scaling" working too well for people who do not understand the consequences. In no sane version of the world should "not adding a db index" lead to getting a 50x bill at the end of the month without knowing. I am a strong believer that services that are based on "scale infinitly" really need hard budget controls, and sl…

It can't be like that. I have discussions with vendors sometimes and the first question I ask - if something lapses and we weren't paying attention - you won't cut our service right?

I think too, in most cases, people would rather run over than cut service.

Also how would such a system work? Let's say you sign up for some API and what, set your billing limit to 500 requests per day. Let's say you're now hitting fabulous numbers / signups - but suddenly you start hitting that 500. If that shuts off your signups or what have you, you're typically going to be worse off than if you just pay the overage bill.

I know it sucks, but the first time you pay your overage is probably your last.

Re: Spending $5k to learn how database indexes work

#167

Post by romero-jk »

derekperkins wrote: post #118
anglinb wrote: post #41

Earlier quoted context omitted.

I'm so curious, so you maintain Vitess but don't use it personally?

I do use it in production and have for years, just not the online schema changes. It's fantastic and FKs are supported in a single shard, which we use heavily.

If you take out online schema changes and sharding, what's the use case for vitess?

Re: Spending $5k to learn how database indexes work

#168

Post by nrmitchi »

coding123 wrote: post #166
nrmitchi wrote: post #74

As the author touches on, the main problem here isn't learning about indexes. It's about "infinity scaling" working too well for people who do not understand the consequences. In no sane version of the world should "not adding a db index" lead to getting a 50x bill at the end of the month without knowing. I am a strong believer that services that are based on "scale infinitly" really need hard budget controls, and sl…

It can't be like that. I have discussions with vendors sometimes and the first question I ask - if something lapses and we weren't paying attention - you won't cut our service right? I think too, in most cases, people would rather run over than cut service. Also how would such a system work? Let's say you sign up for some API and what, set your billing limit to 500 requests per day. Let's say you're now hitting fabul…

> Let's say you're now hitting fabulous numbers / signups - but suddenly you start hitting that 500.

Sure, you get alerted, confirm it's reasonable, and then change your limits. You're also describing how many APIs actually work.

I'll say there is also a difference between going from 500 requests/day to 1000 requests/day, where you might say "this is probably legitimate and I want to run over", and from 500 requests/day to 25k requests/day.

One is mildly inconvenient, and the other is potentially bankrupting.

Re: Spending $5k to learn how database indexes work

#169

Post by ltbarcly3 »

nrmitchi wrote: post #74

As the author touches on, the main problem here isn't learning about indexes. It's about "infinity scaling" working too well for people who do not understand the consequences. In no sane version of the world should "not adding a db index" lead to getting a 50x bill at the end of the month without knowing. I am a strong believer that services that are based on "scale infinitly" really need hard budget controls, and sl…

> In no sane version of the world should "not adding a db index" lead to getting a 50x bill at the end of the month without knowing.

Computers do what you tell them to do. If you are totally clueless and don't bother to take even a few minutes to try to understand a system you are using, the results are going to be poor. Thinking any system can overcome total user ignorance is the thing here that isn't sane.

What the person in this article did is like opening all your windows and setting the thermostat to 74 degrees. It will use massive amounts of energy and just keep trying to heat the house 24/7. If someone turns around after doing this and claims there is actually a problem with thermostats not being smart enough because what if someone doesn't know leaving the window open lets cold air in, well, they shouldn't be allowed to touch the thermostat anymore.

Re: Spending $5k to learn how database indexes work

#170

Post by Something1234 »

romero-jk wrote: post #167
derekperkins wrote: post #118

Earlier quoted context omitted.

I do use it in production and have for years, just not the online schema changes. It's fantastic and FKs are supported in a single shard, which we use heavily.

If you take out online schema changes and sharding, what's the use case for vitess?

If you take sharding out what's the point of using anything other than a normal sql database?
Post reply on HN