Slashdot Mirror
Ask Database Guru Brian Aker
Brian Aker is Director of Architecture for MySQL AB. He has also worked on the code (and database) that runs Slashdot, and is well-known in both Apache and Perl circles. Outside of the arcane world of open source "back-end" programming, though, hardly anyone has heard of him. This is your chance to ask Brian (hopefully after looking at his blog and Wikipedia listing) about anything you like, from Perl to database architecture to open source philosophy to upcoming events in Seattle. We'll send Brian 10 of the highest-moderated questions approximately 24 hours after this post appears. His (verbatim) answers will appear late this week or early next week.
What is your take on Google's enhancements? Do you fear that Google's upcoming code donation is going to make them a large stakeholder in the future of MySQL? What impacts (if any) do you think this will have--especially on your decisions as a director?
My work here is dung.
From your perspective, what's the biggest public misconception about MySQL and what (if anything) is MySQL AB doing to correct it?
There are no karma whores, only moderation johns
What do you see as being the biggest inhibiting factor in the world of databases? If you could snap your fingers and have one piece of software/hardware changed or removed or improved today, what would it be?
My work here is dung.
When can we get replication that isn't brutally difficult to setup and maintain.
Example, slaves that can be started blank and copy all necessary files without needing to have a copy of the databases already.
MABASPLOOM!
What is it about MySQL that caused you to create so much for it and to become a director for it? You're obviously very talented, why didn't you pick some other open source database (I don't mean to incite a religious war here)? Was it political? Was it because of friendships or really for technological reasons?
My work here is dung.
Is it valid behavior to silently tru
Norris/Palin 2012
Fact: We deserve leaders who can kick your ass and field dress your carcass.
So, let me get this straight: you (mySQL) use a dolphin to fetch data while PostgreSQL uses an elephant to fetch data. Would that explain why PostgreSQL is better at fetching large datasets? Like, the elephant can haul more, but is slower while the dolphin is faster, but can't carry as well? Have you thought about using a non-animal to fetch your data? Maybe a racecar? Those are fast and could probably haul as much as an elephant. Plus, then I wouldn't need to have fish or peanuts in my server room.
Well, I will ask something not related to databases, or even computing at all. From the "About Me" section in your blog, I can see you named your lovely cats Nausicaä and Kiki. I will assume that you are indeed a fan of Japanese Animation, especially the works of Hayao Myazaki. So I ask:
- What's your favorite Myazaki movie to date?
- What's the reason for this choice?
- And finally: I also love Myazaki's movies, but lately I have been struggling to find anime that I really enjoy.
They all seem repetitive and cliché. Would you dare recommend one? =)
Thank you a lot.
My best wishes for you and your cats!
If I clone myself, can I call it a thread?
If a girl winks to us, can I call it a race condition?
Hi, Brian -
Are relational database the end-all, or do we have other promising database models to look out for? OO-databases apparently went the way of the Dodo, but what else is out there that you find interesting?
Assorted stuff I do sometimes: Lemuria.org
It strikes me that a lot of the work that has gone into optimizing databases in the past (especially storage, index structure, and buffer management) works on the assumption that the database will be stored to a hard drive, which is way slower than main memory and has variable access times depending on the relative position of the disk head and the required data.
Nowadays there's a lot of large solid-state flash drives coming out, and as time goes on we can expect to see sizes increase and costs decrease. For small-to-medium size databases, it's now reasonable to keep the whole database on, say, one of the new 64GB memory drives. The use of drives which have a fixed, cheap cost for random access seems to invalidate and simplify a lot of the assumptions made about conventional back-end data storage, and opens up possibilities for new types of optimization (binary tree indexes instead of B+ trees, more use of indirection).
I'm wondering what you see as some of the biggest opportunities for memory-resident databases, and what work is going into MySQL to take advantage of the changes that are happening in storage.
Anonymous Luddite: "What do you think of the dehumanizing effects of the Internet?"
Andy Grove: "Not Much."
What's your opinion of SQLite, PostgreSQL, and Firebird? What do you like about them? What don't you like about them?
Do you even lift?
These aren't the 'roids you're looking for.