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

The Database Administrator is dead

thenextweb.com

Post reply on HN
Print view View original

41–50 of 78 posts

Re: The Database Administrator is dead

#41

Post by falcolas »

belorn wrote: post #35
falcolas wrote: post #16

I guess I had better tell my colleagues that our jobs are all dead! Wait, it's an absolute statement for a headline, so it's actually "absolute crap". > These days, the technology decision maker is the dude with Sublime Text open and a cloud control panel up in Chrome. And when he is successful and gets clients, and a few thousand rows in his database, he realizes that he needs someone to keep that database alive. He…

I normally associate DBA with efficiency and performance of data storage. However, you comment describes a blend between that, and a security administrator who's job include the creation and maintenance of high availability plans, disaster recovery plans (like backups), and monitoring. Do you think the overlapping speaks for the decrement of either profession specialization?

No - DB software is highly dependent on the system it's on. So much of a DB's underlying performance is going to depend on matching the settings you create for your DB to the hardware you're on (and optimizing the system to run a DB).

In other words, efficiency and performance both depend heavily on the machine your DB is running on.

As such, a good DBA needs to be able to do sysadmin tasks. The business won't care that it was the sysadmin's fault for not realizing that a battery had gone dead on the raid controller, and a DBA shouldn't care either. Their purvue is the database, and everything that it entails.

Re: The Database Administrator is dead

#42

Post by twic »

falcolas wrote: post #38
csmuk wrote: post #28

Earlier quoted context omitted.

I disagree. dedicated DBAs are on their way out. Databases are becoming pretty good at managing themselves and the marginal performance gains from tuning usually are easily offset by throwing bigger kit at the problem or throwing more cash at the plan you are on.

Often the act of throwing "bigger kit" at the problem requires specialized tuning of the DB to be able to take advantage of it. More memory? Increase the buffer pool size. Faster HDD? Tweak the settings that determine how many disk operations are attempted every second. Bigger CPU? Figure out the point of diminishing returns on the number of CPU cores for your DB, and start sharding onto multiple DBs to make sure you…

Databases definitely require knowledgeable tuning. But so do most other complicated moving parts in a modern infrastructure - web servers, app servers, kernels, cache servers, etc. Sysadmins manage those quite successfully. In my experience, they also manage databases quite successfully. The idea that a database is a special beast that requires special keepers is a holdover from a dark age.

Re: The Database Administrator is dead

#43

Post by Shorel »

csmuk wrote: post #28
falcolas wrote: post #16

I guess I had better tell my colleagues that our jobs are all dead! Wait, it's an absolute statement for a headline, so it's actually "absolute crap". > These days, the technology decision maker is the dude with Sublime Text open and a cloud control panel up in Chrome. And when he is successful and gets clients, and a few thousand rows in his database, he realizes that he needs someone to keep that database alive. He…

I disagree. dedicated DBAs are on their way out. Databases are becoming pretty good at managing themselves and the marginal performance gains from tuning usually are easily offset by throwing bigger kit at the problem or throwing more cash at the plan you are on.

MS SQL Server has always been good at managing itself. I can only guess it is getting better.

But Oracle needs the finetuning, and I can't see that changing anytime soon, with Oracle some queries basically require that you use a IOT, other some are better with partitioned storage, and so on.

So your premise is extremely dependent on what DB you use.

Re: The Database Administrator is dead

#44

Post by csmuk »

falcolas wrote: post #38
csmuk wrote: post #28

Earlier quoted context omitted.

I disagree. dedicated DBAs are on their way out. Databases are becoming pretty good at managing themselves and the marginal performance gains from tuning usually are easily offset by throwing bigger kit at the problem or throwing more cash at the plan you are on.

Often the act of throwing "bigger kit" at the problem requires specialized tuning of the DB to be able to take advantage of it. More memory? Increase the buffer pool size. Faster HDD? Tweak the settings that determine how many disk operations are attempted every second. Bigger CPU? Figure out the point of diminishing returns on the number of CPU cores for your DB, and start sharding onto multiple DBs to make sure you…

This is all trivial knowledge under the "application performance" banner. All of our development staff are capable of diagnosing these issues and providing suggestions.

Re: The Database Administrator is dead

#45

Post by Shorel »

jbooth wrote: post #21
ghshephard wrote: post #15

Earlier quoted context omitted.

"Most people don't need dedicated DBAs" That's a pretty easy statement to defend. But, I'll respond by saying that most Companies running Oracle 11g with more than a couple terabytes of databases, require a competent DBA, particularly if Disaster Recovery/Transaction Rollback is important. " the DBA often never has sufficient domain knowledge of the problem " Of the half dozen or so truly high level DBAs I've worked…

Why would someone run Oracle in this day and age? "We have 100k lines of established PL/SQL running our business" is a reason, of course, but you could make a similar argument that COBOL development is alive. PL/SQL pretty much always leads to an unmaintainable mess, and if you need BIG DATA, you can go much bigger without Oracle than you can with it, and cheaper to boot.

