Brian Aker gives the “zinger” lightning talk about the newly announced “Drizzle”. This short (under 8 minutes) video captures Aker’s highlights of why he started the Drizzle project and how Drizzle is different from MySQL — both in what has been removed from MySQL and what features Drizzle can accomodate.
Play the video directly in your browser at http://technocation.org/node/576/play or download the 116 Mb file at http://technocation.org/node/576/download.
That’s right. MySQL now has a user group in Paradise.
I am always looking into connecting with other MySQL professionals, to share the laughs and tears, and to enjoy what we love working with every day, MySQL. I have always wanted to bring us all together, and I thought that this would have a good chance of doing so. Since I live in Malta, this made for the perfect location for it. If you live in Malta, or perhaps in Sicily or Tunisia, and want to take a trip, please do join us at our first meeting.
We will be having our first meeting in Mellieha, and please RSVP to me personally via email, westerlund (at) pythian.com if you want to attend. The date is set for Thursday, July 31st at 6pm. We will discuss the current use of MySQL, its future, and whatever else comes into mind. I myself would love to hear usage stories for our first meeting, so we all get an understanding of how MySQL is used in Malta and environs.
I will make sure there are some refreshments to be had.
Let’s keep ourself educated and aware of how other people solve problems that we all sometimes encounter, as well as their interesting technical solutions. And let’s have some fun doing so!
If you are attending Usenix 2008 at the Sheraton Hotel in downtown Boston, you can meet me and ask your burning MySQL questions at my “The Guru is In” session. On Friday, June 27th, 2008 from 2 - 3:30 pm in Constitution B, I will be helping folks out by optimizing queries and schemas, teaching general principles of working with MySQL databases, and answering (to the best of my ability) any other question they may throw at me.
The event details are at:
http://www.usenix.org/events/usenix08/tech/#fri
Hope to see you there!
So, we have all heard that Billy Joel played a concert at Oracle’s OpenWorld in 2007.
What follows is an actual IRC conversation among Don Seiler, Dave Edwards, and myself:
(4:02:46 PM) don: ha @ Billy Joel at OOW
(4:03:38 PM) dave: “We didn’t fire the startup…”
(4:07:53 PM) don: “we didn’t start the backup”?
(4:12:53 PM) dave: “Don’t go changin’ . . . your slave and master”
(4:20:19 PM) ***sheeri shoots Dave
(4:20:49 PM) sheeri: “I don’t want clever replication, we never could have come this far”
(4:24:05 PM) sheeri: “And the server sounds like an aero-plane, and replication chugs along as it must…and the inserts go on, replication corrupts, and I say “Man, now I’m workin’ all night!”
(4:24:29 PM) dave: “I said ‘ls -u’ . . . that’s for access”
[”I said I love you . . . that’s forever”]
(4:24:30 PM) don: UP-TIME GIRL
(4:34:09 PM) dave: “Say it’s not wrong, execution plan!”
(4:43:39 PM) sheeri: Where’s my execution plan, oh man?
[Sing us a song of a piano man]
(4:45:52 PM) sheeri: Go ahead with your schema, leave me alone!
Comment here with your own database-themed parody of a Billy Joel song. Perhaps if we get enough MySQL-themed entries, we can get him to come to the MySQL Conference in April.
That and maybe thousands of dollars………..
Twitter has had many outages recently. On May 17th, 2008 http://blog.twitter.com/2007/05/devils-in-details.html was posted and says:
What went wrong? We checked in code to provide more accurate pagination, to better distribute and optimize our messaging system?basically we just kept tweaking when we should have called it a day. Details are great but getting too caught up in them is a mistake. I’ve been CEO of Twitter for two months now and this an awesome lesson learned. We’re seeing the bigger picture and Twitter is back. Please contact us if something isn’t working right (with Twitter that is).
(in other news, that post was made on May 17th and does not show up on http://blog.twitter.com, which it should, between the May 16th and May 19th posts. I found a reference in other posts and had to search the site to find that post).
A real “awesome lesson learned” is “do not tweak production without testing first.” In every job I have had I have first learned and then taught the concept of “test everything possible.” Which Twitter has not learned yet, because http://blog.twitter.com/2008/05/not-true.html, posted on Tuesday May 20th, states:
We caused a database to fail during a routine update early this afternoon.
As someone who has years of experience working with MySQL, and before that was a systems adminsitrator; as someone who was referred to as “the MySQL Queen” yesterday (by someone who wanted me to test their product, so yes, they were flattering me); I can assure you:
no matter how “routine” a change is, if you do it on production without testing it first, you are playing with fire, and 95% of the fires caused by not testing first are completely preventable.
I will repeat this, because repetition is important to learning concepts.
no matter how “routine” a change is, if you do it on production without testing it first, you are playing with fire, and 95% of the fires caused by not testing first are completely preventable.
With a proper testing environment, 19 out of 20 “whoops, didn’t expect THAT from a routine change!” issues are caught. And I can tell you that often “routine changes” cause unexpected results.
Now, I was online during an outage, and http://twitter.com/home was showing their “site isn’t working” page for at least 3 hours between 2 and 5 am EDT yesterday (Tuesday, May 20th, 2008).
So…..there is no read-only copy around that Twitter could use? Maybe I cannot tweet, but I should at least be able to read what was done before!
Of course, since last week Twitter has done the opposite — often I can see the most recent 20 or so posts, but not anything prior. Now, I understand that it is hard to get all the histories for the people I follow. But it only needs to be done once, and could then be cached — “Posts from who Sheeri follows on 5/20″. It would not be difficult, and I would be OK with the functionality changing such that “once you follow a new person, their tweets prior to when you followed them do not show up in the history.”
Alternatively, you could go the snarky way and say: http://www.techcrunch.com/2008/05/20/twitter-something-is-technically-wrong/ states:
What would be great is if Twitter just moved their blog to another platform so that it doesn?t fail when users need it most.
I am not a huge user of rails. But I will say that given the content of the public announcements, the platform is not the problem. It is the code release process that is the problem. Maybe there’s “agile development” happening, paired programming and code reviews. But there is not adequate testing.
Twitter — if you truly need scaling help, please ask for help — I know Pythian would be happy to help. However, if it really is as it seems — that basic good practice is not being followed — I would like to remind you that backups are really important too, just on the off chance that backups are not happening.
Contemporary software engineering models include many loosely-defined layers. Database developers might help with other layers, but for the most part a database administrator’s domain is the persistence layer.
The Daily WTF has an article on The Mythical Business Layer makes the case for not separating the business layer and the application layer:
A good system (as in, one that’s maintainable by other people) has no choice but to duplicate, triplicate, or even-more-licate business logic. If Account_Number is a seven-digit required field, it should be declared as CHAR(7) NOT NULL in the database and have some client-side code to validate it was entered as seven digits. If the system allows data entry in other places by other means, that means more duplication of the Account_Number logic is required.
It almost goes without saying that business logic changes frequently and in unpredictable ways. The solution to this problem is not a cleverly coded business layer. Unfortunately, it?s much more boring than that. Accommodating change can only be accomplished through careful analysis and thorough testing.
I will call this merged business/application layer the “functional layer.”
The serious scaling requirements posed by most applications these days call for partitioning, clustering, sharding or some other term for “dividing up the data so it does not become the bottleneck”. Enter the “architecture layer”.
“Wait a minute,” I hear you asking. “Isn’t that just the persistence layer?”
Yes and no. To me, there’s a difference between the storage and the architecture of said storage. The database schema for storing a user profile is a persistence layer issue. Figuring out which database instance to go to is an architecture layer issue.
This is an important distinction for me. Many folks are coding the architecture layer directly into the functional layer. A “save_profile()” API function might call an ORM to deal with the persistence, or it will have MySQL (or other database) connection handling and queries. However, the database will grow, and at some point you will find yourself wanting to split the data [more].
This type of information, like the presentation layer, needs to be separate. Why should the application care whether save_profile(’Sheeri’,'hair color’,'blonde’) accesses database1 or database2? More importantly, why should there be major code changes to the functional layer if the architecture changes? Just like no functionality has changed when you change your website color from blue to red, there is no functionality change when you go from splitting data between 2 database servers to splitting among 3, or 10.
For me, the persistence layer is about how the data is stored. Which, explicitly and for the record, I also believe should be separate from the functional layer — if you store hair color and eye color in one table or 2, the functionality of the application has not changed; all that’s needed is a change in how that data is stored and retrieved.
The architecture layer is all about where the data is stored. Early forms of the architecture layer are configuration files, though most would not call that a “layer”. Database administrators should be able to change the architecture of the database system without requiring mucking about in the application’s functional code.
Thoughts?
group
oracle
engineering
Articles
architecture
posts
non-tech
I have already blogged about this keynote at http://www.pythian.com/blogs/948/liveblogging-who-is-the-dick-on-my-site.
If you are interested in actually seeing the video, the 286 Mb .wmv file can be downloaded at http://technocation.org/videos/original/mysqlconf2008/2008_04_17_panelDick.wmv and played through your browser by clicking the “play” link at http://tinyurl.com/55c5ps. This is not to be missed!
At the 2008 MySQL Conference and Expo, The Pythian Group gave away EXPLAIN cheatsheets. They were very nice, printed in full color and laminated to ensure you can spill your coffee* on it and it will survive.
For those not at the conference, or those that want to make more, the file is downloadable as a 136Kb PDF at explain-diagram.pdf
* or tea, for those of us in the civilized world.
Jeff Rothschild of Facebook’s “A Match Made in Heaven? The Social Graph and the Database”
Taking a look at the social graph and what it means for the database.
The social graph:
“The social graph has transformed a seemingly simple application such as photos into something tremendously more powerful.” We’re interested about what people are saying about us, and about our friends. Social applications are compelling.
Facebook users blew through the estimate for 6 months of storage in 6 weeks. It is serving 250,000 photos per second at peak time, not including profiles. Facebook serves more photos than even the photo sites out there, and serves more event invitations than any other website out there.
E-mail invitations are an example of the power of the social graph. If you get a newsfeed or an invitation that tells you 12 friends are attending an event, you have more information, and then can have a better decision on whether or not you want to go. (more…)
Recently I acquired Sesame Street Volume 1, and on the third DVD in the set I came across one of my favorite Sesame Street songs: “Who are the people in your neighborhood?”
Here’s a sample of one such skit, if you are not familiar with it, or if you want a bit of nostalgia http://youtube.com/watch?v=B9lpUjQvToY (note, play will likely start automatically, so tune your volume appropriately before clicking).
The refrain is “Who are the people in your neighborhood? The people that you meet each day!” I live in a city of 34,000 people just 6 miles northwest of Boston, MA. I know exactly one neighbor, across the street, whom we met because I sent my husband over to get her live band to stop playing loud music at her party at 2 am. I do not know many of the local business owners. I do not know who lives in my neighborhood, yet people live around me. Saying I live in a “neighborhood” might be true, but I have no ties or links to it.
Calling a group of people with common interests “community” is just as meaningless as saying I live in a “neighborhood”. There has to be a bond there. I am proud to be a part of the MySQL Community, which actually has forged bonds. Much like Sesame Street, with dentists and bus drivers, our community has many different types of people in it.
In fact, I know that there are many who “only” read and perhaps comment. Remember that every single child (and adult!) that watches Sesame Street is a valuable part of the community — after all, a bus driver is useless without people to drive around. Similarly, folks who develop tools would be doing useless work if there was not such a need for these tools.
The MySQL Community is very real to me. If I were to “move away” from this community, I would experience a loss. There are so many folks whom I will be glad to see and spend time with at the upcoming MySQL Users Conference, and if they are not there, I will definitely miss them.
I blog about MySQL because I enjoy helping others. More importantly, I’ve enjoyed helping out the MySQL community a lot. I have been a part of other “communities” that did not have very much momentum and I was the only or one of the only contributors. I have also been a part of communities in which I’m mostly a lurker, or a learner, and while I gain a lot from it, I much rather prefer a more balanced give-and-take (that’s just my personality).
Speaking of personality, I’m human, as is everyone whose blog feeds to Planet MySQL (organizations excluded). This means that when folks e-mail me or find me in person and say “I love your podcast!” and “Your blogging really helped me.” and “Thank you for all you do,” I feel really good about myself.
If you are new to the MySQL community, feel free to come up and talk to me (or anyone, really) — during the conference, or otherwise. Even if you feel you have nothing to say, just say hello.
And I must end with a disclaimer: I won last year’s “Community Advocate” award from MySQL, so I guess all in all, I’m still a community advocate. Long live the dolphin!