I converted one of these ugly PL/SQL unmaintainable mess from Oracle to the MySQL query language.

Because the boss told us MySQL was cheaper.

Because of MySQL limitations, I think it is even more unmaintainable now. In real world terms, it is ugly and about ten people out of 500 can fix stuff there.

Re: The Database Administrator is dead

#46

Post by Keyframe »

csmuk wrote: post #28
falcolas wrote: post #16

I guess I had better tell my colleagues that our jobs are all dead! Wait, it's an absolute statement for a headline, so it's actually "absolute crap". > These days, the technology decision maker is the dude with Sublime Text open and a cloud control panel up in Chrome. And when he is successful and gets clients, and a few thousand rows in his database, he realizes that he needs someone to keep that database alive. He…

I disagree. dedicated DBAs are on their way out. Databases are becoming pretty good at managing themselves and the marginal performance gains from tuning usually are easily offset by throwing bigger kit at the problem or throwing more cash at the plan you are on.

I disagree. dedicated DBAs are on their way out.

Is ETL considered a DBA task?

Re: The Database Administrator is dead

#47

Post by jbooth »

Shorel wrote: post #45
jbooth wrote: post #21

Earlier quoted context omitted.

Why would someone run Oracle in this day and age? "We have 100k lines of established PL/SQL running our business" is a reason, of course, but you could make a similar argument that COBOL development is alive. PL/SQL pretty much always leads to an unmaintainable mess, and if you need BIG DATA, you can go much bigger without Oracle than you can with it, and cheaper to boot.

I converted one of these ugly PL/SQL unmaintainable mess from Oracle to the MySQL query language. Because the boss told us MySQL was cheaper. Because of MySQL limitations, I think it is even more unmaintainable now. In real world terms, it is ugly and about ten people out of 500 can fix stuff there.

Well, IMO, you're saying that you basically trapped yourself in a box there. If you're completely determined to embed your business logic into a relational query language, then PL/SQL is probably the best there is.

I'm saying that your business logic shouldn't be there. You've got a whole universe of programming languages, potential disk formats and all that available to you. If you're writing huge ugly queries, and I have, that's when I generally step away from the computer for a bit and think if that complexity is better managed someplace else.

Re: The Database Administrator is dead

#48

Post by morgo »

I am a database administrator.

I somewhat agree with the conclusion which essentially says having your on premise DBA is on the decline.

Hiring DBAs has always been tricky for employers anyway. It's a position of responsibility (to protect the business' data) that is hard to know you've hired the right person for, difficult to replace, and difficult to allow to take any vacation/leave since there will seldom be more than one.

What I don't agree with in the conclusion is that by moving off premise it's all moving to datastore-as-a-service. Large amounts will also move to remote DBA as a service (consulting firms).

Re: The Database Administrator is dead

#49

Post by mattmanser »

falcolas wrote: post #22
mattmanser wrote: post #7

Earlier quoted context omitted.

Most people don't need dedicated DBAs and worse the DBA often never has sufficient domain knowledge of the problem to make an intelligent suggestion anyway. DBs performance is complicated, yes, but the vast majority of it is extremely simple. It's just none of this simple stuff has to be learnt until it's too late and the cost of fixing it has dramatically increased. There's a certain level where you need a DBA and t…

> What we really need is to demystify DB performance, which for the most part is fairly simple. Without getting into the rest of your argument, I'd like to quickly address this. No, it really isn't. In your typical MySQL database, your performance for a simple "select * from x where y" is going to go through a lot of complicated machinery (most of which can be tuned for performance), a few points of which I will enum…

This sort of nonsense is exactly the sort of mysticism I'm talking about.

My, for example, do you think every query needs to be tweaked for this one:

Push the query plan down into InnoDB

So why did you include it on the list?

5a + 5b, Is MySQL so bad at memory management that you tweak it for every query?

So why did you include it.

Virtually everything on that list are implementation details that the vast majority of applications and developers don't need to even think about.

Re: The Database Administrator is dead

#50

Post by Shorel »

jbooth wrote: post #47
Shorel wrote: post #45

Earlier quoted context omitted.

I converted one of these ugly PL/SQL unmaintainable mess from Oracle to the MySQL query language. Because the boss told us MySQL was cheaper. Because of MySQL limitations, I think it is even more unmaintainable now. In real world terms, it is ugly and about ten people out of 500 can fix stuff there.

Well, IMO, you're saying that you basically trapped yourself in a box there. If you're completely determined to embed your business logic into a relational query language, then PL/SQL is probably the best there is. I'm saying that your business logic shouldn't be there. You've got a whole universe of programming languages, potential disk formats and all that available to you. If you're writing huge ugly queries, and…

The stored procedures are not actually big ugly queries. But they surely have business logic.

So far, besides the ugly MySQL workarounds for some missing features, it has been a good decision.

And well, it was a company decision, they are the ones trapped. I'm free from maintaining it, while I had to maintain the first version with all business logic outside the DB.

Post reply on HN